Compliance: What CLOs Should Know

By now, it is a cliché to say that the rise of the Internet, e-mail and World Wide Web a decade ago revolutionized virtually every field of human endeavor. During the first half of that decade, early adopters experienced problems that today

What made these and other advancements possible? Standards. To appreciate the pervasiveness of standards, imagine how inconvenient life would be if wall sockets were designed as randomly as potato chips!

By embracing standards, e-learning can foster market maturity, but what would such maturity look like? Dan Rehak, a professor at Carnegie Mellon University and contributor to multiple e-learning specifications, views standards as essential if the learning function is to begin focusing on human capital development as opposed to today’s nearsighted emphasis on tools and interoperability. Broad, deep and ubiquitous standards compliance that promotes tool- and vendor-independence would allow human capital investments to zero in on subject-matter expertise without undue concern for technology shifts and skill-set retooling.

According to Rehak, positive byproducts of this evolution will be “the emergence of common paradigms for how content is put together, which are independent of any subject-matter expert or tool. Learners, too, will begin seeing patterns in how content makes pretests, navigation, remediation paths, auxiliary help and supplemental reference material available. In the process, they become better learners.” So, a mature e-learning field will realize efficacy and cost savings driven by freedom from technical, user interface and process issues.

With assumed reliability and perpetual availability, it is human nature to overlook things that are standardized unless exceptional circumstances call them to our attention, for example, lack of a dial tone when using a landline telephone. Perhaps it is also human nature to lose sight of the broad forces from which standards emerge.

In organizational development circles, discussions of how groups arrive at a modus operandi for getting work done often include the phrase “stormin’, normin’, conformin’.” At first, many proposals are proffered resulting in a chaotic state of affairs. Over time, a handful of proposals emerge as contenders for the group standard. Finally, a great leap in productivity occurs when a single proposal wins out and all players agree to support it.

In the standards world, this “stormin’, normin’, conformin’ ” phenomenon is roughly analogous to the evolution of specifications into standards. Specifications are subject to change as new ideas are proposed and experience is gained from their implementation. Players share these experiences, and the specifications undergo revisions on their way to standardization. Once a specification becomes a standard, it is considered stable, and it is unlikely to change for several years. If changes do occur, they are modest or incremental. Standardization takes place when a formal standards body like IEEE or ISO officially ratifies a mature specification as a standard. For this article, we use the term “standard” generically unless “specification” is called out.

Given that e-learning as we know it today is an offshoot of Internet technologies, it is by definition an immature industry subject to stormin’ and normin’. Any immature industry is necessarily dealing with concepts that are new to its stakeholders, while players in the standards community strive to shape standards in ways consonant with their own visions and agendas. This swirling interplay of abstract ideas, common interests and individual agendas makes it difficult to achieve consensus on baseline features of a specification. Furthermore, articulating the essential characteristics, benefits and requirements of a specification can be challenging.

So let’s cut to the chase. Why are standards important to a chief learning officer? Ultimately, a CLO wants to report to a CEO that the firm’s business objectives are being met by the investments it makes in learning. Implicitly then, “content is king.” Getting the right content to the right person at the right time is key to the learning function fulfilling its promise. As such, AICC (Aviation Industry CBT Committee), SCORM (Shareable Content Object Reference Model), IMS Content Packaging and the IEEE Learning Object Metadata standards take center stage.

Elliott Masie of The Masie Center said, “CLOs understand that without standards there will be problems. It is therefore a ‘no-brainer’ that CLOs require people in their organization to procure content and tools from vendors that can verify their support of standards that this is ‘how we buy.’ ” (See Figure 1, “CLO’s Checklist of Standards Compliance Questions for Vendors.”)

By the same token, Amy Finn, chief learning officer at Centra, said, “CLOs need to have a healthy skepticism about what standards can actually do.”

Recall that the AICC and SCORM specifications are subject to change as well as differing interpretations by vendors. Furthermore, standards are difficult for laypeople to understand. Few learning management system (LMS) vendors provide workshops on how to implement standards, and content providers have a vested interest in not sharing detailed knowledge gained from successful integration efforts.

