Tech, People and Systems

The article below was written for an internal audience to illustrate the potential of the Experience API (Tin Can API). This brief overview contains narrative descriptions of four use-cases.

Disclaimer

The use-cases described below illustrate projections and opportunities that could help to resolve some organizational challenges. The use cases described below do not represent plans. This article doesn’t necessarily represent the viewpoint of the U.S. Coast Guard or the Department of Homeland Security.

The DoD ADL Initiative is working on a set of technology interoperability standards to enable training and learning systems. This new set of standards is called the Training and Learning Architecture (TLA). The first technology standard to emerge from the TLA is the Experience API (XAPI) also known as the Tin Can API. Differing from current systems that focus on connecting content with systems, this standard creates a language and technology framework that focuses on connecting people with systems. More specifically, the Experience API enables systems to capture the actions, activities, experiences, and accomplishments of people.

What benefit could this new standard provide the U.S. Coast Guard?

• The USCG maintains systems for capturing and reporting data that include formal competency and qualification systems. The XAPI could provide improved responsiveness, efficiency, and decreased costs by capturing contextualized performance and proficiency data while making the connection with mission accomplishments in real-time.
• The USCG is a deployed and distributed service. This broad distribution poses challenges. Unlike SCORM, the XAPI is designed to track experiences from anywhere. This could provide opportunities for capturing, queueing, and reporting accomplishments and readiness indicators from deployed and disconnected platforms as well as mobile devices.

As we move to integrate a DHS-wide LMS, we must consider this technology as a way to improve how systems work together to increase proficiency and mission readiness across the organization.

Background

The USCG is a learning organization. Training and mission rehearsal are universally understood as pillars of mission success. Like many organizations, whether it’s training or operating, the USCG is always preparing for the next mission.

This level of mission preparation is expensive and challenging. This challenge is compounded by the nature of our distributed and deployed organization and further complicated by information systems that don’t always connect or communicate. Sub-optimized and marginally compatible systems can create isolated information channels and stove-piped data streams. Many of the research and data call activities we pursue within FORCECOM are only necessary, in part, because we contend with many opaque and insulated information systems.

What would the XAPI look like in Coast Guard contexts?

At its core, the Experience API is a language and structure designed to enable systems and people to express accomplishments and activities. This structure enables the capture of activities at multiple levels of granularity and in practically any context. The core structure of an activity statement is simple.

Imagine a system capable of capturing anything people experience and accomplish within an organization, wherever they are and at any level of granularity from an accomplishment down to a moment of an experience. A system that captured these moments manually or automatically in a language that can be read between systems to provide a complete picture to the individual, to the unit, or to the organization.

Now take the picture of accomplishments and experience formed by new data opportunities, and extend that data with new adaptive system features that predict and suggest individual or unit performance interventions to improve mission readiness. The four vignettes below illustrate how the xAPI could be employed in Coast Guard readiness and career contexts.

1. Progress towards proficiency underway

While preparing to qualify as OOD, BM2 Struthers accesses practice activities and assessments using a mobile device while deployed at sea. The device stores her completion data and synchronizes with a shipboard appliance when she is in range. In turn, this appliance connects with a regional data store when connected to a shore tie. The BM2 uses the device to complete courseware, study for the servicewide, and complete PQS items as she pursues qualification for various positions at the unit. Each accomplishment and experience is captured and forwarded through an occasionally-connected system. The BM2 and her Unit Command have access to a complete and detailed picture of her progression toward proficiency. The standard has enhanced information services to the unit and the member. The BM2 knows exactly where she stands in her progression. She progresses faster with integrated reference and training resources within reach.

The matrix of data provided through the record store helps to validate databases of competency models associated with the BM2’s position and occupation. A data trend from all BM2’s is used to flag a task review prior to occupational analysis, notifying the RFMC and Program Manager of a task trend that could impact resident training and qual decisions.

Access to content, support and feedback wherever you happen to be from a device you carry with you. This is likely something many of us already do outside of work. The organization has talked about distribution to devices for more than a decade. Many problems contribute to the challenge of making deployed systems work. A new technology standard and language may help to solve the disconnected measurement problem.

