Enterprise integration in education has always been challenging and expensive. It was traditionally hard to do given the lack of interchange standards, legacy of systems on campuses, subpar quality of the stored data, and speed at which underlying technologies themselves evolved.
At the same time systems are more interdependent than ever before. Users expect a fully integrated experience. Many flat out require integration to work effectively. Therefore huge sums of money and time are often sunk in to the “final 10%” for custom hooks and data migration.
To put it simply, integration was always viewed as a necessary evil.
Fortunately quite a bit has happened in the last decade to address these problems. Organizations like the IMS Global Learning Consortium have introduced the Learning Tools Interoperability (LTI) and Common Cartridge (CC) standards for data interchange. The Sharable Content Object Reference Model (SCORM) was developed by the Department of Defense. Almost every vendor now has an API. Entire companies have been formed just to address integration challenges.
So, integrating systems should be easier than ever, right?
Wrong!
Whereas integration of years past dealt with custom systems and interfaces, today IT administrators are instead faced with a plethora of custom APIs and standards. They have to bring together vast amounts of data from even more disparate and incompatible systems. They are expected to be platform agnostic since LMS, SIS, and specialized systems are changing as frequently as one changes their socks.
To top it off “standards” like LTI are implemented entirely differently across the vendors. In Blackboard you might be able to access “user_id” but not “lis_person_sourcedid” (supposedly the universal username identifier) until you install a third-party building block. Desire2Learn swaps “user_id” for “ext_d2l_username.” And forget it if your switching to Instructure as you’ll then end up with “custom_canvas_user_login_id.”
In large part the same, complicated integration challenges exist today as they did decades ago and the promise of interoperability has never been fulfilled.
This was the genesis for Apidapter. A tool needed to be built to address inconsistencies and incompatibilities in both standards and the data itself that was simple, flexible, and efficient. All three of the core issues described above regarding LTI implementation variation above can be immediately solved using Apidapter. You can also mix and match protocols so you can translate from one standard to another on the fly. Plus you get the added benefit of robust debugging tools, transaction logging, and the peace of mind knowing that as integrations evolve you can just as quickly respond to them by adjusting your adapters.
We may be unable to change the way that standards organizations and vendors define and develop their integrations, but we sure can make it painless (maybe even fun) for you to work with them.
