There has been a lot of talk in LETSI lately about what SCORM 2.0 should look like. Everything is on the table. Since there are so many use cases for e-learning, it has been difficult to narrow down the focus of what a specification for the next generation of e-learning should look like.
Some have proposed that maybe SCORM 2.0 should be more of a platform than a specification. Aaron Silvers introduced the phrase “Linux for learning” (Aaron discusses it some here). It has been bounced around a lot, there is a lot of enthusiasm around the idea, but it’s exact definition remains a bit elusive. There is a thought that in a time of accelerated innovation, it makes more sense to focus on informal specifications and open source implementations rather than on formal standards. If that is the case, what is LETSI’s role in the community? Does LETSI merely shepherd the development of specifications, or do they actually produce open source software?
It is sometimes hard for me to debate ideas in the abstract. It really helps me to see the merits (or demerits) of an idea if we can be concrete about how it will actually be implemented and what it will do. In this case, what does a “platform for e-learning” actually do? What problem(s) will it solve? What will it look like? Why would people actually use it?
Tim and I have batted these last questions around a lot over the last few weeks. We’ve come up with one answer that might represent a useful path forward for LETSI. This might be just a different way of stating what others have already stated, but here goes.
Ten years ago, every LMS and every content vendor needed custom hooks to get their applications to work together. Proprietary interfaces required vendors to modify their products every time they wanted to integrate with another vendor. The world looked like this:
After SCORM standardized the interface between LMS’s and content, things got a lot easier. Now LMS and content vendors all just had to code to one single interface and things were a lot simpler. The world looked like this:
Today we are back in a similar situation, except the items being integrated are changing. The content integration problem has largely been solved (yes, it can still improve, but the path is known). The integration problem facing learning systems now stems from trying to integrate other systems and applications. It looks something like this:
It’s a very similar problem to the one SCORM solved. Years ago, LMS vendors were being asked to integrate with many different types of content. Today, they are being asked to integrate with many different types of applications. Currently, LMS’s integrate with things like virtual worlds, simulations, assessment engines, competency management tools, content repositories, reporting services, discussion boards, classroom management tools, intelligent tutoring systems, performance support systems, knowledge management systems, document management systems….and the list goes on and on.
Back in the day, each LMS and each content producer had a proprietary interface for performing integrations. Today’s situation is similar. Today, many LMS’s have their own proprietary plug-in architecture or API for enabling extensibility. For a great example of LMS extensibility and integrations, check out the number of modules available for Moodle.
Many LMS’s are providing extensibility interfaces. Each is doing this differently. The industry wants more integration. The use cases presented to LETSI require system integration and extensibility. Perhaps standardizing LMS extensibility interfaces is the next big problem that LETSI should solve.
Integration and extension seem ripe for standardization. Why?
- It is currently being done. As a standards body, we would not be innovating, but instead codifying established best practices.
- It is in demand. LMS’s are already expected to integrate with a number of systems and this number is rapidly increasing.
- It is currently costly. Much of the cost of LMS implementations currently stems from integration services work.
- It is currently painful. In addition to cost, the fragility of integrations makes it hard to justify changing systems. This creates vendor lock-in.
Many have already discussed developing a “platform for e-learning” or a “learning systems architecture”. This post is saying the same thing, but getting a bit more concrete about what that means. To us, this platform/architecture is a way of adding new functionality to existing learning systems in a standardized fashion. A standardized platform/architecture enables functionality to be developed once and integrated into any system, just like content can now be developed once deployed to any system.
The key insight here is that this is something that is already being done and that it is an existing pain point with real business value. LETSI can define an architecture by codifying existing practices rather than inventing something from the ground up. Simpler integration benefits vendors and users alike.