2. Connect logistics, human performance, and the mission

Imagine that the CGC Skywalker just received a new RADAR system. This RADAR System, designed by the Navy, has integrated the Experience API and connects to the ship’s maintenance reporting network. The RADAR system reports status updates to a centralized system using the Experience API. One evening, the system reports a malfunction. The OOD wakes the duty technician to remedy the fault. The technician enters his identification code and proceeds to repair the system. The system automatically generates a history record indicating its new status and the identity of the technician that made the repair, creating an experience record for both the system component as well as the technician.

Across the organization, a stream of experience records are generated by connected systems, creating a system of connected moments that tell the story of Coast Guard performers accomplishing work. Months later, the occupational analysis team includes this data when examining the design of the job of a technician. The product line uses this data, along with other sources, to plan for lifecycle sustainment and update maintenance procedure cards. The schoolhouse uses this captured accomplishment data to update curriculum. Each technician’s supervisor accesses the stream to support enlisted performance evaluations.

By painting a complete picture of performance and closing the loop between systems and people, we can make better decisions about where training might be required and where the answer is somewhere else entirely. We maintain trends of equipment faults in closed and isolated systems and it’s often difficult to make the connections when there may be a performance deficiency or an equipment deficiency. The Experience API provides the opportunity to see the experiences, events, and moments of people and machines in a unified view.

3. Create a map for career progression

To help people progress through a career and create a trajectory of success, both the individual and the system need to know three things.

• Where does the member need to be? Where does the member want to go with their own capability and career?
• Where is the member now?
• What has the member done already?

The Experience API provides a language structure to enable capturing, assessing, and communicating where the member needs to be, where the member is, and where the member has been. More importantly, the API provides a structured language for systems and people to express and capture these streams of accomplishments and encounters.

The member and the organization have the opportunity to see the member’s trajectory with the aid of feedback. This feedback may increase momentum.

4. Unshackle content from the LMS

Tracked learning experiences are traditionally imprisoned within the LMS. This can creates a narrow field of expectation for what a learning experience can and should be and reduces the incentive for participants to return to content as a performance support.

Experiences within the LMS tend to be isolated from the environment and context of work. Rich learning experiences across device platforms can be challenging to implement on a SCORM LMS, particularly when the device is only ocassionally connected. The Experience API unshackles content from the confines of the LMS, enabling learning experiences to take on different forms by removing the limits imposed by LMS rules and expanding the types of activities that can be captured.

The system is designed around modular and far simpler Learning Record Stores (LRS) that can be connected or deployed to feed data streams to other systems including HRMS, LMS, and CGBI. This means it likely will be relatively inexpensive to deploy an LRS to each ship in the fleet to maintain a “sometimes connected” capture capability.

The challenges and opportunities we encounter every day call for a new generation of interoperable tools. xAPI presents an opportunity to make those tools real.

For more information…

Several articles have been published in the past months expressing support for and apprehension surrounding the new standard. A few of these articles and resources are linked below.

• USCGHPT Presentation (PPT) and video with Aaron Silvers and Steve Flowers
• There are Stories to be Told by Megan Bowe
• Why Aren’t We Talking About Content by Megan Bowe
• Three Reasons Instructional Designers Need to Know about Tin Can by Julie Dirksen
• Easy as ABC by Andrew Jacobs
• This is why I am very scared about how the new Tin Can API will be sold to businesses, a response by Tim Martin from SCORM.com
• Kicking the Tin Can by Guy Wallace
• Branch.com response to Kicking the Tin Can

Postscript – Three Years Later

Almost three years later, the stories outlined in the article could still hold up. These aren’t situations that an LMS or any other system fielded at the time could handle well. New systems, tools, and design approaches have emerged each year since this article was drafted that could take on the challenge. A strategy that includes flexible, interoperable, and modular tools like LRS and activity providers could help to paint a complete data picture for how people relate to the systems in which they learn and work. In turn, this data could be used to fold back and build smarter systems and tools to support work and learning. We just need to step beyond the boundaries of conventional thinking to make them work!