Integration
Why we reduce systems before we integrate them
Every integration you add is something that can fail at 2am. Before we connect anything, we try to work out what can be removed instead, and the arithmetic makes the case better than any argument does.
Key takeaways
- Point-to-point integration grows at n(n−1)/2. Six systems is fifteen connections, ten systems is forty-five.
- The real cost of an integration is not building it. It is owning its credentials, retries, failure modes and documentation for years.
- Retiring one overlapping platform removes more work than automating around it ever will.
- An integration layer trades many small failure points for one place to look when something stops.
- Point-to-point is still the right answer at small numbers. The trap is not noticing when you have left that range.
Almost every integration brief we receive is written as a connection problem. Two systems do not talk to each other, someone is manually bridging them, and the ask is to automate the bridge. It is a reasonable request, and it is usually the wrong first move.
Before we connect anything, we try to establish what could be removed instead. Not as a cost-cutting exercise dressed up as architecture, but because the arithmetic of integration is unforgiving and most organisations have never had a reason to look at it.
The arithmetic nobody runs
Connect every system directly to every other system and the number of connections grows as n(n−1)/2. That formula is abstract until you put your own numbers into it.
| Systems | Connections | What that means in practice |
|---|---|---|
| 3 | 3 | Manageable. One person can hold it in their head. |
| 6 | 15 | Nobody has the full picture any more. |
| 10 | 45 | Changing one system means auditing nine others. |
| 15 | 105 | Effectively unmaintainable without a dedicated team. |
Route the same six systems through one integration layer and you are maintaining six connections instead of fifteen. More usefully, you have one place to look when a feed stops, rather than fifteen places where it might have.
What an integration actually costs
Build cost is the part everyone quotes and the part that matters least. An integration you own for five years costs you:
- A set of credentials that expire, rotate, and occasionally get revoked by someone doing the right thing in a different team.
- A failure mode that has to be designed, tested and monitored: retries, dead letters, replay, and an alert that reaches a person.
- A place in every future upgrade conversation, because changing either endpoint means re-testing the connection.
- Documentation that has to survive the departure of whoever wrote it.
- A share of the blame surface when two reports disagree and nobody can say which side drifted.
The rule we work to
An automated version of an unnecessary process is still an unnecessary process. Only now it is harder to change, and someone has to maintain it.
What we look to remove first
A rationalisation map takes two to three weeks and usually pays for itself in retired licences before a single integration is built. Four categories account for most of what we find.
- 01Systems that overlap. Two platforms doing seventy per cent of the same job, each with its own internal champion. Compare them on what your process actually needs, not on feature lists.
- 02Systems nobody uses. Licence counts against real login data. This is usually the easiest money on the table and the least contested decision in the programme.
- 03Reports that exist out of distrust. A spreadsheet maintained in parallel because someone does not believe the system. Fix the trust problem and the spreadsheet retires itself.
- 04Steps that only bridge two systems. Work that exists purely because system A cannot talk to system B. This is the category to delete rather than automate.
Decide ownership before you build
Most integrations that 'keep breaking' were never told which system owns which field, which systems may write to it, and what happens when two of them disagree. That is a governance question surfacing at machine speed, and no amount of retry logic will answer it.
When point-to-point is still right
None of this argues for a middleware platform in every business. At three or four systems, direct connections are simpler, cheaper and easier to reason about than a layer nobody needs yet. Introducing orchestration too early is its own expensive mistake.
The trap is not starting point-to-point. The trap is not noticing when you have left the range where it made sense, which tends to happen one reasonable decision at a time, until the day a feed fails silently and a customer tells you before your monitoring does.
The short version
Count your systems. Run the formula. If the number is uncomfortable, the next integration is not the thing to build. It is the thing to question. Reduce first, connect what is left properly, and make sure the connections you keep are loud when they fail.
Read next
Why the guardrails are the expensive part of an AI agent
Getting a model to read a document well is the afternoon. What makes it safe to run unattended is everything around it, and that work costs the same whether the agent is for one client or fifty. Which is precisely why it keeps getting skipped.
Governance decisions that are cheap on day one
Nobody books a governance workshop. It arrives later as a question from an auditor, a client security review or a privacy complaint. Four decisions cost close to nothing at the start and a great deal once there is data in the system.