David recently met up virtually with Dr Wolfram Jost of imc Learning to discuss the concept and solutions around the headless LMS, which is growing in importance – particularly for large organisations going through digital transformation.
Dr Wolfram Jost has been a board member and Chief Product Officer at imc since April 2019. Over the years, Wolfram had prominent roles within other software companies and now brings his passion for learning, development and technology to imc.
What do we mean by headless?
The headless CMS is a well established and proven solution and now most of the core applications found in modern organisations are increasingly going headless. This holds also true for the learning management system (LMS).
In an earlier article on this subject, we described what a headless LMS could do. Headless LMS and CMS allow for content to not only to be published to a website or primary platform, but also across a range of channels.
The system does not have an out of the box experience layer (single presentation layer) – as it is ‘headless’. Access to the system functionality and data is only provided by predefined APIs.
Here we take a deeper dive into the headless LMS with Wolfram, who shares his thinking around the headless LMS and takes us to the next level of detail.
Headless everything
While there is a plausible argument that all LMS are largely the same (in their relevant market sectors of course) and that the SAAS model enabled by the cloud has forced it into this mould as it has limited the LMS customisation abilities to meet organisational needs, the desire of organisations to customise, configure and integrate their LMS with other systems has not gone away.
So, even though ostensibly a vendors deployed LMS should be the same time and time again, the reality is that they are often just somewhat similar and increasingly quite dissimilar. Configuration capabilities and customisation possibilities are increasingly becoming the key differentiator in the mid corporate and upwards LMS market, and the biggest of these differentiators is in Learning Light’s experience; integrations.
This integration requirement is becoming more and more common in large corporations with sophisticated tech stacks and includes CRMs and ERPs as well as LMS and HRIS all with a lengthening list of configurable options being implemented and with an increasingly sophisticated integration being required. In short, it is becoming more and more difficult for LMS, HRIS, CRM and ERP vendors operating in the large corporate market to meet the clients UI and UX requirements out of the box.
The desire to integrate CRM, HRIS, ERP and LMS into these platforms is being met with the accelerating use of APIs. However, this trajectory of the very natural (and probably business critical) yearning of organisations to have bespoke UI’s (user interfaces) and UX (user experience) across multiple systems means that their learners experience is aligned to the organisational requirements.
There needs to be some serious re-thinking in how these API integrations are managed as the increasing interdependencies between systems are actually preventing progress. There is a danger that we are rapidly running up to a hard stop unless the manner by which APIs are used changes. In short, a new API mediation layer is needed and a new concept of how these applications operate is required.
So, I am very grateful to Wolfram Jost in sharing his views on this challenge.
But first, what has this to do with the concept of the headless LMS? Well, the LMS and pretty much everything else in large corporate tech stacks will become headless and will be based around a micro-services architecture. This means that the possibilities for integrations are considerable and the requirements for APIs to handle these integrations are vital.
Low code development
So, secondly to make these API integrations not only possible, but realistic, Wolfram highlights the role of low code application development platforms (using metadata discovery) which will develop and access APIs quickly and easily. It is these APIs, (that crucially do not need programming expertise to create) that will generate the bespoke integrations between systems.
The user experience will then in effect be created via an API gateway between systems. The use of low code application development platforms will allow organisations to undertake this work themselves and create APIs independently of the CRM or HRIS etc… The dependency requirement between systems (and their support teams) in need of integrations is effectively eliminated.
Low code development means that a visual approach is used and those that understand the business needs (a business architect) can create the the user experience and APIs without the necessity for IT specialists. Systems can now work together in theory. The question now is how does this look like practically?
The publisher-subscriber model
Well, we are back to our headless concept with each system component acting as a publisher capable of sending information to any other system, not just publishing/presenting through one interface. And likewise, each system in the stack is now also acting as a subscriber, capable of asking for information from other components of the tech stack.
In effect, every system is headless for information coming in and going out. The APIs created in the low code development platform are making this all possible.
Event driven architecture (eventing)
The headless concept is in effect able to create an event based or event driven architecture and not a monolithic block with one tightly integrated system trying to centralize all the data from all the applications. The APIs ask for the information required… “can I have a catalogue of learning in the CRM addressing selling skills, and when it is updated tell me again”.
Business architects can now create user experiences and user interfaces linking systems together and of course still exercise configuration options in systems as well. In fact, the UI and UX is becoming increasingly self-service for the client and those key differentiators around integrations are made possible.
Is the library of APIs offered by vendors becoming redundant? Well not yet, but the potential for organisations to create their own custom APIs and effectively bespoke their headless LMS is now very real.
The API mediation layer
Wolfram goes on to argue that the API layer must now be managed so one developer does not damage the whole construct. The API mediation layer brings order and enriches the interactions between the different components of the tech stack, our publishers and subscribers, thereby managing the looser connections that enable making those event driven actions possible.
If you are just using a small number of APIs you probably do not need to worry so much about this, if you are using a larger number of APIs an API Mediation layer is going to be needed as the one size fits all API will no longer be capable of meeting the growing number of integrations.
So, for the corporate market the headless LMS will become a key part of the tech stack. In case you are wondering what this approach looks like in reality, while LMS vendors have been putting a huge amount of effort in replicating the Netflix look and feel, it was the clever use of individual APIs and the API mediation layer that has allowed Netflix to deliver its UI across multiple different devices.
Dr Jost is one of a number of leading training and technology experts at imc – a company that has impressive pedigree and longevity in delivery elearning solutions to many of the world’s top brands.
You can learn more about the imc Learning Suite and the wider company over on their website.
