Again, xAPI is not Intended to Replace SCORM

Editor’s note: I started this article over a month ago, so it has now been almost two months since the meeting referred to in the first paragraph. Since that time, I have joined the team who are planning and implementing the next phase of the Experience API project. The ideas from this article are just as true as they were a month ago when I was first writing it. I hope you enjoy it.

A couple of weeks ago I attended an online meeting with Mike Rustici, of Rustici Software. The meeting was about the future of online learning now that version 1.0 of the Experience API (also known as the Tin Can API or the xAPI) has been officially released. Here is the biggest take-away that I got from that meeting.

Mike started by speaking about the myriad of functionalities that are typically bundled into a traditional Learning Management System (LMS). He showed a graphics depicting over a dozen tasks that might be performed by a modern LMS (or LCMS) and talked about how these different pieces of the total solution might be used in different parts of the company. But then he said that most of the things that a traditional LMS does can be boiled down into one of two categories, a Training Delivery System (TDS) and a Learning Record Store (LRS).

And here is the key point, for me. He did not say that the LMS could be boiled down to a Learning Record Store, but that it consists, primarily, of two parts – a TDS and an LRS. He explained that, in the emerging future of distributed learning, we see two separate components – a Learning Record Store to track learning events from whatever source they might originate, and “a different component to allow formal training to be accessed from anywhere, in the Training Delivery System.” Furthermore, Mike went on to say that the Tin Can API addresses only the LRS portion of this problem.

Yes, it is true that, in the Rustici view of distributed learning beyond the horizon that the TDS is but one possible client of the LRS. This is a point we completely embrace. However, Mike also acknowledges that there is a need for something to contain, manage, and deliver formal training, and that need is beyond the simple definition of the LRS (and its Experience API). This is the part of SCORM that the Tin Can API does not address and does not seek to replace.

Will SCORM be replaced? Maybe – even probably. But the Experience API is more of an adjunct to SCORM than a replacement.

This entry was posted in Experience API, SCORM, Technology, Tin Can API. Bookmark the permalink.

One Response to Again, xAPI is not Intended to Replace SCORM

  1. xAPI could replace the record storage, but what about all the other functions?  xAPI is not designed for scheduling, for example.  There s no sequencing, no user management features, and so on.

Leave a Reply

Your email address will not be published. Required fields are marked *