Systems integrations can be wonderful when they work, but they often end in failure. Here are four tips to improve your success rate.
DON’T Assume Anything
Assumptions will wreck an integration project. Here are several assumptions that can cause serious grief:
- Connectivity and access right between systems
- Data formats between systems
- Timing of when services or features are made available
- Throughput or responsiveness of remote system calls
Any integration assumption needs to be tested. It doesn’t need to be an expensive test. Often, a quick-and-dirty proof of concept or spike is more than sufficient to prove or disprove an assumption. But something needs to be tested.
The key phrase to listen for is, “We should just be able to….”
- “Well, we should just be able to call into the SSO service because it is exposed through the firewall.”
- “We should just be able to format the data in JSON since the other system is also running on Node.”
You get the idea.
If someone says, “We should just be able to…,” then plan on testing that assumption.
DON’T Neglect to Identify Next Steps and Deadlines
The majority of integrations are made between systems owned by separate teams. This implies the integration itself is under shared ownership. When building (or maintaining) under shared ownership, it’s critically important to identify:
- Exactly what needs to be done next
- Who’s doing it
- When the due date is
Clear identification of the above helps avoid making assumptions (“I thought so-and-so was going to do it…”) and sets a specific date to can expect a progress update.
Personally, I like to note the above in the format of [current date] [next step] [due date], e.g. 2019-12-10 Micah will create sample data structure for Nick by 2019-12-17.
Whenever a due date is hit, the team can review to make sure the item is complete, update its status, or decide if there is anything else that can help move it forward.
DO Give Yourself a Lot of Calendar Time
It’s important to plan on an integration taking a lot of calendar time–not necessarily effort, but time for the different teams to iterate back-and-forth. Teams tend to be on different timetables and have different competing demands. This simply means it will take a lot of time to make significant progress.
I personally like to begin any known integrations at the very start of the project. I also like to conservatively assume that they won’t be complete until the end of the project. I then re-shape the non-integration work to be done during the gaps between integration steps.
DO Create Fallback Plans if the Integration Fails
An integration may still fail even if you follow the above advice. Ensure you have a fallback plan. Without the integration, is there still a way to complete the key user workflows?
Can a user live with a clunkier approach to achieve the same goal? Are pencil, paper, and phone calls a fallback option? Be open-minded about what could work; remember, humans were completing all sort of workflows and activities for thousands of years before software came along.
For example, a product we built needed to push the final output of a calculation to another system. In this case, we built a local storage option as a short-term fallback until the long-term integration could be completed.
As a bonus, the local storage had the additional upside of making local, disconnected development activities significantly easier to work through.
Conclusion
Systems integrations are hard. I suggest you assume they will be the riskiest part of the project. Following the above DOs and DON’Ts will go a long way toward de-risking the project, minimizing surprises, and ultimately, finding success.