(Editor’s Note: This is the last of five articles by Steve Foreman on learning management systems.)

How much longer will the LMS remain relevant? Learning is bursting out of the classroom and becoming informal, social, and mobile. How can learning be “managed” in settings where there are no class rosters and no registrations or completions to count? To many organizations, the future of learning management systems seems unclear.

Steve Foreman’s five articles on LMSs:

Of course, the LMS’s ability to track formal instruction is still important to many organizations, especially in areas such as compliance, safety, onboarding, and baseline skill development. But traditionally, LMS products have not been very useful in managing learning that happens in the workplace through activities such as coaching, knowledge sharing, professional networking, work assignments, and other work experiences.

In this article, I’ll explore the Experience API (xAPI) and its potential to advance our ability to manage emerging learning models that seamlessly integrate learning with working.

Advanced Distributed Learning (ADL) standards: SCORM & xAPI

ADL is a standards body that began as a joint project of the US Department of Defense and the Department of Labor, and with industry participation. You may know ADL as the organization that brought us the SCORM standard.

SCORM, which is an acronym for Sharable Content Object Reference Model, is a standard specification for publishing, launching, and tracking eLearning and it remains a dominant standard in the eLearning industry. Essentially, SCORM-compliant eLearning courses can interoperate with any learning management system that also supports SCORM.

First published in 2000, they updated SCORM several times over the next decade. Many eLearning authoring tools and LMS products support the SCORM standard.

Since 2009, not much has happened with SCORM, which they designed for use with traditional eLearning design. SCORM is ill equipped to handle non-traditional learning that is informal, social, and mobile.

Around 2010, ADL recognized a need to define an updated standard that could overcome many of SCORM’s inherent limitations. SCORM is constrained to tracking specific course-oriented things like lesson pages viewed, test scores, and module completions. SCORM also relies on JavaScript, which makes it difficult to implement in mobile apps.

In 2011, Rustici Software received a contract to research and define the new standard. During its R&D phase, they called the project “Tin Can.” Released on April 26, 2013, the standard is officially named the “Experience API” and often referred to as “xAPI.”

What’s in a name?

Unfortunately, all three names (Tin Can, Experience API, and xAPI) are in use today. Having three competing names for a new technology standard is confusing. How can anyone expect the marketplace to adopt a standard when the sponsors can’t even agree on what to call it? It would be fine if the names actually were synonyms for each other. xAPI is an acronym for Experience API, so using those two interchangeably makes some sense. However, the names Tin Can and Experience API (or xAPI) represent two different concepts. “Tin Can” tends to be more relevant to the IT community, while “Experience” is more relevant to learning professionals.

It’s easy to understand the IT perspective. Some of us have played the children’s game where you connect two tin cans via a string. When the string is taut, and one child speaks into the can at one end of the string, another child can listen through the second can. Since the API enables two software applications to communicate with one another, this metaphor makes sense and may resonate with some people, particularly programmers and IT professionals. The name, Tin Can API, is focused on how the API works.

From a learning perspective, the name Experience API is focused on how instructional designers and learning professionals can apply the API. Why call it Experience API instead of Tin Can? Because the Experience API enables us to design learning programs that incorporate, not just formal lessons, quizzes, and tests, but all sorts of experiences where learning may occur.

Since the objective of the new standard is to meet the needs of the learning community, hopefully, the pre-release Tin Can moniker will be dropped in favor of the official and much more compelling name, Experience API, or even the abbreviated xAPI. I’m only going to use Experience API or xAPI in the rest of this article.

What is the Experience API?

The term API (application programming interface) is broadly used throughout the software industry. It generally refers to a library of programming functions that software developers can use to integrate two or more separate software applications.

The Experience API is significantly different from SCORM. Unlike SCORM, the xAPI is not limited to eLearning courses or learning management systems. As a standard, it describes how you can interface any software application with a system that stores and reports on learning data, such as a learning management system.