Even with the most mature specification, AICC, skepticism is warranted. Its original incarnation dates back to the days of computer-based training (CBT) when LMS products used Windows INI text files rather than databases to keep track of learner progress. To this day, AICC seeks backward compatibility with LMS products of that era. Some modern LMS vendors adhere to the letter of AICC law despite running on industrial-strength databases. The implications of this become clear by understanding the tradeoff that backward compatibility dictates.

From the standpoint of an LMS programmer, as tracking calls from content are received, it is far more difficult to modify portions of an existing file than it is to overwrite it entirely. When many requests arrive simultaneously, such piecemeal handling of a file leads to corruption. The workaround AICC came up with places a burden on the content developer that requires a course to supply all learner progress information generated in the current session, even if the delta of new or changed information is small. Let’s refer to this distinction as the “the tile versus the mosaic.” To a content developer, it is unintuitive to continually post a mosaic of information when learner activity is only modifying a single tile’s worth of data. With tight coupling of authoring tools and LMS products from a common vendor, some learning management systems accept tiles when a mosaic is required. This can give the content vendors that are using these authoring tools a false sense of security that is shattered when they encounter an LMS expecting mosaics.

As feedback of this kind reaches the standards community, inventory of known solutions is taken so that a specification can be revised for the benefit of all. Over time, what looks like a good solution at first can turn out to have unforeseen consequences. AICC sought to resolve the tile-versus-mosaic issue by providing an elegant and simple application program interface (API), which institutionalized the tile and greatly clarified how content should be programmed. This API, written in JavaScript, is expected to manipulate an LMS-supplied “API adaptor object” (usually a Java applet) that handles whatever low-level string handling is needed for communication with the LMS. This change marked the transition from AICC version 2x to version 3x. Both versions are in widespread use today. However, the API approach was considered such an improvement that stewards of the SCORM specification adopted it as their official runtime environment. (SCORM is part of the Department of Defense Advanced Distributed Learning Initiative and as such, collects and extends other standards for the benefit of its constituents. See Figure 2, “Standards Overview: AICC and SCORM.”)

Experience has shown that this API works fine when the content and the LMS reside on the same server. However, when they do not, Web browsers prevent JavaScript from communicating with the API adaptor object. Browsers do this to maintain the integrity of the desktop and to prevent servers from using content objects in a browser as conduits to other servers. Whether the LMS server and the content server are behind a common firewall or a mixed deployment is in play, browsers apply the same rules. While the simplest solution is to place the content on the LMS server, there are reasons to avoid this approach. If placed on separate servers, IT can better manage user and group permissions since the populations handling content and administering the LMS are likely to have different access profiles. In addition, with separation, the LMS and the content do not compete for common Web server resources and slow each other’s performance.

Several LMS vendors have come up with their own solutions to this problem. A standardized solution is not likely since each customer environment has its own IT culture that impacts what tradeoffs it will find acceptable. Still, to its credit, SCORM will publish a list of solution descriptions it culls from its LMS and content vendor membership. This will appear in its 1.3 specification due out in early 2003. This enables adopters of SCORM to proceed without having to change the way they develop, deploy or procure content.

An area common to SCORM and AICC fraught with integration dangers is the extent to which an LMS implements the data model of a given standard. A data model constrains what the content and the LMS are both expected to know about the learner (for example, score, status, bookmark, etc.). For several LMS vendors, implementing those parts of the data model that track interactions, objectives, student data and student preferences tend to be tricky. So far, relatively few content offerings make use of these data groups, and defects go unnoticed longer than would otherwise be the case. It is only in the past couple of years that content started routinely implementing tracking that utilizes these more esoteric parts of the data model. Note that SCORM 1.3 will make all fields in the data model mandatory for an LMS to support, whereas now many fields are optional.

To facilitate integration, LMS vendors are setting up online “content labs” where partners can test for interoperability, 24×7. To defray costs associated with content integration, some LMS customers require their content vendors to successfully “pass the lab” before allowing the content on-site. The ADL Co-Lab is expected to begin providing SCORM certification testing services in 2003. Similar services are under consideration by the IMS project as it relates to those specifications under its aegis.

Even with new interoperability test environments springing up, CLOs need to take inventory of all content development and procurement activities in the enterprise so that efficiencies from shared content design, re-use, storage and maintenance can be realized.

