Data integration is an expected feature for many schools when they purchase new digital products. Given the new logistical headaches brought about by COVID-19, it's more important than ever for companies to nail down their integration strategy and provide a wider range of integrations.
LMS integration, in particular, has always been challenging for online learning platforms. In addition to requiring a ton of development effort upfront, it can place an ongoing burden on unsuspecting companies. This is development time that would otherwise be spent improving your core product. Since this is our bread-and-butter, here are our top reasons why LMS integration is harder than it looks (in no particular order):
1. There are a bunch of different learning management systems.
There are dozens of different learning management systems (LMS) and student information systems (SIS) available on the market. There are new ones coming and going every year. There are over 100,000 schools in the United States, and they all rely on some form of technology for their students and faculty to complete homework, communicate, and track grades.
With systems rising and falling in popularity, it can be hard for companies to decide which integrations to prioritize, and for companies to complete the necessary integration work in a timely manner. Just one integration could take several months. Add in 5 to 10 more and you're looking at years of development work - time better spent on your core platform.
2. There are many different ways to integrate with an LMS.
A major reason that companies never move forward with LMS integration is simply that there are too many options and not a lot of subject area experts to provide the necessary knowledge and guidance.
Companies suffer from classic analysis-paralysis. They send their developers off on a task like this: "A large district wants Canvas integration. Figure out how to do that." The developers quickly discover that Canvas has two different APIs, several supported versions of LTI®, QTI®, Common Cartridge®, and so on. Combined with a lack of good examples, thorough documentation, and the underlying worry that they will have to navigate this process for every LMS, many teams just decide to throw in the towel on LMS integration and get back to work on their core platform.
3. Each LMS has a different data model and different feature set.
Designing a system that is abstract enough to handle the data models in every LMS requires a significant planning and programming effort. Many online learning platforms were never designed to handle things like third-party authentication, contextual user roles, or complex organizational hierarchies.
Some LMS's have course sections; some don't. Some LMS's require user email addresses; some don't. Some LMS's allow the school administrator to define custom user roles; some don't. Understanding all of the unique edge-cases is a challenge in and of itself. Accounting for them in development is a different story altogether.
4. Some LMS's are cloud-hosted, and some are self-hosted.
Blackboard, Canvas, Moodle, and Brightspace are systems that can be hosted by a school or university on their own cloud provider like Amazon Web Services. When schools host their own LMS, you (the unsuspecting learning platform provider) are in for a variety of new edge-cases.
If you use the LMS for single sign on (SSO) or API integration, you'll have to take custom domains into consideration. Moodle and Canvas allow users to make custom modifications to their LMS as they're both open source.
Another major headache is that schools may be running a variety of different LMS versions. When schools self-host, they no longer receive automatic updates and have to release new versions to their students and staff on their own schedule. Some schools and universities can be running LMS systems that are years behind, and lack important features that your integration relies upon.
5. Onboarding clients who have an LMS can be a challenge.
School administrators are busy enough as it is and don't have the time to navigate a lengthy integration process. LMS setups vary wildly and there are dozens of different configurations that can be required between the various LMSs. Schools may self-host their LMS (#4) and some may use a vanity URL for their teachers and students to get quicker access.
In addition, most methods require the exchanging of sensitive data like LTI consumer and secret keys, or API client and secret keys. Generating these keys within the LMS and then sending them via email is extremely insecure, but unfortunately, happens all the time. The fact is, many school administrators (and even your platform implementation staff) don't understand how sensitive these keys can be, or what they can be used to do.
6. Testing your integrations is tricky.
In addition to the fact that schools are often running different LMS versions (#4) or have different organizational hierarchies or user roles (#3), it can be hard to set up any sort of testing environment to build and test your integrations.
Some systems like Blackboard, Canvas, and Moodle must be run on your own servers, requiring time and money to get up and running. Others like Brightspace and Microsoft require that you have partnerships in order to get access to testing environments. In either case, even getting to the point where your developers can start working on an integration is a time consuming, and potentially costly process.
7. Access control is a challenge.
Adding third-party authentication can present some challenges with regard to controlling access to your platforms. For example, when you add a Sign in with Google button, you are exposing your platform to any Google user. There is no way to tell Google ahead of time that you're only interested in logins coming from a particular organization.
Most companies rely on something like a user's email domain to determine the organization that the user is coming from. This too is fraught with problems: what if your application is only meant to allow logins from one elementary school within a larger district? How do you limit this? There are also significant security concerns when you validate anything based on email address alone, as we'll discuss in point #9.
8. You may have to reconcile LMS data with SIS data.
When you integrate with a method like LTI, you will often want to know about users ahead of time. Doing this requires either an API or SIS connection. Typically, companies will also choose to roster students and enrollments with a platform like Classlink or Clever.
Now that users and courses are pre-provisioned, you have to match up LTI launches with a user coming from Clever or Classlink. This can be a very hard problem as finding common identifiers between the LMS and the SIS is tricky.
9. Self-hosted LMS's present new types of security concerns.
Email provides the most common form of user authentication on the web. Logging in with your email address and password is no doubt a familiar experience to the reader. Since emails are allegedly unique, they provide a great way to identify unique accounts.
The problem comes in when you rely on a third-party authentication method in order to correctly inform you about the user's email address.
For example: suppose you sign up for a website with your email "email@example.com". Later, you choose to Sign in With Google using the same email address. The website will likely rely upon your email address in order to identify you. This is OK - Google is reliable and secure. Learning management systems are not so reliable. Because most systems allow you to set any email as your LMS email (even if you don't own the email address), users could set their email to be anything, and even use this mechanism to improperly gain access to others' accounts.
10. LMS's vary wildly in their data formatting and consistency.
There is no blueprint for writing an LMS and the largest ones on the market have developed over the course or years or decades to meet the needs of their clients. As a result, there are no generally-accepted practices for modeling data in these complex systems.
Even something as straightforward as object ID's can prove to be rather complex. Some systems use auto-incrementing integers. Some use integers, but they're presented to you as strings. Some use random strings. More modern systems typically rely on globally unique identifiers (GUID's). This can create a great deal of confusion for your developers for something as "simple" as importing a list of a user's courses.
In Canvas, a user with ID of 1 can be enrolled in a section with an ID of 1, which is contained by a course with an ID of 1, which is located within a school of (you guessed it) ID of 1.
Wrapping Things Up
These points are all things to consider before you jump head-first into the depths of LMS integration. It can seem deceptively easy to connect to these systems when you're staring down a large RFP.
All in all, when you're thinking about adding LMS integration for your online learning platform, consider working with an outside team like us. It could save you a lot of time, money, and mental anguish so your developers can get back to what they do best: improving your platform for teachers and students.
Learning Tools Interoperability® (LTI®), Question and Test Interoperability® (QTI®), and Common Cartridge® are trademarks of the IMS Global Learning Consortium, Inc. (www.imsglobal.org)