What a system integration is (and when it earns its cost)

"We should integrate these" is one of the most-said and least-examined sentences in a small or mid-sized company. It sounds like an obvious fix: two systems that don't talk to each other — make them talk. But an integration is a piece of machinery with a cost of its own — to build and, above all, to keep alive — and the decision worth taking slowly isn't "can they be connected?" (they almost always can), but when an integration earns its cost, and when it's better to wait.

What integrating two systems actually means

Integrating means a piece of data travels from one system to another without a person typing it in. Behind that simple sentence sit very concrete decisions: exactly which data travels (the whole order, or just the amount?), in which direction (does the CRM feed invoicing, or the other way round too?), how often (instantly, hourly, overnight), and what happens when the two sides disagree.

An integration isn't a cable: it's an agreement between two systems, written in code. And as with any agreement, someone has to set the terms. Those choices look like technical detail, but almost all of them are business decisions in disguise: which side owns a given piece of data, or how fresh it needs to be, is not something the technician can decide alone.

The integration you already have: a person copying

If data already gets from one of your systems to another, an integration already exists; the question is what it's made of. In many companies it's made of a person: someone exports from one system, pastes into another, checks that it adds up and fixes the formatting. Every week, or every day.

It's an invisible integration. It appears in no systems inventory and no budget, yet it performs exactly that function. And it deserves some respect before you remove it, because it has virtues an automatic connection doesn't ship with: a person spots oddities, tolerates exceptions, and adapts without notice when something changes on the other side. Its costs exist too — they just never show up in one place: recurring hours nobody accounts for, typing errors, data that arrives when someone has time rather than when it's needed, and a quiet dependency — when that person is away, the data doesn't travel.

Recognising the copy-paste for what it is — a manual integration — changes the conversation. It's no longer "should we integrate?", because you already have. It's "which integration do we want: this one, or an automatic one?".

What breaks when one side changes

This is the part least often mentioned when an integration is being sold: it ties together two systems that will keep changing independently. One vendor updates a version, renames a field, or retires the connection method you were relying on. The other system adds a mandatory field that didn't exist before. Someone, with the best of intentions, changes a setting.

And the integration — which had run for months without anyone thinking about it — stops working. Sometimes with a visible error; sometimes silently, which is considerably worse, because data stops travelling or travels wrong and nobody notices until a number fails to add up.

None of this argues against integrating. It argues for counting the whole cost: an integration isn't something you build once, it's something you maintain for as long as it lives. Who finds out when it fails, and who fixes it, are as much part of the design as the fields that travel.

When an integration earns its cost

With the full cost on the table, the criteria become fairly sharp. An integration pays off when several of these hold at the same time:

• The transfer is frequent and rule-based, not occasional and riddled with exceptions.
• The cost of an error is real — a wrong invoice, a late delivery, a lost order — not cosmetic.
• Both systems are reasonably stable. Integrating against a system you're thinking of replacing means paying twice.
• It's already decided which side owns each piece of data that travels. An integration doesn't settle that disagreement: it propagates it faster.
• Someone is on the hook: they'll know when it fails and who to call.

When it doesn't pay off (yet)

"Not yet" has clear signals of its own. If the volume is so low that copy-paste costs less than building and maintaining the connection, the copy-paste is fine. If one of the two systems is under review, wait until you know what you're integrating against. If the underlying process is still changing every few weeks, the integration will freeze a version that won't last.

And there's a subtler case: sometimes the manual step is acting — without anyone calling it that — as a checkpoint. Someone looks at the data before passing it on, and that look catches errors. Automating the step without replacing the review with another control doesn't remove a cost: it removes a filter. It's the small-scale version of a more general rule: automating something disordered only speeds up the disorder.

Five questions before you ask for an integration

1. Exactly which data travels, in which direction, and how often?
2. Which side wins when the two don't match?
3. How will you find out it has failed — before a customer does?
4. Is either system likely to change soon?
5. Who maintains it when something changes? Because something will.

If you can answer all five, the integration will probably earn its cost, and the project will be one of the rewarding ones. If any of them goes unanswered, that's where the groundwork is — exactly the questions we settle before building anything in a data and AI project.