A glimpse at the history of SCORM, starting along with the need for EdTech standardization, reveals a riveting tale. It might tell us something about its limitations, and the ways . It might also give us an idea of its future and how it will fare in the face of recent competition.
US Department of Defense, Late 90s: SCORM is Born
In 1996, the US Congress granted the National Guard funds to “prototype electronic classrooms and learning networks.” This project would spark interest in other agencies’ EdTech initiatives. Soon enough, the sheer volume of information technology projects in defense and security contexts alone would lead to the creation of the Advanced Distributed Learning initiative―first led by this guy―and supervised by the Under Secretary of Defense for Personnel and Readiness. Tasked with unifying the structure of existing online learning programs for the Department, ADL borrowed ideas from AICC, a late 80s specification for EdTech from an aviation industry committee.
In 2001, the Sharable Content Object Reference Model (SCORM) first saw the light of day. Shortly after its first release, the specification SCORM 1.2 was launched, fixing some patently missing elements from version 1 and quickly becoming the most successful EdTech standard to date. Despite the expanded functionality and ongoing updates of its next iteration, SCORM 2004, the 15-year old version prevailed.
Thanks to SCORM 1.2, LMS nationwide reached an understanding of what an electronic learning offering was, what it should include, and how its content should be laid out. It gave federal agencies, and organizations in general, the ability to compare and share content across various platforms. It kept monopolistic practices at bay and protected content from being lost even if a system stopped being supported or if a vendor went out of business.
From a technical standpoint, SCORM is an XML file that outlines content in a tree-like structure, along with a set of required and optional attributes. This makes it easy to deploy as a content “spellchecker.” Perhaps almost too easy. Throughout its tenure, several learning products claimed to be SCORM-compatible when all they did was something akin to conducting the spelling and grammar checks done by popular word processors. Even worse offenders were the SCORMifiers, one-click tools who magically transformed any learning content into SCORM conformity. Prominent cases of interoperability failure where SCORM was involved did not help its cause.
SCORM and LMS: A History
Early on, systems like Moodle™ had the ability to import SCORM packages. All the package needed was an “LMS manifest” XML file at the top following the specification, along with the course content laid out according to the manifest. Multimedia files and reading material are arranged accordingly inside the package, which is a typical ZIP file.
SCORM was embrace, with abundant functionality provided. Fixes and new features for SCORM kept showing up in new releases of Moodle™, with important roles played by Dan Marsden and a small-but-sturdy army of volunteers. Mardsen’s blog documents the years of steady work and alludes to an optimistic future that, ultimately, has failed to materialize.
But over time SCORM started to lose traction, which seemed to be the case ever since SCORM 2004. Most perplexing, the space vacated by SCORM wasn’t filled by anybody else, raising the question of whether anyone other than the US DoD really needed a learning specification. Another question was if it made business sense for commercial EdTech to allow the free flow of data. Why should a Blackboard or Canvas offer easy portability to another LMS? Even Moodle™, the industry’s archetype for openness, offered SCORM compatibility but never added SCORM-creation abilities. Much like Esperanto, the revolution for universal EdTech understanding stayed in the larval stage.
As an added explanation for the loss of traction, the web 2.0 movement of web-services and 3rd party content accessible through standards such as the IMS Global Learning Tools Interoperability and now Caliper have opened the world of content and activities to LMS and classrooms without the need to transfer files or other information between systems. The ease of use for these widely adopted standards has helped to make “External Tools” one of LMS best core features.
Attention to SCORM development has all but come to a halt in recent years. Even so, you can still find Marsden giving case-by-case support to at least some issues in the Moodle™ forums.
Eating SCORM’s Sour Grapes
One of SCORM’s worst pitfalls is its complete focus on supply while disregarding demand. Instructors soon realized that they could appropriate standardized content into their teaching thanks to SCORM. But when it came to performance, SCORM had no way to ensure assessment outcomes were similarly standardized. The question of why this was not a similar priority for the DoD at the turn of the century is better left for another time.
In 2013, recognizing the several issues facing SCORM (including, possibly, brand reputation), and a new technological stage, ADL launched the “Experience API”, or xAPI, a potential SCORM replacement. xAPI came with the appellative of “Tin Can API”, intended by ADL to reflect its “two-way conversation with the community.” Coincidentally, that same year, Marsden, by then a lone coyote in the SCORM prairie, announced that he would move from working on SCORM compatibility in Moodle™ to greener “development tasks.”
Instead of XML, xAPI works in JSON, a newer, simpler, and more flexible format that features the one thing the technical basis for a specification should have: interoperability. While XML requires additional functionality to dissect the data from the structure, JSON is data and structure all at once. Programming languages like JavaScript and Python can read JSON files using built-in functions without extra coding required.
When All Is Said and Done…
While xAPI lets you add a performance profile and use it to automatically track and evaluate the effectiveness of a learning intervention, it offers little help in developing said profiles. A task that takes a “massive amount of thought and detail.”
For all the imperfections the SCORM specification has, xAPI has yet to reach SCORM’s status of standardization. Furthermore, promises made about how xAPI will “future proof” your content, sound too much like those made about SCORM a decade ago. The only update they include is a promise of updating for contemporary privacy concerns.
Some see CMI-5 as the next frontier. CMI-5 is a recent “xAPI profile” that brings back some elements from AICC but with added specificity. It does seem to require large parts of the xAPI specification, plus some additional development, which makes it unclear whether it makes sense to add CMI-5 and not xAPI compatibility to an LMS. Besides, CMI-5 development is also in the hands of ADL since AICC (the Committee) dissolved in 2014.
So, with the imminent demise of SCORM having been predicted for years, the need for a better, sounder specification is still out there. While ADL and Rustici, a private company, are betting on xAPI, they both also have active projects based on SCORM. Rustici, owner of the scorm.com domain and working independently from ADL, is perhaps the only entity who offers some third-party functionality, by way of their “SCORM Cloud” plugin family, which requires a paid subscription to work.
5 Responses
Five years on and there has been no progress towards a SCORM Successor. xAPI is dead in the water, failing to live up to hype and burning the fingers of any corporation betting on it.