Connecting Your Tools Into One Operation

One system is the wrong goal

The instinct when tools multiply is to consolidate everything into one platform. It is almost always the wrong move: the all-in-one is worse at each individual job, the migration is enormous, and in three years you are back where you started with a monolith you cannot leave.

The right goal is narrower. For each kind of data — customers, orders, stock, invoices — one system is authoritative, and everything else receives from it. Six specialised tools with clear ownership beats one mediocre platform.

Choosing the master for each entity

Write this table down and circulate it. Half of all data conflicts in a business come from two systems both believing they own the same entity, and the fix is a decision rather than a technology.

Point to point, until it stops working

With three or four systems, direct integrations are the right answer. They are cheap, easy to reason about and easy to debug.

The cost is combinatorial: five systems can need up to ten connections, seven can need twenty-one. The tell that you have crossed the line is a change to one system requiring you to test four others.

The threshold in practice is around five systems, or the first time somebody cannot draw the integrations on a whiteboard without crossing lines.

What goes in the middle

Past that point, put something between them. It does not have to be an expensive platform — for most mid-sized businesses it is a small service you own, doing four things.

1. Receiving events from each system, in whatever format they emit
2. Translating to a shared internal shape
3. Routing to the systems that need to know
4. Logging every message, so a failure is diagnosable rather than mysterious

That fourth point matters more than the other three combined. The difference between a good integration layer and a bad one is almost entirely whether you can answer “what happened to that order?” in thirty seconds.

Handling failure like it is normal

Integrations fail constantly — APIs go down, rate limits trigger, a field arrives null that never has been before. A connection that assumes success produces silent data loss, which is far worse than a visible error.

• Retry with backoff, and a limit
• A dead letter queue for anything that never succeeds
• An alert to a human when the queue is not empty
• Idempotency, so a retry cannot create a duplicate order
• A daily reconciliation that counts both sides and reports the difference

That last one catches everything the others miss. A nightly job comparing record counts across systems will find problems weeks before a person notices.

What to leave disconnected

Not everything needs connecting. If a system is used by one person for one purpose and nothing downstream depends on it, an integration adds maintenance and removes nothing.

We have talked clients out of integrations more than once. The test is whether anyone re-types data between the two systems, or whether the two disagree in a way that costs something. If neither is true, leave it alone.

Frequently asked questions