Building xAPI-Enabled Ecosystems Requires Strategic Choices

A potentially game-changing technology for L&D teams, xAPI holds out the promise of gathering and using more complete data on learning activity and its impact than has ever been possible before. In choosing to move to an xAPI-enabled learning and performance ecosystem, an organization undertakes two key shifts: The first is capturing data from a wider variety of sources and documenting all types of learning activities—using xAPI’s common syntax. The second is exploring how and where to store all of the data the new xAPI system gathers and deciding how to make the best use of it.

An xAPI ecosystem allows eLearning designers and developers to capture, send, and use a vast amount of data about the learning experience, including:

  • Capture data with an eLearning authoring tool: Leading authoring tools provide at least minimal support for xAPI as part of their out-of-the box offerings; some offer very rich options.
  • Send data from another type of learning tool: When investigating new learning technology, ask whether there is an existing or in-development xAPI integration for your interoperable ecosystem.
  • Wrap content in a tool that does the xAPI coding for you: This makes it possible to capture data from learning experiences that don’t fit the typical LMS-cataloged eLearning course profile.
  • Write custom code: Using xAPI is not a difficult task for experienced developers; L&D teams that are writing new software can easily do it using xAPI.
  • Export and convert data from other systems: This may be a meaningful stopgap measure to get performance and business data from systems outside of the L&D environment.

While capturing learning data may be completely within the capability and scope of the L&D function, building an ecosystem to receive, store, and analyze all of the data an xAPI ecosystem can capture generally requires a larger effort. This involves multiple departments and considerations, and generally more investment, to accomplish.

LMS, LRS, or both?

Two types of systems provide the foundation of an xAPI-enabled ecosystem: the LMS and the LRS.

Most large organizations already have at least one learning management system, or LMS. The LMS has taken a beating in recent years for being an inflexible, cumbersome, closed system. The very nature of the SCORM specification at the heart of many LMSs is a contributing factor to that. In addition, LMSs reflect a historically centralized and one-size-fits-all approach to providing organizational learning.

Modern learning approaches call for a decentralized, more personalized, less LMS-centric environment, although the core functions offered by an LMS remain very relevant for many organizations.

In an xAPI ecosystem, a learning record store, or LRS, is the database that accepts, stores, and allows for retrieval of xAPI data. The Advanced Distributed Learning group in the US Department of Defense (the same people who created SCORM) offers an LRS conformance test suite that vendors can use to certify that their LRS meets the xAPI specification. This conformance certification provides organizations the assurance that the LRS will handle data in the interoperable way that is understood by the industry. Most commercial LRS products offer data analytics and visualizations that go above and beyond the specification, allowing L&D teams to get the most out of their data.

Note that some eLearning authoring tools use earlier versions of the xAPI specification. Several commercial LRSs will accept these older statements, even though doing so is technically non-conformant. Careful consumers will ask both the LRS vendor and the authoring tool vendor about supported versions—and make their choices accordingly.

How do these two systems work together in an xAPI-enabled environment? There are a number of possible approaches to deciding whether and how to integrate xAPI with an LMS:

  • LMS with LRS inside: An LMS with the xAPI LRS alongside the SCORM and AICC databases that are likely already there offers a very simple all-in-one solution. In this environment, the LMS provides hosting, centralized search, and the dynamic data about people, their job roles, and reporting structures; these provide additional context for xAPI activity.
  • LMS is an activity provider: Some LMSs are choosing to adopt xAPI by becoming activity providers themselves, sending information about course activity, completions, enrollments, and other LMS functions—including data about instructor-led and virtual classroom sessions—to any compatible external LRS.
  • LMS with LRS alongside: Barring any activity from the LMS with respect to xAPI, implementing a “sidecar LRS” allows the L&D team to begin using and gaining from xAPI while maintaining the structure provided by the LMS.
  • LRS only: For organizations that have very simple requirements around managing learning and learning assets and no compliance requirements, an LRS-only approach is very simple to implement.
  • LRS with BI: Organizations with strong business intelligence functions will likely choose this route. In this case, the LRS is the clearinghouse for all L&D data, and it exports data to the BI software for further analysis with business data.

The fluidity of data in xAPI allows for more connection among learning platforms than ever before. This means that in more complex environments with several LMSs and LRSs, a single “binding LRS” can be used as the single source of truth—the master record from which audit reports can be run.

As Spider-Man’s Uncle Ben says, “With great power comes great responsibility.” With xAPI, that wise saying could be adjusted to: “With great interoperability comes great responsibility.” xAPI affords the challenge—and the opportunity—to rethink how L&D’s infrastructure supports the business. Explore the possibilities of an xAPI-enabled ecosystem at xAPI Camp, a co-located event with The eLearning Guild’s DevLearn 218 Conference & Expo, Oct. 24 – 26 in Las Vegas. Be sure to visit the xAPI Central Showcase in the Expo Hall.

More Management

You May Also Like