Sharebar?

Learning Impact Blog

IMS Global CEO Rob AbelRob Abel, Ed.D. | August 2021

 

"Get your motor runnin'" —Steppenwolf

 

What’s Under the Hood of Your EdTech?

Once upon a time, you could not only buy a muscle car, but you could work on pretty much every part of what makes it run. I think it’s likely that I’m in the last generation of humans who spent substantial time working on their cars when they were young, whether just for maintenance or fun. A key reason we were able to do this was that the designs of cars were relatively simple, with pretty much all “subcomponents” operating independently of one another. You did not have to mess with onboard microprocessors and extensive electronics to tune your engine or change your brakes.

But embedded computer tech has gradually changed the design of autos to be much more interconnected. My current car, for instance, is a hybrid. It is a performance car that automatically determines how to distribute power from gas and electricity to each wheel and adjust the suspension in real-time in response to the driver and conditions determined by access to data from many sensors.

My dad was an aerospace engineer. In the 1970s, he was involved in developing prototypes of hybrid engines for cars. Fifty years later, hybrids are everywhere, and it does not take much imagination to predict a predominance of electronic vehicles over the next decade or two. What’s under the hood has changed forever. Motivations for the evolution have included reducing harmful emissions and fuel costs. But the more integrated architecture enables the user experiences that sell cars.

What does this have to do with edtech?

First, we see a very similar evolution in terms of integration bringing value to the end-users. While the individual applications of an edtech design are important, more and more the user experience is how well the totality and built-in flexibility of the design respond to user needs. We're making powerful advancements like achieving digital on day one and enabling instructional innovation by making data easier to see, understand, and act upon. These interconnections are what enable faculty to teach and students to learn their way.

Second, as edtech evolves, the bar is going up for IT, academic, and product leadership when it comes to designing and ensuring the user experience across products. Once upon a time, automobiles had only a set of hardwired gauges each representing one signal for the user to monitor. The software products we know today as the LMS, portal, or single-sign-on system, are just the first or second generation of what will evolve to be a much more sophisticated approach to configuring the edtech experience at an institution and for each learner.

Another way to make this second point is that what is “under your edtech hood” is not just a list of what products you support (for institutions) or what specific integrations you support (for product developers). What is under your hood is the design of how users launch products, how context/user preferences are transmitted to each launched product, what progress indicators and data are generated, micro-credentials are awarded, where the outputs go, and how the outputs are expected to be used.

Candidate NGDLE Architecture

Candidate NGDLE architecture in relation to product categories that already exist in higher ed; taken from the EDUCAUSE Review article Shaping the Educational Technology Innovation Ecosystem by Rob Abel, Published: July 17, 2017

Source: Shaping the Educational Technology Ecosystem, EDUCAUSE Review, July 17, 2017

 

Third, the need to reduce harmful effects on the environment and keep fuel costs low is analogous to the need to achieve scale and agility without increasing cost.

If all of this sounds a bit “futuristic,” well, some of it may seem to be, but this is the road we’re traveling in IMS. The scaling of edtech and cost savings achieved from open standards-based interoperability in concert with a committed community that shares how they are making progress are reaping the rewards. The leaders in IMS can now focus more on that user experience design. For instance, during the pandemic, IMS members—institutions and suppliers alike—have been able to leverage what is “under the hood” of their edtech ecosystem to better configure experiences for end-users.

Going forward, intentionally designed interoperability, working across an institutional product ecosystem, is what will make or break the power of digital edtech for faculty, learners, and administrators.

We have come a long way and have a long way to go. But there is much that we can do today to improve user experiences by encouraging broader and deeper adoption of the work of the IMS community. Let’s take the next step of incorporating the full capabilities of LTI Advantage, OneRoster, QTI, CASE, TrustEd Apps, and Caliper for the benefit of our learners!

To learn more, I encourage that you register for our upcoming annual Learning Impact: Connecting the Power of the EdTech Community. IMS Contributing Members get two free registrations, and Affiliate Members get one free registration!

 

Tags:

 

IMS Chief Architect Dr. Colin SmytheIMS TECH TALK

Contributed by Dr. Colin Smythe, IMS Chief Architect

 

Compliance, Conformance, and Certification: Why Getting IMS Certified is Important

One of the benefits of IMS membership is having your certified products listed in the IMS Product Directory—the official list of all learning apps and tools that have passed IMS interoperability certification. A product must demonstrate support of one or more IMS specifications through conformance testing to appear in the directory. IMS awards each certification for 12 months, so every product must undergo successful recertification to maintain its listing. This 12-month cycle allows vendors to use agile development processes without requiring recertification for every product release. New major versions of a product must be certified. It is not unusual for several versions of a product to show up in the product directory. It is important to note that the product receives certification and not a deployment of the product.

