We get this question a lot. Edlink isn't everything to all people and we won't try to convince you otherwise. With that being said, here are some raw thoughts we have about the pros/cons to building an LTI application in-house vs working with Edlink.
Related: What is “LTI integration”
We'll touch on: how building an LTI application in-house affects your time-to-market, actual costs and opportunity costs of both options, LTI functionality limitations and how Edlink overcomes these, user experience options, scalability of both and the future of LTI/edtech integrations.
- The opportunity cost of building-in house is worth considering. Most don’t.
- It takes ages to build an integration of any kind in-house. With Edlink it takes 4 weeks max in 80%+ of cases.
- Working with an intermediary will no doubt be more scalable.
- LTI has limited functionality in regard to user experience and interoperability.
Most of the clients we work with are able to connect their application to the Edlink API in less than four weeks with only one in-house developer working on the connection. In some cases, they’re able to get linked up in less than three days.
Connecting to Edlink’s API gets companies access to the entire list of systems we’re already integrated with, saving them hundreds, if not thousands of hours.
To illustrate the magnificence of this timeframe, we’ve checked back in a year later with prospective clients who decided to go it alone (i.e. not work with Edlink). In most cases they were building a single integration (to one LMS, like Canvas or Schoology) and in most cases they were still working on that one integration 12 months later.
In the situations where they decided to work with a “competitor” of Edlink, the time to connect was reduced to 16 weeks, but the scope of the integration was also limited in terms of functionality (SSO only, as opposed to SSO + rostering + grade synchronization + content integration).
Related: Who are Edlink’s competitors?
Our clients love that they can train their salespeople to just say “yes” when schools and districts ask about integration. This reduces friction in the closing and procurement process and makes it easier for salespeople to work with confidence when talking to prospective customers.
There are two alternatives that companies seem to be typically encountering when we meet them.
- They’re having trouble teaching their sales teams the nuances of which integrations they support and which integrations they don’t. And they’re saying “no” to potential customers that need integrations they're not offering.
- They’re just letting salespeople say “yes” and trying to work it out with educational institutions after the deal is signed, either by finding a work-around (aka reneging on what the salesperson said) or by moving around dev priorities, or hiring contract dev (or Edlink) to get the integration done in a hurry.
Clearly, neither of these situations is ideal.
Often companies talk to us about their concern for their sunk costs (i.e. "we've already scoped out building an LTI 1.3 compliant application") with little regard for the opportunity costs they may have incur by choosing to continue building in-house.
Larger organizations, with more resources and more adept developers, ironically also have the highest opportunity cost when choosing to build-in house. Not only does it take longer to scope and build out the functionality, but the deals on the line are larger and the value of the time their developers spend on building products is greater.
For smaller or resource-constrained companies the opportunity cost is different, but still existent. Often entrepreneurs we talk to tend to err on the side of being conservative with their money rather than their time. At the risk of sounding cliché, you can always make more money. Not the same can be said for time (unless you've got a time machine, in which case, you've probably got more exciting problems than building LTI applications).
Further, when you take into account that the edtech industry as a whole is inevitably consolidating, brand new startups with little market share and few acquisition prospects might be spending precious time building non-core functionality (i.e. integrations) at the risk of becoming the last startup standing when the music stops.
That’s not a risk we're willing to take.
Not to mention, of the almost 1,000 companies we’ve talked to since Edlink’s inception, only one of them had a product for which integration was considered “core functionality” or their “unique value proposition.”
Edlink’s pricing is here.
On average, Edlink’s clients pay us $15K per year. The companies we’ve met with robust integrations typically have an entire team of engineers solely responsible for integrations, and they still don’t offer the depth and breadth of functionality that Edlink offers.
Ian Lotinsky of LearnZillion says it costs his team upwards of $25K per year, per LMS, just to maintain their adherence to the LTI specification.
Functionality, Flexibility and User Experience
Building an LTI application alone offers less functionality, less flexibility and a more constrained user-experience than Edlink.
The display of an LTI application will be different from LMS to LMS. This means more work for your support team and sales teams, in that they would need to understand the nuances of each system you intend to support to accurately convey/troubleshoot the experience your customers will have.
Rostering with LTI can be limited. When a teacher launches an LTI resource from their course within their LMS, the LTI app can only read the enrollments of teachers and students of that specific course. The app cannot see the enrollments of any other course that the teacher is a part of. In fact, if the app is not using the Names and Role Provisioning Services in LTI Advantage, then the app cannot even read the enrollments of any users in the course who have not yet launched into the LTI tool. This obviously can cause some issues if your app needs to roster users in advance or in bulk.
When an LTI application is launched, the application appears in an iframe inside of the LMS, which just doesn’t work for some of the more advanced, robust or interactive educational tools that schools use. It should also be noted that many LMSs allow users to add LTI tools to different placements in their LMS. A placement refers to the location on screen or context in the LMS where the user will launch the LTI application. Since placements can change where the user is launching the tool from, it can alter the experience for the user and make it more nuanced for your support teams to troubleshoot issues across different LMS.
Assignments and events won’t show up as a calendar item inside the LMS because the LTI specification doesn’t touch the calendar feature.
Finally, the dataset of uses-cases any one organization will take into account (and related edge-cases) is always going to be smaller than that of an organization who's aggregating integrations. It’s rare that we get requests to build new integrations--we’ve usually already built them, because we’ve gotten wind of their upcoming importance due to this fact. So the wait time for a new integration, as well as the number of edge-cases that won’t be accounted for, is virtually zero working with someone like Edlink as opposed to building in-house.
LTI alone limits you to being able to support integrations for customers who have a system that is compliant with the version of the LTI specification you’ve implemented. Major LMSs that support LTI are:
- Canvas - LTI Advantage Complete
- Brightspace - LTI Advantage Complete
- Blackboard - LTI Advantage Complete
- Moodle - LTI Advantage Complete
- Sakai - LTI Advantage Complete
- Schoology - LTI v.1.1
Related: What is LTI 1.3/Advantage Complete?
Google Classroom does not support LTI. Neither does Microsoft Teams.
Scalability also comes into consideration when you think about troubleshooting and maintaining connections with school-data systems. It’s one thing to manage one integration. What about 100? 1,000? We can help you do this, today if you need.
Even if building an LTI application solves your integration pain today, what about tomorrow?
IMS Global occasionally updates the LTI specification and LMSs don’t all agree on when they’re going to update their support for the new spec. Schoology, for example, is still on LTI 1.1.
There’s always a chance that an educational institution you’re working with will change LMSs to one with which you don’t integrate.
Finally, with the edtech market rapidly consolidating and evolving, the landscape of technology used in the educational ecosystem will likely shift. Will LMSs get deprecated entirely? Will major players switch to other or new systems?
We’re excited to find out and we’ll be ready regardless.