The Learning Tools Interoperability (LTI) standard was written with the primary intention of supplying a universal way to implement SSO from learning management systems (LMSs) to learning tools. To achieve this, especially with the interest of prioritizing the privacy and security of young learners, the LTI standard is written such that when a user launches a learning tool from within their LMS, the data shared with the tool about the user is kept to a minimum for the tool to function. However, reducing the user data sent within LTI launches can, in some cases, end up in tension with personalized learning solutions, since those solutions potentially depend on exactly the same user attributes that these LTI launches intentionally hide. For example, with the knowledge of each student’s grade level, applications can be tailored to a student’s likely demeanor and interests. While personalized learning may be a big driver for some, many other creative drivers surely also exist to ultimately necessitate receiving more information about a user when they launch into your application, beyond their name, email, and class.
Where can this additional information come from? The LTI 1.3 Core specification outlines many substitution parameters for which the LMSs can optionally provide data. Additionally, each LMS also has the freedom to supply its own custom substitution parameters beyond what is listed in the specification, which may supply even more data. Ultimately though, the primary system housing student data to be fed into downstream applications is the student information system (SIS). In other words, when LMSs are able to provide additional information through LTI substitution parameters, that data is sourced from SISs as shown in the diagram below.
While this diagram looks fairly simple, the first step of loading the data from the SIS into the LMS is actually quite complicated. This is because there are well over two dozen different kinds of SISs that serve both higher education and K-12. More information on K-12 SISs can be found here (ListedTech) and for higher education, here (Gartner). In addition to the first node in the diagram actually representing nearly two dozen different nodes, schools and districts often have custom needs that lead them to either modify the format of the data within their SIS, or request modifications to it as it flows into the LMS or both, which makes the left-hand side of the diagram look more like spaghetti and meatballs if drawn realistically.
In an effort to limit the amount of metaphorical "spaghetti", many SISs have adopted 1EdTech’s OneRoster standard and attempted to apply the OneRoster format to their data when transferring it to LMSs. Unfortunately, because standards have to be written in such a way to not be too constrictive and still allow vendors enough creative freedom to provide unique and high-quality systems, many SIS implementations of OneRoster are custom. Consequently, the OneRoster standard has improved the interoperability between SISs and LMSs to a degree, but a high level of complexity in these integrations still exists, especially since standards typically can’t reduce institutions’ desires for custom features.
Where does this leave the learning tools? The two primary sources from which learning tools can extract user data are from the LTI launch that the user makes from the LMS into the tool or directly from the SISs as shown in the diagram below.
However, as discussed above, the node for the SIS and the arrows of data emanating from it are considerably more complex than the diagram suggests. This means that learning tools must ensure to construct a robust architectural strategy and plan if they choose to embark on integrating with SISs to enhance the data stream into their application(s). Some things to consider on this journey are outlined below.
If it isn’t already obvious, it is critically important to note that for most learning tools the goal to be interoperable with as many SISs as possible won’t happen overnight, and it won’t happen in one fell swoop. Given this, learning tools should talk with their customers and potential customers about what SIS they use and if they’re planning to migrate to a new one any time soon. This way the learning tool can target certain SISs to integrate with first, and establish a multi-year plan with appropriate prioritizations to move towards the ultimate goal of the highest interoperability possible.
Another aspect to consider is how you intend to use the data you receive from the SIS. How can you personalize the learning experience with this data? Will your application require account binding to pair user accounts from LMS LTI launches with user accounts imported from the SIS? Will it need to bind the LMS classes to the SIS classes and courses as well? How often will your application resync with the SIS? How will you handle issues if the SIS and LMS end up out of sync? What if your customer’s customizations to their SIS and/or LMS render the data you receive from both to be seemingly useless?
Additionally, customer onboarding is important to consider as institutions’ IT administrators are getting increasing sway in their institution’s edtech purchases as discussed in a previous blog. Adding an SIS registration in addition to an LTI registration for each institution admin is double the hassle for them, and it also doubles the number of pipelines in place to have to worry about malicious actors getting ahold of PII. This means it will be important to be able to outline whether or not you want your application to require SIS integrations or if you will leave the added features for that configurable. Additionally, it will also be important to be ready to present the institution admins with data explaining why the value of the features that the SIS integration brings outweighs the additional hassle and security risk.
In conclusion, having more data can be a very powerful tool to be able to offer unique, cutting-edge products and learning experiences to customers, even helping to improve the equity gaps in education. Given that, it is important to put a lot of thought and planning into developing an integration strategy tailored to your team’s mission and timeline as the complexity of interoperability can expand rapidly. If you are just beginning this journey or if you are interested in tightening your existing interoperability strategy, Unicon has extensive experience providing edtech vendors with evaluations and solutions to a myriad of complex integration issues, and we would be happy to provide assistance.
