Essential Considerations When Planning Third-Party Integrations

p>One of the advancements in the software development world over the past five or ten years is the ease at which software is extensible via the usage of third-party platforms. For the most part, this is because the API, or application programming interface, is now more or less standard fare for most software packages. The usage of APIs has made it easy for developers, and even those who are less adept technically, to connect packages together and therefore streamline workflows and operations for their businesses.

But, with the good also comes the bad. It's essential to make informed decisions when it comes to integrating outside software and systems. The factors that you need to evaluate should vary from the practicality of the solution, the business and legal aspects of the integration and of course, the technical implications of the integration itself.

So let me start with the first step when considering a third-party integration – figuring out if you should use it at all.

Determining If You Should Use Third-Party Software

There is a relatively simple rule that you should consider when making this determination:

Does the software being considered expand your functionality and is easier to integrate rather than building the same system yourself.

This, to me, is really important to consider. While this may be a no-brainer question, in truth, it isn't. There is no hard-and-fast rule that you must utilize third party software to get the job done. In some cases, building the solution yourself makes sense. But you can only figure that out if you carefully weigh the pros and cons of building versus licensing. 

Once that determination is made, it's crucial to start looking at the factors that will determine the success or failure of the integration itself.

What Makes a Good Integration?

First, let's review the variables that determine that a third-party system, and its integration method, is sound for your company's usage. If the system can pass these litmus tests, you should feel relatively safe in making a choice, and investing in the integration process.

1) It's "swappable": Is the system something that will be a component in your overall project, or will it serve as a centerpiece? On principle, I'm always very hesitant when clients introduce a third party that will serve as a centerpiece of their project. This is especially the case when the third party is something that is closed source or otherwise proprietary. Let's say a client wanted to utilize a third party, hosted database. That system is a lynchpin in the organization the minute the project is completed. Swapping it is difficult, should the need ever arise. I find this level of marriage to a solution as risky, and as such think that you need to utilize easily swappable systems, on relatively short notice. As I'll speak to below, systems can go offline and sometimes with little to no warning. As such, having easily swappable components is vital.
2) It's Flexible: This should go without saying, but whatever system you use must be flexible in that it actually offers pathways to custom integrations. For the vast majority of solutions available today, this means an API. Almost everyone has it. However, I still see some niche software providers who do not, and in this case, they should be practically eliminated from contention unless they are positioned so deeply that they cannot be avoided. API's offer flexibility in that the development team connecting to the system can utilize the interface in a variety of ways to make their integrations work seamlessly. Alternatives simply do not offer this level of integration and thus should be avoided.
3) It's Stable: This is somewhat hard to discern before signing up with a software provider, but with some due diligence, you can always dig a bit deeper to see how things work under the hood. Does the provider have a stable platform, and do they offer some level of SLA to support the system? Can you speak to existing customers to get a sense of uptime, responsiveness, and overall satisfaction? Stability in this sense is purely technical and support-driven – if your company will rely on this integration, then this is an essential factor.
4) Support & Documentation: This is somewhat also a part of the above point, but necessary to mention on its own. I always say I need two things whenever we build an integration. First, I need to know that it's documented well. This means a thorough set of written documentation that is actually maintained and has been adequately vetted for accuracy. Secondly, it helps to have a human being to speak to for when things do get a bit confusing. With smaller software companies, getting a human on the phone often isn't an issue. With more significant players like Google, it's impossible. But luckily, they maintain such strict standards with documentation that it isn't much of an issue. 
5) Deep User-Base: Sometimes, it makes sense to integrate into a solution that has a deep userbase that already exists. Users have a level of familiarity which will aid in your overall adoption, and the fact that you integrate popular software means the trust factor of those providers carries over to you. For example, offering login via Google or Facebook is an excellent feature to add to an authentication system. Users know it, it's safe, and it's a bit faster to use than building your own login platform. Never be afraid of the well-known integrations as they bring more to the table than just functionality, they also subconsciously bolster credibility.

Components of a Bad Integration

There are two ways we can look at bad integrations. First, look at my four points above, and if any of them don't exist or are questionable, you are potentially looking at trouble. However, there are other factors I also want you to consider as you choose what software to integrate into place.

1) The Health of the Partner: Nothing stinks more than to spend time integrating into some software, only to have the provider go out of business a month later. Be careful when integrating to systems from start-ups or other companies that have no proven track record. They can, and do, disappear from time to time, leaving those who relied on the software in a rough spot.
2) The Partner's Partners: This is an odd one, but we've seen it happen. Let's say you integrate into a single CRM system. Then you utilize another mailing list software, and it's all connected together "seamlessly"… It is possible along the way that provider A and provider B remove their connectivity due to a business realignment or strategic maneuver. This is unpredictable to a certain extent, but, you can somewhat hypothesize about where this may happen and plan for it. And remember, as I said above, focus on swappable components to mitigate your overall risk.
3) Added Costs: I've seen companies that have charged their customers premiums for API access. And, to boot, the costs have been outrageous. In one case, clearly few customers were asking for an API, so they built one hoping that the few who required it would foot the bill for access. They were charging for each individual API call! But, it isn't just smaller players who do this – Google maps just started charging for access, and it isn't as affordable as one would think. Now, tens of thousands of apps that use this functionality have to decide is it worth it. The latter situation you can't predict, which is another reason why having options to swap out integrations is essential. But the former is somewhat predictable – just ask when you are signing up if there are fees associated with access. To make one note: services that provide data, like stock ticker prices, are going to charge for access on a per-call basis as traditionally they are paying for that data anyway. So, it isn't necessarily that all APIs should be free, but instead, you should take notice to avoid paying outrageous access fees.
4) It's New: Trust me – you don't want to be the first person integrating into an API. This never works out well. First, you'll serve as the quality assurance partner for the provider. This means you are basically working for free. Secondly, you'll spend so much more time on that testing and finding issues that you'll end up paying more in fees and expenses along the way. Always try to be the third or fourth party to integrate into an API. Otherwise, plan ahead to spend more time and resources on the project.

Wrapping Up

In wrapping up, it's essential again to impress upon you that integrations to third parties are basically assumed with custom development projects these days. Almost every project we architect, build and deploy relies on third-party connections, and in my opinion, that's a good thing. It's faster for us to build, and it's making client solutions more comprehensive. However, with anything else that involves partnership, you have to consider your due diligence before pulling the trigger on a new software connection. Hopefully, using the above guide should make it a bit easier to find the right partner for your project.