Future of SCORM 1.x guide published, services top of the menu
It's not a roadmap. It's not, in theory, exhaustive. It doesn't recommend anything in particular. It's not even from ADL itself, so it is not normative in any way. Yet Carnegie-Mellon Learning Systems Architecture Lab's "Technical Evolution of SCORM" probably is the most definitive guide to what could happen to the present form of SCORM. We talk to the author, Dan Rehak.
The paper in itself presents nothing terribly new. Rather, it brings together all the different 'wouldn't it be great if SCORM supported ...' wishlists that people have published or just discussed over the years. It's a menu of options, in other words.
That approach is clearly meant to tie in to ADL's newfound emphasis on implementating existing versions of SCORM and avoid scaring implementors with whizz bang new functionality that looks as if it might make the present spec (1.2 going on 1.3) obsolete.
As Dan Rehak, key architect of the SCORM but no ADL spokesperson, puts it, "There is no official plan beyond 1.3". So there's not going to be a SCORM 1.4 anytime soon, never mind a SCORM 2.0. Instead, ADL focusses on releasing new tools, documentation and courseware that will help implementors of the present version.
If, whether and how the options outlined in the 'Technical Evolution of SCORM' paper become part of SCORM is, according to Dan, entirely up to the community. Requirements are gathered during ADL plugfests like the forthcoming one at Carnegie-Mellon, and put into ADL's internal decision making process.
The 'Technical Evolution of SCORM' paper aims to inform that process by listing all possible SCORM 1.x extensions. The extensions are ranked on complexity of inclusion in SCORM itself, effort required to implement the extension's functionality, and the impact of the extension on the use of SCORM. Also indicated are the scope of the extension within the SCORM model, the amount of research that has been done around the extension, the level of existing practice around the extension, whether any standards exist in an extension's area, and whether there are any related issues. Pretty comprehensive, in other words.
Still, by collecting those extensions that are feasible within the SCORM 1.x model, a few things can be ruled out. First and foremost, the "procedural learning" pedagogical model that underpins the present SCORM is unlikely to be changed. SCORM was designed to take a single learner through a preset sequence of material and, beyond the more flexible sequencing that comes with 1.3, that's what it'll remain.
In the very distant SCORM 2.0 future, the goal is to marry this kind of 'next page' pedagogy with "model based approaches"; i.e. intelligent tutoring systems. This approach would take user targeted customisation of courses to the point that some material can be dynamically generated as well as sequenced. Beyond the possibility of adding a few collabaritive functions in SCORM 1.x, there's no mention of open, collaborative, learner directed pedagical approaches for either SCORM 1.x or 2. Harmonisation with other IMS specs like Learning Design is assessed as an enhancement, though.
The most noticeable overall enhancement in the guide is the emphasis on a service based architecture. This reflects a strategic decision at ADL, and is intended to enable many of the other possible enhancements to the model. In essence, the idea is to disaggregate the various functions that make up a SCORM run time implementation, and have them exposed as a (web) service. For the widely desired assessment enhancement, for example, it would mean that a SCORM implementation could have a separate, self-contained assessment engine that processes IMS Question and Test Interoperability (QTI) extensions to a SCORM compliant learning object (a SCO) and exposes the results to other enignes such as a sequencing or tracking service.
According to Dan Rehak, the main motivation behind this strategic focus on services is that "we have had to deal with organisations that have widely distributed learners, and they don't want their learners to have to go to a number of different systems. They want the integration to take place behind the GUI, and to use best of breed solutions."
A properly architected, services based SCORM environment (essentially an MLE, rather than a VLE) would also make it much easier to extend SCORM functionality, without breaking established functionality. Once a service based system is in place, people could add a repository service, for example, without having to replace or rewrite their entire SCORM environment. Much the same would go for new services, or newer versions of existing services.
As with all the other proposals in the paper, however, implementation depends entirely on what the SCORM vendors want. Dan points out that some prototypes are being built, that there is some demand on ADL to expose some SCORM webservices and that developments in the area at IMS and other specification bodies are monitored.
The paper also includes some general diagrams by Dan Rehak as well as ADL technical director Phil Dodds of what a SCORM service environment would look like. It includes tantalising possibilities like a user interface service to support dynamic adaptation of content to different users and devices and enterprise services for student record system integration. But there's no nitty gritty on how all this stuff is to be implemented. Another thing to bear in mind here is that even if consensus can be reached around the usual web services suspects such as SOAP, WSDL, UDDI and the like, there is not going to be anything to stop the vendors from implementing the lot in the same old VLE.
Still, the strategic decision to go for a services based architecture, as well as its similarities to the architectures that are knocking around IMS, JISC and OKI, yields one of the strongest indications yet of the future of e-learning technology. And it's not the one size fits all, no user serviceable parts, monolithic VLE.
The paper can be downloaded as a pdf and viewed as html at the Carnegie Mellon University Learning Systems Architecture Lab website.