Coded point-to-point integrations

In this approach, a developer is writing code to integrate APIs. This is done by an internal or external development resource. An API integration tool, like Cloud Elements, may be used to help expedite the integration development or developers just code directly to the API.

When to consider this approach

You only have a couple of applications to integrate to a hub app, i.e. 1-2
You already have IT developers on staff with bandwidth to implement, manage, and maintain the integrations
You don’t want to leverage third-party solutions

Cautions

If you have more than a couple of applications to integrate, writing custom code for each integration may take too long to meet business needs (average of 41 days per integration)
Custom integrations require a dedicated resource(s) to maintain and manage as business teams will have no visibility to errors or any ability to make changes without using IT
IT will need to resolve any integration errors
If integrations are mission-critical and time-sensitive, you will need to staff for 24x7 365 rapid response support
You will need to create a process to be made aware of endpoint (API) changes to avoid unintended downtime

Vendor provided (native) integrations

This approach is relatively common as many apps provide native integrations to large hub applications like Salesforce.com. In this approach, the vendor has built an integration that typically a business system admin configures to exchange data between their app and one other. For example, HubSpot to Salesforce.

When to consider this approach

You don’t have any unique or custom integration requirements
You don’t have a need to send the same data to multiple other applications

Cautions

You may have to buy a higher tiered version of the respective apps to gain access to the APIs and integration services
It is hard to customize these integrations outside of what the vendor provides out-of-the-box
Determine who is responsible and a process for managing errors as typically only system admins have the necessary visibility
Visibility and error handling is basic often with no ability to recover without resending the record from the source system or manually re-keying

Point-to-point integration solutions

These solutions are typically built for individual tech-savvy business users to enable relatively simple integrations between the systems they use. They provide a highly abstracted view of the underlying APIs that enable users to configure integrations so no specialized skills are needed. Users typically need admin access to the systems they are trying to integrate or access to API keys. Example solution providers are FarApp and Zapier.

When to consider this approach

You have individual or department level integration needs
You only have a couple of apps to integrate with a handful of simple integration flows
Business teams own apps and integrations

Cautions

Because of the high abstract interface, It is hard to customize integrations outside of what the solution provider has built
These solutions do not scale well to organization-wide use
Pricing is “task” based which can get expensive if you have large numbers of small data packets moving between systems
Visibility and error handling is basic
There are no checks to ensure integrations are not stepping on each other, i.e. different integrations are mapping different values to the same field
It is very difficult to perform audits when there is a proliferation of point-to-point integration

Integration Platform as a Service (iPaaS)

This class of integration solutions is relatively new to the market, coming up in the past 3-5 years. The are designed to eliminate the problems that often result from a proliferation of point-to-point integrations by providing centralized integration management. Like point-topoint solutions, they abstract APIs to enable configuration of connections from apps to the iPaaS. Beyond that, the user experience can vary widely. Some iPaaS solutions are built for large enterprise use cases so they are more like integration “toolkits” better suited for IT use, such as Dell Boomi, Jitterbit, and Mulesoft. Others offer more pre-built integrations designed to help organizations get started quickly and the ability to build custom integrations to serve any use case. These solutions tend to serve midsize companies better as they can be used by both business and IT teams to build simple to complex integrations. Celigo and Workato are good examples of iPaaS solutions that cater to the mid-market.

When to consider this approach

Your integrations are mission-critical
You have a mix of complex and simple integrations
You have multiple applications to integrate
You want business teams to manage and maintain integrations, not your IT team
Your integration requirements are fluid and change often
You need to build custom integrations
You need advanced operational visibility into your integration performance, including error handling and auto-recovery

Cautions

Not all iPaaS solutions are the same, so develop a checklist of your specific requirements
Ensure you are not paying for enterprise-level features you will never use

Contact Us for help integrating an iPaaS solution for your Business.