The word 'integration' has become a huge buzz word in the enterprise software space.
Every single buyer that I work with wants their new platform to be 'integrated.'
Many buyers build their vendor shortlist by going to the website of a favorite tool and seeing which 'integration partners' they have listed.
I've seen clients ignore major red flags with a product, because it promises to be integrated to their other tools.
There is a warm and fuzzy feeling that buyers get when they hear that two products are going to be integrated. And it makes sense. An integration sounds amazing. It makes you think that technology is actually going to work, that information will flow freely, that life itself can be simpler, etcetera, etcetera.
But, unfortunately, two problems exist that make this dream world less of a reality.
- Software companies know how attractive the word 'integration' can be and are willing to let you believe it means one thing, and then after the contract is signed, explaining that it means something else
- Buyers often do not understand the mechanics of integrations well enough to ask the right questions during evaluations and are therefore prone to being oversold and underwhelmed.
That's why we felt it was important to demystify integrations and to allow the average software buyer the ability to better understand what to expect
What an integration sounds like in theory
As a buyer, when you hear that two platforms have an integration, your mind is going to automatically assume a few things:
- This integration will be no-cost
- This integration will not require any set-up work since it already exists
- This integration will be bi-directional
- This integration will automatically pull/send the exact data fields you want
Although there are some integrations that work just like you hoped, the truth is that those four criteria are often an ideal integration that doesn't exist in practice.
Instead, what tends to happen with integrations is far different, especially integrations between large, complex software platforms.
What happens with integrations in reality
Integrations often need to be built
Just because a vendor says they 'have an integration with Vendor X', doesn't mean you should assume that this is a pre-built, no-cost, turn-it-on-with-one-click integration.
Oftentimes when a vendor claims an integration, what they're really saying is: "Our system and Vendor X have the ability to pass data back and forth and we've built this bridge before."
In the majority of cases, building an integration requires an IT resource that can set it up, test it and ensure the right data is delivering. Sometimes that IT resource is provided by your new vendor, other times your team needs to provide that resource or hire a consultant.
Make sure to ask: "How is the integration turned on during implementation? Do we need to work with your IT team or Vendor X's IT team to create the integration? Will there be a cost to our team to build or utilize this integration?"
Once built, integrations can 'break'
An integration that works on Day 1 of Go-Live is not guaranteed to stay effective throughout your lifecycle as a customer.
The majority of software integrations today are done by API (more on this later). API's are lines of code that instruct the two systems on how to transfer data. However, since both software platforms are dynamic and constantly updating, those lines of code can become outdated and ineffective.
Let's say your team went through the process of building an integration that ensures that 5 key data fields are automatically imported. However, two months later, your vendor partner releases a total overhaul of their platform and 1 of those data fields is no longer part of their architecture.
Now all of a sudden, that integration that your team built is no longer automatically transferring everything you need it to. Maybe your team will need to have an IT resource remap the integration to new fields, or maybe your team will have to manually re-enter that field for a while.
Make sure to ask: "Who is responsible for maintaining the integration? What happens when you push out product updates that could alter the data fields involved in the integration? What happens when integrations go down?"
Data flow isn't always precise
Another challenge with integrations is that buyers don't always have the control that the expect when it comes to defining what data to import.
Oftentimes an integration will pass over too much information and make your employee database messy.
For instance, with a hypothetical time-to-payroll integration, you could import the time card punches, but also receive employee birth dates or ID numbers too.
Since those other fields were already stored in your payroll system, now you have two different columns that are storing the same field.
Additionally, the challenges can go the other way. Some providers claim to have open API's but will put restrictions on what fields can be exported/imported. Oftentimes you won't find out about these limitations until it's too late and you realize that one of the key data fields you wanted to import is inaccessible
Make sure to ask: "Will our team have control over which data fields are included in the integration? What happens if duplicate data is involved in the integration? Are there certain fields that we are unable to include in the integration?"
Various types of integrations
Application Programming Interface (API) is the most common tool for connecting different applications. API's are built by the software provider and are essentially instructions for accessing the platform's data.
Nowadays, almost all modern software platforms have APIs, so they are commonly available. However, APIs are code-based and maintained by the vendor, so they are subject to change and require a working knowledge of programming languages.
Webhooks are similar to APIs in that they connect two web-based platforms. However, webhooks are event-based, meaning as soon as an event happens in one application, the corresponding change is made in the other application.
Because of this model, webhooks are more instantaneous than APIs. On the otherhand, they offer less control over what data is transferred over.
SFTP (Automated File Transfer)
SFTP transfers are essentially secure, automated file transfers. During implementation, you will determine which fields you want to 'download' out of one system. Simultaneously, you will determine how those fields will 'upload' to the other system.
Once the fields are mapped, an automated and secure file transfer will take place according to a regular schedule.
While SFTP transfers are very flexible and secure, they are more manual to build and any changes to one platform can affect the ability to import/export data to the other platform.
Alternative approaches to integrations
Integration Platforms as a Services (iPaas), such as Zapier, MuleSoft and Dell Boomi, are platforms that are dedicated to finding the easiest way to integrate thousands of software platforms. For a fee, these companies will build and maintain your team's integrations.
This can have two powerful impacts: (1) It prevents your IT resources from having to constantly oversee and manage integrations and (2) It will make your data more consistent across the entire company
Human - Tech Hybrid
One of our partners, GoCo.io, has taken a novel, yet straightforward approach to solving the integration challenge. Like most of their peers, GoCo prioritizes API connections. However, GoCo also offers an 'integration dashboard' that will alert customers if there were any changes or failures with their integrations.
For an extra cost, their team will provide a live person to monitor and fix those failures, so you are never the wiser about them even happening.
Another one of our partners is currently pioneering an integration approach that looks like a game-changer. The Partner is a background check company called Verified First.
In order to succeed in the background screening business, it’s critical to have integrations with leading ATS’s. However, there are thousands of background screening companies in the space and only a couple dozen major ATS’s, so there is a lot of competition to see who can get the attention of those ATS companies to build an integration with them.
Instead of chasing costly back-end integrations, Verified First built a front-end browser plugin that accomplishes the same task, in a much more elegant way. An end user can install the plugin in less than 30 seconds, refresh their ATS and have the integrated background screening button immediately visible.
We believe wholeheartedly in technology that can automate and simplify the lives of our customers. However, we also want buyers to know that integrations are not always what they promise to be.
Make sure to ask good questions when evaluating software platforms, so you can determine how 'integrated' the two platforms will really be. And once you have a better understanding of the time and costs involved in building that integration, ask a hard question of yourself to see if all the work is even necessary.