Learning Architecture: Designing Digital Learning Ecosystems

Most organisations do not have a digital learning ecosystem. They have an accumulation of platforms.

Most organisations do not have a digital learning ecosystem. They have an accumulation of platforms.

A learning management system stores courses. A separate platform delivers virtual classrooms. Another provides external content. Assessment, skills data, coaching, credentials and analytics sit elsewhere. Each purchase may solve an immediate problem, but the combined experience becomes fragmented, expensive and difficult to govern.

Calling this collection an ecosystem does not make it one.

A genuine learning ecosystem connects learning purpose, people, content, technology, assessment, support, data and workplace or educational practice. Learning architecture is the discipline that makes those relationships deliberate. Its value lies not in assembling more tools, but in deciding what must connect, what should remain separate and what the organisation should be able to replace without destabilising learning.

The learning management system is not the architecture

Many organisations continue to treat the learning management system as the centre of learning. This confuses administration with education.

The system may enrol learners, distribute materials, record completions and generate reports. These functions are necessary, but they do not create coherence across the learner journey. The original Next Generation Digital Learning Environment work challenged reliance on a single system and proposed a component based environment built around interoperability, personalisation, analytics, assessment, collaboration and accessibility. It explicitly concluded that no single application could adequately deliver all of these functions (Brown et al., 2015).

The criticism remains relevant because many supposed ecosystems are still organised around the limitations of the dominant platform. Learning activities are selected because the system supports them. Assessment is simplified because integration is difficult. Data remains trapped because migration is expensive. Educators adapt their practice to technology that was originally procured to support administration.

This is not learning architecture. It is platform dependency.

More tools can produce less learning

The argument for an ecosystem is often reduced to offering learners more choice. Yet choice without coherence creates friction.

Learners may need to move repeatedly between systems, recreate profiles, interpret inconsistent navigation and remember where discussions, resources and feedback are located. Staff may duplicate content, export reports manually and maintain several versions of the same learner record.

Every additional tool creates obligations involving integration, accessibility, identity management, security, data retention, support and staff development. A platform that appears inexpensive during procurement may become costly when these hidden responsibilities are included.

The architectural question is therefore not whether a tool has attractive features. It is whether the tool strengthens the complete learning journey without creating greater fragmentation elsewhere. A system should not be added merely because it can perform a task.

Educational institutions: flexibility without fragmentation

Duke University’s Kits project illustrates an attempt to move beyond reliance on one learning management system. Rather than forcing every course into the same platform, Kits allowed educators to assemble approved applications around particular teaching needs while maintaining shared course groups and access arrangements. The design emerged partly because students had experienced difficulty navigating resources distributed across different systems (Tingen, 2019).

The initiative exposes both the promise and the difficulty of ecosystem design.

A modular environment can support disciplinary differences and reduce dependence on a single vendor. However, modularity can also increase complexity. Learners should not have to understand the institution’s technical architecture simply to participate in a course. Integration at the system level is insufficient if the resulting experience remains cognitively fragmented.

Duke’s approach is valuable because it attempted to curate and connect tools rather than permitting uncontrolled adoption. Nevertheless, even a well integrated catalogue does not guarantee strong learning design. An institution can connect several weak activities as efficiently as it can connect effective ones.

Architecture must therefore govern pedagogical purpose as well as technical access.

Architecture is also organisational

Digital learning strategies often treat architecture as a technical matter owned by information technology teams. This is a serious category error.

Learning is produced through relationships among educators, designers, assessors, support staff, managers, subject specialists and learners. If these groups work through disconnected processes, integrated software will not create an integrated experience.

Research examining learning design practice at the Open University showed that established structures could both enable and constrain design. Specialist roles, workshops and institutional knowledge supported collaboration, while perceptions of learning design as a gatekeeping or quality assurance process sometimes restricted creativity and made it appear as something done to academic teams rather than with them (Olney & Wood, 2023).

This finding challenges the assumption that a durable ecosystem can be designed through a technology roadmap alone. The architecture also includes decision rights, production processes, staff capability, governance, time and professional relationships.

Where these are weak, new technology simply digitises organisational fragmentation.

Corporate L&D: the content marketplace problem