Any type of software or system that has been xAPI enabled can generate Experience API data. The xAPI operates based on activity streams, a model that uses software to track things people do. The idea of tracking activity streams emerged from social networking and is used by sites such as Facebook, Twitter, and Google Plus.

The Experience API makes it possible to track activities that people do using computers such as performing work tasks, producing work outputs, interacting with others using social media, achieving milestones in games and simulations, and just about any other activity that one can observe or record.

How does the Experience API work?

Imagine that your LMS can communicate, not just with eLearning courses, but also with knowledge bases, collaboration platforms, document management systems, enterprise resource planning systems, helpdesk systems, portals, talent management, performance management, and other types of systems used in the workplace. The learning management system may track not only attendance, completions, and test scores, but actual work inputs, outputs, deliverables, tasks, and more.

The Experience API describes learning activities as statements. Each statement is comprised of an actor, an action, and an object. I (actor) did (action) this (object) (see Figure 1).

Figure 1:
Actor, action, and object used to track and store experience as an activity statement

When a user performs a pre-defined action in an enterprise portal that is xAPI enabled, it fulfills an xAPI activity statement. This activity statement describes a learning experience.

For example, your organization may offer a performance-support solution that helps new employees submit vouchers. When a new employee, named John, successfully submits a completed voucher via the company’s portal, it records an xAPI activity statement. The learner’s experience is then relayed to a Learning Record Store (LRS) (again, refer to Figure 1).

What is the difference between an LRS and an LMS?

Basically, an LRS is a database where each learner’s xAPI activity statements (in other words, the learning records) are stored. It can be seamlessly built into an LMS or it can be a standalone product.

An LMS that has a built-in LRS supports the Experience API and also does all the other things LMS products do to manage learning delivery.

A stand-alone LRS supports the Experience API’s tracking and reporting, but it cannot do all the other things an LMS can do such as scheduling training, enabling self-registration, handling notifications and approvals, providing certificates, or managing instructors, facilities, and resources, etc.

xAPI example

An example of a learning program expressed in Experience API statements illustrates the power of this concept. In this example, Jane is a management trainee who has never written a project proposal, yet her new job requires that she do so.

Jane’s manager is aware that the learning department offers a learning program for people in the organization with similar professional-development needs. The learning program involves formal training and work assignments. The learning department runs an LMS report showing that 80 percent of employees who completed the learning program generated a winning proposal that earned revenue for the company.

Jane’s manager decides to use the learning program. The learning program starts with formal training followed by a set of tasks that Jane completes with coaching from her manager.

The company’s portal and LMS are Experience API enabled. The portal collects data on Jane’s activities and sends that data to the LMS, which generates an xAPI activity stream as Jane goes through the program.

Table 1 contains a list of the proposal-writing learning program xAPI statements. The originating system is the system that generates the statement and reports it back to the LMS. All of the following statements are tracked via the xAPI.

Table 1: Proposal-writing learning program xAPI statements

xAPI “Experience” Statement

Originating System

Learning Type

Jane attended a workshop on proposal writing

LMS (completion)

Formal learning program.

Jane passed a test on proposal writing

LMS (test score)

Formal learning evaluation.

Jane read a sample project proposal

Portal (page access)

Work experience

Jane attended a meeting about the sample proposal with her manager

Portal (calendar)


Jane created a proposal

Portal (file upload)

Work experience

Jane attended a meeting about the proposal with her manager

Portal (calendar)


Jane completed revisions to the proposal

Portal (file upload)

Work experience

Jane attended a meeting about the revised proposal with her manager

Portal (calendar)


Jane completed delivering the proposal to a customer

Portal (file upload)

Work experience

Jane completed closing the sale

Portal (CRM report)

Business result

At any point, Jane’s manager is able to access a report from the LMS on Jane’s progress. After the first two statements, which are programs the learning department traditionally offers, the remaining statements reflect on-the-job work assignments, coaching, and accomplishments. The xAPI tracks all of these statements. Jane was able to learn while producing work outputs and results. This blend of learning and working is a powerful model.

