Building or Buying Your LMS Integrations

by Jordan Clark

Will you ever need to integrate to more than one LMS?

Sometimes understanding the full context of the problem is key to solving the problem. Maybe your product will only ever need one integration. But many times, a product’s growth projection will take in connections with several LMS providers. Understanding which category your product falls under can determine if the solution is “one integration” or if it is “several integrations”. Once context like this is clear, the scale of resources needed can be better identified. One integration will need some short-term resources that can be redistributed later, while several integrations would need a reoccurring set of resources that need to be established.

Suppose your product falls into the “several integrations” category, and your company isn’t large enough to spare the developer(s) needed. In that case, it becomes quite clear to find a solution that is cheaper than adding another full-time developer. Even for larger companies who don’t want to take on the financial debt of adding another full-time developer, buying makes sense.

Do you need API, the LTI specification, or both types of integrations?

There are two types of LMS integration methods, direct API integrations and using the LTI specification. It's better to truly understand the root of the type of integration a product needs first and then match the integration method. For example, suppose your product needs single sign-on (SSO) because your user base needs an easier way to sign into your product and your users don’t respond well to iframes. Why build an LTI specification integration? Or if your developer team can build either API or LTI specification integrations, why not choose the easier build for them? There are even times when products need both types of integrations, which then places them into the “several integrations” category mentioned above.

Another detail of choosing an integration method partly depends on which LMS you're connecting with. LMS providers can support different integration methods, while some LMS providers don't support the LTI specification at all. Meanwhile, other LMS providers who do support the specification may only support some of the recent services. Even API integrations can vary between LMS providers. Developers and their teams might have to navigate through the API’s privacy and user consent policies – defining what data is retrievable and recordable. In some cases, edtech product developers will have to manually request access to sensitive scopes from the API provider, which can be lengthy and cause potential roadblocks when developing integrations.

Regardless of the integration method(s) you choose, each choice comes with certain obstacles to overcome. Understanding the obstacles can (again) help define the resources needed to move forward, or show product teams how complicated LMS integrations can be. Sometimes, teams are up for the challenge, but there isn’t any shame in understanding that a team’s focus can best be placed somewhere else.

Are integrations an auxiliary feature or part of the core product?

By now, product leaders might better understand the context to solve LMS integrations for their products. It is clear the choices of one or several integrations; the method(s) to build those integrations; and which LMS provider to connect with; can drastically change the resources needed to do the job. After understanding this complexity, product leaders can then evaluate what their development team’s focus should be on – asking questions like, “Are integrations the core of our product?”, “Should I pull our team’s focus to build integrations?”, etc. (assuming the complexity turns out to be high).

If the complexity is high enough, the obvious answer (which it is, to be fair) is, “No, it doesn’t make sense to build these integrations.” Typically a team’s focus is to develop the core product and not spend hundreds of development hours figuring out how to build auxiliary features like integrations. Instead, it is often more favorable to continue product development and building LMS integrations at the same time – which often can only be done as a “buyer”.

In Short

Product leaders and managers in edtech often have to decide to either build or buy LMS integrations. There are so many questions out there about this choice, but some often not asked are:

  1. Will you ever need to integrate to more than one LMS?
  2. Do you need API, the LTI specification, or both types of integrations?
  3. Are integrations an auxiliary feature or part of the core product?

After assessing questions like these, product leaders and managers can better determine if their team should take on the complexity of LMS integrations or if they should focus on buying them instead.

Update | 5.23.24

Read More on Integration

Here are other articles we’ve written on building integrations to help you on your journey:

If you're looking for a partner who can help guide you through developing LMS integrations (like these), then let’s introduce ourselves. We’re Edlink!

Introducing Edlink
Our Mission at Edlink
What is the Edlink Unified API