Corporate Learning and Development has embraced the language of ecosystems, but many implementations amount to content aggregation.

Employees are given access to thousands of courses, videos and learning pathways. Artificial intelligence recommends resources according to job roles, interests or skills profiles. The experience appears personalised, yet the organisation may still lack a clear account of which capabilities matter, where learning will be applied or how managers will reinforce it.

IBM’s Your Learning system represents a more developed architecture. It connects internal and external content, personalised recommendations, learning records, badges, manager requirements, skills information and other human resources processes. The system was designed as part of a broader workforce strategy rather than as a standalone course library (Qin & Kochan, 2020).

Research using IBM personnel, learning and performance records found positive associations between learning activity, internal credentials, sales performance and career progression. However, those relationships do not demonstrate that the platform itself caused the outcomes. More motivated employees may learn more, perform more strongly and progress faster for reasons that the system does not capture (Qin & Kochan, 2020).

IBM therefore demonstrates both the strength and the limitation of ecosystem thinking. Learning becomes more strategically valuable when connected with skills, careers and performance. Yet integration can make claims about impact appear more convincing than the evidence permits.

A connected system is not automatically an effective system.

Corporate ecosystems must connect learning with opportunity

Schneider Electric reported implementing an open learning ecosystem in which its learning management system supported compliance, formal training and reporting, while other platforms provided access to formal and informal learning, assessment and certification. The company later connected development opportunities with projects, mentoring and internal mobility through its Open Talent Market (Schneider Electric, 2020, 2023).

This is architecturally stronger than treating learning as content consumption because it connects development with opportunities to apply capability.

However, the language of openness should be examined carefully. An ecosystem is not meaningfully open merely because several platforms are connected. Openness also concerns whether data can move, whether credentials remain usable, whether content can be retained, whether suppliers can be replaced and whether employees can understand how recommendations and opportunities are allocated.

Without these conditions, an apparently open ecosystem may remain commercially and algorithmically closed.

Interoperability is necessary but not sufficient

Technical standards can allow systems to exchange identities, content, activities and results. This reduces duplication and makes replacement more feasible. It does not guarantee educational coherence.

Two systems may exchange data perfectly while using conflicting definitions of participation, completion, competence or skill. A credential may move between platforms while remaining a weak representation of capability. An analytics system may combine records from multiple sources while still measuring activity rather than learning.

The difficult work lies in agreeing what the data means and what decisions it should support. This is why architecture requires shared definitions, data ownership, assessment principles and governance. Otherwise, interoperability merely moves confusion more efficiently.

Built to last must not mean built to remain unchanged

A durable ecosystem is not one that preserves the same platforms indefinitely. It is one that can evolve without repeatedly disrupting learning.

Organisations frequently create dependency by allowing a supplier to control content, learner histories, integrations and reporting logic. When costs rise or strategic needs change, migration becomes so difficult that the organisation remains with a system it no longer considers suitable.

Architecture that is built to last should therefore protect organisational capability rather than individual products. It should include:

• Open standards.
• Transferable data.
• Documented integrations.
• Clear ownership.
• Modular components.
• Realistic exit arrangements.

UNESCO, UNICEF and the International Telecommunication Union similarly argue that digital learning platforms should strengthen wider educational systems, serve public purposes and remain publicly accountable rather than allowing platform priorities to define education (UNESCO, UNICEF, & ITU, 2025).

Sustainability also requires continuous review. Content becomes outdated. Accessibility expectations change. Security threats develop. Organisational priorities move. A platform that once solved a problem may later become the problem.

The critical test of a learning ecosystem

An organisation should not judge its ecosystem by the number of platforms connected or the amount of content available. It should ask:

Where these questions cannot be answered, the organisation has not created a learning ecosystem. It has connected software.

Learning architecture matters because isolated courses cannot address complex educational and workforce needs, while isolated tools cannot create continuity. The work is not to place everything inside one system or connect every available platform. It is to design the smallest coherent environment capable of supporting learning, assessment, practice, support and improvement over time.

The strongest ecosystem is not the one with the most technology. It is the one in which technology can change without the purpose, quality and continuity of learning collapsing with it.