When a company complains that its systems don't talk to each other, the answer seems obvious: connect them. Build the integration, let the data flow on its own, and the problem is solved.
Sometimes that's exactly how it goes. Other times, six months later, there's more confusion than before — and now it's harder to investigate, because nobody can say where any given value came from.
The difference between the two outcomes comes down to a decision made before the first line of code is written.
What happens when you connect without deciding who's in charge
Picture two platforms holding the same customer's address, each with its own version. They're connected both ways, so they're "always in sync."
What actually happens is this: whoever changes it last wins. Sales corrects the address in the sales system, and the sync carries it over to billing. The following week, someone in billing corrects something else on the same record, and the old address comes back, because that system still had it saved.
Nobody notices. Two months later, a piece of post gets returned, and the conversation is about who changed the address — when the truth is nobody changed anything: the problem is that both systems thought the address was theirs.
More connections, more places for things to break
There's also a tedious sum that rarely gets done. Connecting two systems is one link to maintain. Connecting five systems, all to each other, is ten.
Any one of them can fail silently — because a supplier changed their interface, because a certificate expired, because someone hit a rate limit. And silent failures don't throw errors: they produce outdated numbers that still look fine.
That's why a hub-and-spoke setup, with one system at the centre in charge of each type of data, is usually cheaper to maintain than a web of connections — even though it looks like more work at the start.
The question that comes before the cable
For every type of information that's going to cross the connection, three answers:
- Who creates it. One system, and only one, is responsible for creating and correcting that piece of data.
- Who reads it. The others receive it, display it and use it — but don't write to it.
- What happens on conflict. If the two disagree on the day the connection goes live, which one wins. This decision has to be made by someone from the business, not by whoever's writing the code.
Once these three are answered, most connections turn out to be one-way — and one-way connections barely cause problems, because there's nothing to reconcile.
When integration genuinely pays off
None of this is an argument against integrating. It's an argument against integrating first and thinking afterwards.
The cases where it almost always pays off: eliminating a manual re-entry that happens dozens of times a week; getting the status of a job to whoever's answering the phone; and sending what comes in through the website form straight into the management system, with nobody in between.
These are one-way connections, with a clear owner on each side, and that's where systems integration pays for itself within the first quarter. The order in which you tidy up the technology matters, and the order in which you tidy it up is a topic of its own.
Connecting two systems?
Tell us which ones, and what information needs to pass between them. We'll help you decide who's in charge of what before any code gets touched.