General architecture for a SCORM 2004 LMS implementation
Part 1

Claude Ostyn
Version 1.0.2
Copyright © 2005, 2006 Claude Ostyn
This work is licensed under a Creative Commons Attribution-ShareAlike2.5 License

This are working notes for part 1 of a multipart document. The other parts are not publicly available yet. The plan for the other parts includes topics such as user interface considerations, client/server implementation considerations, use of XML, and auditing.

Part 1: Functional overview

Functional components and services

There are many ways to implement a SCORM 2004 conformant LMS. However a fully functional LMS includes a number of features that are beyond the scope of SCORM. A useful way to manage this complexity is to look at a practical LMS implementation as consisting of several main functional components. The components are not listed in any particular order:

• Content repository
• Delivery management system
• SCORM 2004 conformant delivery system (a.k.a. Runtime Environment)
• Historical tracking information repository
• Learner administration
• Objective tracking (a.k.a. Lightweight Competency Management)
• General administration (including reporting and notifications)
• User portal (what a user sees when not actually experiencing a SCORM package)

The functional components may be implemented as cooperating services, or in a monolithic implementation. A services based implementation allows the ability to update the components independently. Also, architecting as a services-based implementation facilitates the creation of integration interfaces, e.g. to integrate the learner administration component with an HR system.

Other services and enterprise integration

Obviously learning and training is not limited to SCORM content. A practical LMS will often need to include services such as:

• Scheduling of offline learning activities, such as classroom instruction
• Scheduling of facilities and resources such as physical or virtual classrooms and equipment or software tools
• Gradebooks or similar means of tracking learner information in instructor-led learning contexts
• Online virtual classrooms
• Various synchronous or asynchronous collaborative learning tools, such as chat rooms, shared repositories for work products and resources used in group learning, wikis, help desks for expert advice on specific topics, etc.
• Performance support, including reference libraries and help desks
• Digital reference libraries for research or exploration, not necessarily tied to specific performance goals or targets
• Collaborative learning facilities, such as multiuser simulation or game environments.
• Personal portfolios

Also, increasingly, enterprises are looking at learning management as only part of a larger enterprise context in which human performance is managed to align with business goals and priorities. So, the LMS may be integrated with a competency management system that may include competency models, assessment processes and workflows, individual and group competency records, and various management tools to create, manage and mine competency information and facilitate alignment with business drivers.

Educational institutions have their own requirements. Some functional features that mesh with academic traditions, priorities and methods can be significantly different from those in a typical enterprise.

This document describes only the basic LMS functionality that is assumed to surround the management, delivery and tracking of SCORM based content. The other services and integration requirements are best described in separate documents with a broader scope.

Content repository

This is where SCORM packages are imported and stored for delivery. The basic repository features include:

• Ingest process: Import, unpack and validate a SCORM 2004 package and store in a virtual or physical directory structure.
• Maintain a catalog of imported packages. The catalog allows listing and searching. The catalog may use a subset of LOM metadata.
• Extract metadata upon import and add to repository catalog, allowing minimal review/editing of metadata and completion of missing metadata.
• Make a package available to the delivery management system (design to determine whether this is either in native form, or in a form pre-massaged for ease of delivery)
• Maintain access permissions and provides access only as authorized. This supports workflow, in which a package that is being imported is not available until import is completed and the catalog entry is validated by an administrator. It may also support segmentation of the repository (e.g. different users have access to different types of content, or a content area may be restricted to users with certain privilege)

Support for remote content

SCORM content packages delivered by the LMS may reference learning objects that reside on remote servers, or the LMS might launch content packages that reside on remote servers. Because of the security constraints imposed by Web browsers to prevent cross-site scripting exploits, such remote content must appear to be coming from the same server of the LMS. This typically requires some infrastructure level implementation to allow the LMS server and remote content server to appear to be the same host.

Delivery System (a.k.a. Runtime Environment)

This system provides the learner experience for a SCORM 2004 package. It manages the sequencing of the package. As a learner attempts to use the package successfully, this system manages the attempt. It also collects and maintain tracking data until the attempt is completed. The Delivery System is split into a server-side component and a client-side components.

Server side component

• Delivers a single attempt on an activity tree on behalf of the Delivery Management System. The attempt may be suspended and resumed in a later learner session.
• Instantiates the client side component (frameset and the original content of the frameset) for delivery in the client side browser
• Receives and responds to communications from the client side component.
• Maintains state for the activity tree and sequencing state.
• Maintains state for each activity, including communication data model data that persist between sessions
• Requests persistent storage of suspend data as needed from the Delivery Management System.
• Offers system global objective status data to the Objective Tracking system, and gets global objective status data from the Objective Tracking system.
• Offers historical tracking data to the Delivery Management System on an ongoing basis, or at least before discarding the data at the end of an attempt on a SCORM package activity tree or sub-activity.

Client side component