Industry adoption of the Experience API

Some of the first products to implement the Experience API are eLearning authoring tools and some learning management systems. A second wave may follow with additional learning management systems, mobile learning apps, and instructional games and simulations becoming xAPI enabled.

Some innovative LMS products may add an administrator interface for manually entering and updating API statements and learner records. This approach would enable learning organizations to incorporate informal learning activities in their learning programs without relying on external systems to support the Experience API. For example, Jane’s manager could simply log on to the LMS and attest to the fact that Jane has completed a step in the learning program.

Enterprise software applications such as portals, knowledge bases, and collaborative workspaces offer even greater opportunities for learning design using the Experience API. When xAPI-enabled versions of these sorts of widely used business applications become available, learning developers will be able to seamlessly integrate learning activities into the workflow. However, since the xAPI is a learning-industry standard, the enterprise system vendors may not be aware of the standard. Training and IT will need to work together to drive xAPI implementation in enterprise-software applications.

Several aspects of the xAPI will continue to be refined, including its governance. While the standard specifies a list of actions or verbs (for example, “Jane created,” or “Jane attended”) that can be used in xAPI statements, vendors that build the xAPI into their products can add additional custom verbs. The xAPI verb registry will allow addition of custom verbs to the official list, upon approval by a governance group.

For now, LMS companies must decide which eLearning authoring tool and mobile platform will support using vendors’ custom verbs. We must resolve these, and other issues, to make adoption of the xAPI easier for all involved.

ADL’s Training and Learning Architecture

The Advanced Distributed Learning organization has a broader vision of the future of learning technologies, called the Training and Learning Architecture (TLA). The ADL vision consist of four key components: experience tracking, competency infrastructure, content brokering, and learner profiles.

The Experience API covers experience tracking, the first of the four components implemented. The competency infrastructure will describe learning goals in the form of objectives, tasks, competencies, context, and performance standards. The content brokering portion will tag, index, and deliver learning content. Learner profiles will tag and describe learners.

Essentially, the TLA promises to provide a standard framework for describing learning experiences, learning goals, learning content, and learning audiences. Together, these standards will enable learning-management systems to deliver and track a more engaging, relevant, and personalized user experience.

Of course, none of this replaces the judgment, creativity, and skills of instructional designers and the rigor of a solid instructional design process. This new xAPI standard has a lot to offer, but proper application of the art and science of learning is still what really matters. In order to take greatest advantage of the Experience API, we will have to expand our notions of what effective learning is (i.e., not just formal training), and incorporate these new ideas into our instructional design and work processes.

Concluding thoughts

While widespread adoption of the Experience API may take some time, the concept of experience-based learning programs is exciting. Systems used in the daily flow of work will be able to interface with learning management systems to capture milestones and tasks performed by workers and track them in the context of learning.

The Experience API offers great potential for the convergence of working and learning and offers an opportunity for the learning function to demonstrate a more direct and measurable impact on the organization’s success than ever before. The opportunity to provide structure, guidance, and metrics around learning that occurs through work experiences and coaching increases opportunities for level-four learning program evaluation. (See the Related Articles list and the References, both at the end of this article.) Now we can combine formal and informal learning in new ways that advance the goal from learning gain to performance improvement.

The xAPI provides opportunities for greater training and HR collaboration to create stronger linkages between learning and talent management. Employee development is an integral part of career planning, succession planning, and performance management. The ability to formalize and track work accomplishments and job assignments along with formal learning programs offers new opportunities for synergy in combining methods for developing employees.

Even without the Experience API, LMS products will continue to be important. Organizations have an ever-present need for the types of training programs an LMS manages. But, as the Experience API becomes more prevalent, LMS products will need to step up and support it in order to remain relevant and meet the increasing focus on workplace-based learning.


Kirkpatrick, Donald. Evaluating Training Programs, 3rd ed. Berret-Koehler Publishers, 2006.