This introduces the idea that some discipline on the part of the standards adopter is needed in order to make it work. While decentralized development with widespread adoption of internal and external standards is feasible, without widespread standards awareness, decentralized content development efforts can lead to waste and duplication.

In the view of Jan Ginneberge, chief learning officer for Alcatel, even with interoperability issues resolved, “in the short run, standards foster efficiency over efficacy.” When used successfully, they provide a framework for base-level service that the learning function can provide its customers. Ginneberge said that having a realistic view of what is feasible helps CLOs properly set expectations among the various organizations in their enterprise. Still, Ginneberge believes that over the long term, standards can impact effectiveness. “Once interoperability issues are ironed out and content is uniformly compliant across all offerings, we begin to move from the ‘information stage’ to the ‘learning stage.’ ” Ginneberge sees uniform content compliance as key to unlocking learning stage activities such as tutoring, teaching and remediation.

Beyond interoperability and re-use, getting the right content to the right person at the right time will require easy, efficient ways to tag learning objects using the IEEE Learning Object Metadata standard, competency profiles that link to content and its metadata and learning management systems that implement an instructional designer’s vision as expressed in IMS Simple Sequencing (to be included in SCORM version 1.3).

With an understanding of what standards address, their relative states of maturity and the practical realities surrounding their implementation, CLOs are empowered to demand more from their LMS and content vendors. Wise consumers of standards-compliant products promote not only their own competitive advantage but also drive the e-learning industry closer to market maturity, where its collective focus can move from tools and interoperability to the nexus of people and business strategy.

Eric Rosen is e-learning strategist and standards evangelist at Saba, a leading provider of human capital development and management solutions. Rosen delivers Saba workshops, white papers, working code and dedicated consulting to customers and partners worldwide. He can be reached at erosen@saba.com.


Figure 1: CLO’s Checklist of Standards Compliance Questions for Vendors

 





































Question


LMS


Content Tool/Course Provider


What standards are supported?


X


X


What certification or conformance tests do you list?


X


X


An inherent limitation in the SCORM API forces content and LMS to reside on the same server. Do you have any solutions that will let me place content wherever I like?


X


X


Do you provide prospective customers and content development companies with a test instance of your LMS?


X


 


In AICC or SCORM, certain datagroups are less frequently used so troubleshooting experience with them is scant. Can you demonstrate complete interoperability with respect to interactions, objectives, student preferences and student data?


X


Only if used in content


When SCORM moves to version 1.3 early in 2003, all data elements in the current model will become mandatory for the LMS to support. Will you support all of them at that time?


X


Only if used in content


Do you provide standards implementation workshops and support to customer in-house and external content developers?


X


X


Do you provide consulting in the areas of competencies, certifications, enterprise e-learning strategy, best practices in content development, deployment, re-use and template design?


X


X


 


Figure 2: Standards Overview: AICC and SCORM


 







































































Specification

AICC 2x

AICC 3x

SCORM 1.2

Full Name

Aviation Industry CBT Committee


Aviation Industry CBT Committee


Sharable Content Object Reference Model


Founded

Year

1988


September 1999


October 2001


By

Aviation Industry


AICC 2x


Dept. of Defense Advanced Distributed Learning Initiative


Adoption

Widespread


Rate tapering off. Legacy and new content


 


AICC 2x


Accelerating. Federal Government


sales requirement


Data model

(What LMS and Content Know About Learners)


Windows INI format


AICC 2x in dot syntax


AICC 3x (streamlined)


Runtime environment

(How Content and LMS Communicate)


HTTP AICC Communication Protocol (HACP)


ECMAScript* API


AICC 3x


Content Creation


Development Guidelines


General


Mandatory API


AICC 3x


Development Freedom


Broad


Narrow


 


AICC 3x


Developer Expertise 


High.


Low-level string handling required


Low to Moderate.


No low-level string handling


 


AICC 3x


Integration Failure


Moderate to High Probability


Low to Moderate Probability


AICC 3x


Course Structure


(Instructional


Design)


Orientation


Lessons Comprising Courses


AICC 2x


SCOs ** Doubling as Lessons


Metadata Files


Multiple. Windows INI, Comma Delimited


AICC 2x


Single.


XML



* ECMAScript is the ISO standard version of JavaScript.


** Sharable Content Objects



March/April 2003 Table of Contents