The IMS Product Directory also includes products vetted for student data privacy using the IMS TrustEd Apps process. Many, but not all vetted products, have also achieved IMS standards’ certification. This blog focuses on the products that go through conformance testing for IMS certification.

Defining the conformance requirements and providing the associated conformance test capabilities are essential to the IMS specification development process. Each IMS specification must have a Conformance & Certification document. These documents describe the certification process and define the conformance criteria that a product must achieve for each available certification. Most specifications have more than one certification. An example of this is a service-based specification with certifications as a Service Provider and a Service Consumer (a product must be either or both). The conformance and certification aspects are addressed once the project group responsible for developing the specification publishes the Member Candidate Final documents. These documents are available to IMS members only. A minimum number of products must be certified before the Final Release of an IMS specification can be published. This means the document set is publicly available to everyone.

An IMS specification cannot have a Final Release until IMS members define conformance and certification and create and use the conformance test.

One objective of IMS certification is to demonstrate the level of adoption by vendors committed to open solutions to the market. When a new version 1.0 specification is first published, the conformance requirements are defined to encourage broad adoption. Over time the level of adoption will change, and the specification itself will evolve. Therefore, the IMS specification maintenance process allows for the certification requirements to be changed to fit the changing needs of a market—even when there are no changes to the functionality supported by the specification. Also, it is not unusual for the conformance testing to be continually improved. This flexible approach to certification is another reason why products must undergo annual recertification.

It is becoming more common for organizations to require IMS specifications as part of the procurement process. It is natural for vendors to claim compliance. From an IMS perspective, compliance is claimed by vendors who are not IMS Certified. IMS members can provide their IMS product registration numbers, and users can easily confirm their certification by a quick inspection of the IMS Product Directory. If support of an IMS specification is required, the tendering process should include checking the product’s IMS Registration Number. In most cases, the claim for compliance is wishful thinking and based on unjustified confidence in the in-house interoperability testing. Sometimes, it is a cynical misrepresentation. Buyer beware.

When products claim compliance but are not certified, there are two implications. First, the product has not been through IMS conformance testing. Usage of the IMS conformance test systems is essential in producing a correct implementation of the specification. In most cases, a solution goes through several iterations of conformance testing before being certified. There is no restriction on the usage of our conformance test system for IMS members, meaning they are not just for certification. Secondly, if there is a failure of interoperability when using the IMS specifications, the IMS certification requires the vendors to work together, and if appropriate with IMS, to resolve the problem. In some cases, IMS may have to: improve the implementation guidance, correct the specification, and improve the conformance test systems to avoid such incompatibilities in the future. Experience has shown that products that are not certified do not implement the corresponding IMS specification correctly. Superficially, they appear to work, but there will likely be many significant errors in the implementation.

Certification requires IMS membership. Is access to certification sufficient justification for IMS membership? Undoubtedly, YES!

IMS has invested millions of dollars in developing and supporting our extensive test and conformance systems and related artifacts. Five to ten full-time software developers are working on the various IMS test and conformance systems at any one time. Even the largest organizations see significant benefits in using the IMS test and conformance systems. A further benefit is that the IMS technical team provides a wide range of support to help IMS members adopt and adapt IMS specifications. As part of our specification development process, IMS creates the following testing and conformance artifacts:

  • Service Provider and Consumer conformance test systems (used for OneRoster, LTI, CASE, etc.)

  • Reference implementations of the full specification

  • Online validation of content instances (used for Common Cartridge, QTI, etc.)

  • Reference test sets for testing data import capabilities (used for Common Cartridge, OneRoster, QTI, etc.)

It is important to stress that all of these artifacts are available, for unlimited use, to IMS members. All of these artifacts are being continually improved.

While Certification is very important, it is product-focused and not deployment-specific. There is a limit to the degree of interoperability guaranteed through certification only. It is possible for two products certified for the same specification not to interoperate. For example, in OneRoster, there are both REST-based and CSV-based bindings, and interoperability between these is not possible. Therefore being certified alone is insufficient; the right type of certification is required for interoperability. The IMS Product Directory provides sufficient details to ensure the right type of certification is available. In the case of deployed systems, there are many different ways in which a certified system can be configured (this may also depend on the business model used by the vendor).

As the next step beyond certification, IMS has created the Compatibility Check (CCx), which provides the Characterization of a deployment. Furthermore, CCx enables characterizations to be compared. This means that we can compare the characterizations of certified Service Providers and Consumers to show all of the interoperable and non-interoperable features (including the usage of extensions). At present, CCx supports OneRoster and Common Cartridge, but it will be extended to cover many of the IMS specifications over time. I will go into more details about characterization and CCx in a later blog but understand that the characterization of products is the way forward. It is a far better measure of interoperability than certification alone.

 

Tags: