So you have an integration job ahead of you. Somewhere out there are two different systems, and you’d love it if they could talk just a little more. We get it, after all, at AwesomeAPI, it’s what we do. Whether you are coming here because you are on the cusp of building your own integration or looking back at what you did and wondering what happened and what went wrong, we’re happy you stopped by. Today we are going to talk about why integrations fail.
Don’t Assume an Integration is Just Software
A piece of software can get complicated fast as you are developing it. At its core though, you know the tasks that your software is going to need to accomplish. An integration is the same thing, right? The task is simple. You are moving data back and forth between two systems. It sounds easy enough. The issue becomes what has to happen with that data in transit. In building software, you are often solving complicated problems with simple solutions, but in building an integration, you have a simple problem that often requires a complicated solution. Most of the problems with building an integration stem from this one misconception.
Good Developers, but Not the Right Developers
We know you have good developers. Everyone does. But do you have the right developers? Data may not be your specialty, and even if you have skilled data developers, ideally you want someone who has an understanding of both systems that you are trying to integrate as well as an understanding of what you are trying to accomplish with your integration. Too often good developers that just don’t have the right skillset get thrown at the problem of creating an integration, and that’s just a recipe for a failed integration.
Not Understanding the Scope of the Project
This is a big one perhaps even the biggest. Sure, you could say that it is true of any project, but it is doubly true when it comes to API integrations. When designing any system, things get complicated and decisions are made about how data should be structured. It’s the same as if you are designing a house, no two people are going to design a house the exact same way even though they are trying to accomplish relatively similar goals.
Now though, you have two systems, with data structured in entirely different ways, and you have to get those two systems to talk. Even with skilled developers, it’s going to be difficult to understand the scope of the project when they don’t have experience with those systems.
This often means you underestimate the project. Now you have an understaffed project and you are counting on it working on a certain schedule. Even the developers tasked with the integration may not know what they are in for at the beginning.
Too Narrow of a Focus
This often happens because of what we discussed above, and it’s another reason why these things often fail. When the job is to translate data from one place to another in such a way that both systems understand each other, it’s easy to take that at face value. You build a bridge from one shore to another allowing free flow between two coasts, but now a ship has to pass under the bridge, what do you do? The unfortunate answer is that you should have thought about that before.
Instead of creating a rigid integration, you should have made something that would be easy to develop and integrate on in the future. Hopefully, you are reading this before you got started and aren’t building a rigid bridge that may one day need to allow a ship to pass underneath.
Doing Everything Right and Still Failing
You did it. You’re here. You built the integration, you got the scope close to right, and you didn’t build with a narrow focus so you can update and maintain. Congratulations. Now the problem is that you do actually have to maintain. It’s only a matter of time before your integration trips over itself and fails as the systems it was meant to integrate grow and evolve. Since these are systems largely outside of your control, you won’t always know when you have to pull people off other projects to fix the issues your integrations are now causing, and if it’s not the same people working on it, you don’t know what kind of headache they are going to walk into.
Three Ways to Manage Your Integration
The Things We Have Seen
We’ve seen things you wouldn’t believe… Attack ships on fire off the shoulder of Orion… Okay, we’re not androids… yet, but in all seriousness, we’ve seen a lot. We’ve seen API integrations fail for all the reasons above and more. We’ve even been involved in some of those failures, but we’ve learned from them, and what we’ve learned is that even companies with good software developers don’t always have the skills to successfully deploy an integration from start to finish without costly hiccups, wasted resources, and lost time.
It’s seeing that struggle that made us get into the unified API game in the first place. We are a dedicated API team devoted to our integrations. This means they work right now, and they will continue to keep on working because we are here to support them.
Read More: Awesome API Building in Public