November 26th, 2004 § 1 comment

A friend of mine, who works in the education industry, asked me the following questions about SCORM:

Why SCORM? Why should I use it, with all the paraphernalia of files it entails, instead of using, for example, a weblog with some JavaScript to integrate the learning objects or an in-house system?

I’m asking the question in the context of small schools with a limited budget, no technical support staff, small labs with no servers, unknowledgeable professors, etc.

These are pertinent questions, and I’ve thought about them many times since I started consulting in this area, although never in the context mentioned above.

So, why choose SCORM? As it often happens when considering a new technology for adoption, people tend to rely more on hype and market considerations than on what the change really means.

When I talk to companies that are considering SCORM — whether they are thinking about adapting their LMS to SCORM or buying one that already supports it — I always try to show them why a shift to a new course deployment platform is not a step to be taken lightly. Many of them, unfortunately, think it’s only a matter of moving the old courses to the new platform. What people don’t realize is that when you migrate to SCORM, you often lose functionality you were used to. The question is: does the new functionality gained is worth the price? The answer is often positive, but, of course, it depends on the context.

Technically, there’s nothing special to the SCORM standard. It’s advantage lies not on its data model or run-time environment. As I said in my first article about it, technically it’s a inferior solution. It’s immature, has security issues, and is very limited. What makes it interesting is that fact that it is a standard — with an organization behind its specification — a closed set of requirement, and market acceptance.

As a standard, SCORM present its users with the possibility of a common implementation target, which makes development easier, reduces costs, and increases offer. On the other hand, there’s the fact that no two LMSes implement the standard the same way. Each implementation has its quirks and deviations, many times utterly defeating their usefulness.

Another drawback, which I don’t think I mentioned in the articles, is the price of many implementations. A couple of them have prices in the seven-figures range. In the context aforementioned, that’s obviously a concern. Another problem, which applies to the same context, is that there are few open source implementations of the standard, almost all of them still not quite functional. And most accessory tools are proprietary as well.

If that’s the situation, why use SCORM at all? Why not build an in-house solution, cheaper, simpler, and maybe not so limited? The answer is clear: data aggregation. It’s not enough allow users to take a course: it’s also necessary to follow up on them. It’s necessary to collect data, aggregate it, and react according to what it represents. SCORM presents a common data model that courses can use to talk to the LMS regardless of their origin or previous knowledge of the target LMS. It allows courses from various sources to be used in a way an in-house solution may not able to, because it lacks market penetration.

A fact about SCORM is that it allows adequately developed courses to run both in those environments that support it and those that don’t . Content modules will run almost flawlessly, although they will lose the fine control over their execution that they would otherwise have under SCORM. Assessment modules are more complicated, but it’s possible to build them in such a way that they will allows users to take their tests without losing any functionality. Without access to the standard, however, most of the data generated by the course will be lost. The users can take the course, but their progress will be lost.

An in-house solution with no support for data aggregation is worthless, so I won’t consider it. An in-house solution with a simpler API may be worth the trouble, but it will be essentially reinventing the wheel. Considering that there will be no interest on the part of content developers to support a parallel API, its existence will likely complicate external acquisition of content. In the case of a existing LMS with an existing API, there are two options. You can implement SCORM as an additional course interface or wrap the original API around the SCORM API. The second option may not be interesting if the existing API is too different from the SCORM API, but it’s the easiest path.

In short, what SCORM offers is the possibility to aggregate data from disparate sources, enable distributed development.

But what if there are limitations that prevent an institution from using the standard, whether they are monetary or technical in nature?

If the limitations are of a monetary order, I believe the best solution is to use a LMS with its own proprietary API whose price range is accessible and that also provides enough flexibility to allow a future move to SCORM. In this scenarion, the courses are the biggest problem since they won’t be forward-compatible unless they are specifically developed for both platforms. Some open source LMS, for example, can be extended by way of plugins, allowing a future implementation of a SCORM run-time enviroment. Of course, using a non-SCORM LMS limits the market from which the institution can buy ready-made courses.

Returning to the idea of simulating an SCORM API on top of a proprietary API, if there’s enough technical knowledge, it can be done in this case too. A simple JavaScript wrapper can be used to make SCORM-compliant courses to run on top of a proprietary LMS. Depending on the way the proprietary API is developed, the course can even make indirect use of the data aggregation facilities of the platform. That strategy can also be used in scenarios where the use of a proper LMS is not possible.

If the limitations are of a technical order, I believe a open source LMS, with a good community around it, is still a good option. More than often, those implementations are very light and don’t require the user to follow complex installation procedures. They may be a bit inferior to proprietary implementations when it comes to management, but they do their work. Technical limitations, like modifying a LMS to simulate SCORM also preclude the aforementioned solutions.

That, then, is my view about the issues mentioned in her question. There may be solutions I’m not aware of, although I try to keep in tune with the market. My answer are probably not that satisfactory but I hope they served to clarify some points.

§ One Response to Why SCORM?

What's this?

You are currently reading Why SCORM? at Reflective Surface.