• Typically consists of a persistent frameset that displays the runtime environment user interface components as well as the sequenced SCOs or Assets in a "stage" frame.
• Includes the ability to send and receive data from the server side component without affecting the frameset itself or the stage frame. Some of the data may be fairly large (communication data model instances and/or runtime environment user interface data, such as the user's view of the activity tree, updated according to sequencing rules)
• Manages the communication session for each SCO that is being launched.
• Implements an API object that responds synchronously to the API calls from the SCO.
• Sends data reliably to the server side content in response to API "Commit" calls that may come in rapid succession or be widely spaced.
• Implements minimal user interface components as listed in SCORM 2004 S&N book.
• Implements a way for the user to inspect and navigate through a "tree of activities" that is updated dynamically to reflect the current state of allowed or visible activities, and which allows the user to choose activities randomly when allowed by the sequencing rules.
• Manages display of interstitial state content "between SCOs" as necessary; for example, prompts the user for choices when the sequencer encounters a choice situation with no default flow control mode to guide the choice toward a specific activity.
• Attempts to manage gross user errors such as attempts to close the browser before server side data has been committed.

Delivery management system

The delivery management system keeps track what is being delivered and for whom, and manages the persistent state of SCORM data between user sessions and user attempts.

• Provides minimal management of user "attempt registration" status, e.g. maintains relevant state info as long as a user is "registered" for an attempt on a SCORM package.
• Prevents multiple concurrent registrations by the same user for the same package.
• Negotiates with repository for access to the content package to be delivered by the Delivery System.
• Instantiates the Delivery System when the user is ready to experience a SCORM package.
• Prevents multiple concurrent instances of the Delivery System for the same user.
• Maintains state data on current attempt, including maintenance of the temporary persistent storage for the complete suspended state of an activity tree and its sub-activities.
• Offers historical tracking data to the Historical Tracking Information Repository on an ongoing basis, or at least before discarding the data at the end of an attempt on a SCORM package activity tree or sub-activity.

Historical tracking information repository

The historical tracking information repository maintains historical records of past attempts to use SCORM 2004 packages. It may also maintain current records that are subject to update until "finalized". Note that the SCORM does not define any requirements for the management of historical records, except for the status of certain objectives declared in content packages (see below).

• Provides structured access to viewing or reporting services that are used to review learner and/or package activity records.
• Accepts records of SCORM Activity tree sequencing status data model and individual activity status data model (IEEE 1484.11.1 data instances)
• Manages storage and indexing of the data records (keyed to learners IDs, package IDs and attempt number)
• Manages aging and archiving of aged data (storage space management, hierarchical storage, etc.)

Learner administration

The learner administration scope of complexity may vary considerably, depending on the level of integration with enterprise systems. The SCORM does not define any requirements for learner administration, but obviously this is a key component of a practical learning management system. At a minimum, the learner administration provides services such as:

• Provides a means to register users or relate to existing user data.
• Provides a means for learners to self-register for learning activities that use SCORM packages, if allowed by enterprise policy.
• Provides a means for managers of the learning process to assign learning activities that use SCORM packages to users and to set constraints on those learning activities, such as number of attempts allowed or deadlines.
• Provides a means for learners and managers to view the status of assignments and review tracking data and summary results.
• If groups are supported by the LMS, provide similar services for a group as for an individual user, as well as administration of group membership.

Objective tracking (a.k.a. Lightweight Competency Management)

This is a lightweight system that manages the status of objectives associated with a learner. SCORM 2004 has a concept of "system global objectives" for which the status is maintained across attempts and across SCORM 2004 packages. This system may be built into the Delivery Management System or be a standalone component, or a service provided by a real competency management system.

This system:

• Stores objective status for users in the form of "competency records"
• Provides the Delivery System with current objective status data, if available.
• Receives updated objective status data in the form of "evidence records" with the source of the data change (e.g. SCORM package, attempt number, timestamp) and updates the current competency records or propagates the information to "official" records according to administrative policy. For example, if policy is that an employee's competency records cannot be directly modified by a SCORM course without review or vetting, the status that is persisted for SCORM does not automatically propagate to the official competency records but a change of status may result in a workflow event to request review and update the official competency record.

General administration

There are three major components of General Administration:

• General glue
• Authentication and Authorization
• Reports

General glue

This is the "glue" system that a system integrator uses to tie together the different components and services of the LMS.

Authentication and Authorization

This may include user authentication and single sign-on management, role management (e.g. unrestricted administrator, learner, repository administrator, learning management administrator, etc.) and role associations (e.g. managers can only view reports on the employees they supervise). This system can be arbitrarily complex, and when the LMS is a good candidate for integration with existing enterprise administrative management systems (LDAP, Active Directory, etc.). A basic implementation might implement a very minimal rights and authentication system with a very small set of roles, such as: Administrator and Learner.

Reports

Management wants reports. Reports are typically required to monitor whether the enterprise goals are being met by the LMS, and to identify problems that may occur in the system or with particular users of the system. Extracting and massaging usage, status and tracking data requires the design of reports, or at least of some generic query interfaces or guidelines.

Notifications

A practical system often includes some kind of notification mechanism, typically using email. The SCORM does not define any requirements for notifications. A well designed notification system removes the need for concerned users to log into the LMS to receive notices that concern them. A notification system might provide periodic summaries for administrators or faculty, alerts sent to learners when a new course is being offered, alerts sent to learners when a deadline approaches to register for a course or to complete a course, confirmation of successful completion sent to a learner, or alerts sent to LMS administrators when abnormal conditions are detected, such as security alerts, storage limit alerts, or abnormal usage patterns.

Security and privacy

Beyond authentication and authorization as described above, a practical system typically includes security features, such as encryption of sensitive data, logging of events with security implications, administrative oversight procedures, and user interfaces provided to learners and managers only through a secure SSL session in approved browsers. Most LMS are operating in a context where new requirements for privacy and auditability may be imposed by law.

User portal

This is the set of services and/or components of user interface that allow a user to interact with the LMS. The LMS might have its own portal, or might be integrated in an enterprise knowledge portal or workflow system. For example, direct access and launching of SCORM packages might be taking place in an embedded performance system, where the entire LMS only appears as a link to a tutorial embedded in the reference that pops up when the user requests help on a task. In an enterprise portal, the LMS is typically embedded among other enterprise specific offerings available to authorized enterprise users.