Often times when looking into software solutions, we may consider building a complete solution from the ground up versus making use of 3rd party services to cover the basic requirements in conjunction with some possible custom integration(s) between those services.  All of the pros and cons between completely custom vs. integrated 3rd party solutions is beyond the scope of this article, but we’ll try to cover some of the primary considerations in terms of integrating various 3rd party components together.

Every Service Does it Different

As we consider possible integrations, we should realize that every 3rd party service has the ability not only to grant whichever actions/integrations it may wish (or, none at all), but also that each 3rd party service could provide those integration points completely differently than any others.  In terms of developing and programming, this often means that in order to make use of these integrations, Service A requires development against set of practices X, while Service B requires a completely different set of practices Y.  In the end, we often end up with three distinct components for this: one to get X, one to get Y, and a middleman Z to do whatever it is we actually needed to do.

Each Service will Require “Setup”

For each service that might want to bring into the fold, there’s going to be a fairly significant “initial setup.”  While it’s not easy to put a number as to how many hours might be involved, it’s worth consideration when trying to put together a system of services to provide an overall solution.

This is mainly due to the first point that every service does things differently.  In this case, it’s usually a matter of how the service requires authentication and authorization (loosely speaking: security) as well as some other things such as how much data we’re allowed to work with at any given time and what types of workarounds we might have to put in place.

As an example, it’s very common for a service to state “we allow you to work with orders, but you can only read or edit X number per command.”  This is done to ensure that a customer with 100,000 orders doesn’t issue some command that clogs up the service’s resources and prevents anyone else from getting anything done.  The downside here is that there’s a number of different policies that could be in place for how to work with larger volumes of data, and as such, each new service that we want to incorporate into the larger solution is likely to require special attention to this area as well.

In any case, it shouldn’t be considered a trivial matter to integrate 3rd party services, so as we’re jotting down things we’d like to do while putting our system together, this is a good thing to keep in mind.

The Integration We Need Might Not be Available

Generally speaking, whether or not we can do what we’d like to do is very dependent upon what types of integration the services in question allow.  Some services are very much designed with tight integration in mind, while others add integration services as an afterthought, or possibly not at all.

It’s a fairly common task for example to pull a list of contacts and their basic contact info from a CRM system and update some other system with that information, and such an integration task can certainly be very useful.  More complex integration scenarios – especially tasks that would use realtime, event-driven behaviors across 3rd party providers – is often much more difficult if not practically impossible depending on the various services in question.

General Considerations

• Try to keep the integrations minimal in terms of both the number of services to be integrated as well as the complexity of the integration.  Simple is more cost effective and also less prone to breaking changes as the 3rd party service inevitably makes their own changes.
• For each service we’re considering integration for, inquire about their API (Application Programming Interface).  The API is what allows us to perform these integrations.  Some services may offer an expansive API while others offer none at all.  Many services will charge more for using an API, and often have pricing tiers based on the volume of API usage.
• Ask their sales or technical department (preferably their tech department) if the general integration you’re looking for is supported.  For example, if you’d like to have a “goto customer” invoked in one service when a certain action happens in some other service, try to give a brief explanation of this desired behavior and see if it can be done (your development shop or IT department may have to work out the details here, but during the exploratory phase of planning your solution, it might not hurt to ask).

Sometimes things can pile up pretty quickly- be careful that the amount and complexity of the integrations required doesn’t overstep that of having a custom solution built.  In a culmination of the the various points noted above, we can often find ourselves with quite the puzzle to work out while trying to strike the right balance.  Remembering to keep things simple and restrict integrations to only those that are quite necessary, we’ll be better positioned for easier initial setup and long term stability of the overall solution.