How to Connect Disconnected Business Systems

Walk through most growing businesses and you will find the same quiet ritual. A customer detail typed into the website, then typed again into the accounts package. A stock figure that sales believes and the warehouse disputes. A spreadsheet emailed every Friday so that Monday’s import has something to chew on. A month-end where someone spends days making two systems agree on a number neither of them can be trusted to hold. Everyone assumes this is just how it is — that the business has simply outgrown its tools, or that the team needs to try harder.

It is almost never a people problem. The honest diagnosis is structural, and it is oddly reassuring: you do not have broken software. You have a set of good individual tools — a CRM, an accounts package, an inventory system, a couple of spreadsheets that quietly became load-bearing — and each one works. What does not work is the space between them. The systems are connected, but by offline feeds, file exports and manual re-keying rather than by real-time, supported integration. That single distinction is the entire problem, and naming it correctly is the first step to fixing it.

Why “it works at small scale” stops being true

The cheap ways of connecting systems all work beautifully when you are small, which is exactly why every business reaches for them — and they all fail in the same predictable way as you grow.

• Manual re-keying. Someone retypes the same data into two or three places because the systems do not share it. It works until volume rises, and then it becomes a full-time job that also introduces errors faster than anyone can correct them.
• File exports and overnight feeds. The data moves, but in scheduled batches — a nightly export, an hourly drop. Which means every system is working from yesterday’s numbers, so sales oversells stock the warehouse no longer has and nobody finds out until a customer does.
• Direct point-to-point links. You wire system A to system B with a script, then B to C, then A to C. Each link is bespoke and undocumented, and the number of links grows far faster than the number of systems. The end state is a tangle “somebody wrote in 2003 and nobody fully understands any more,” where any change anywhere breaks something elsewhere.
• One-way automations. The first proper tool — a Zapier or a Make — is genuinely useful for “when this happens, do that.” But it is built for task automation, not data consistency: one-way pushes overwrite and corrupt data, and dozens of little flows become brittle, silently failing without anyone noticing the drift.

There is one clean line worth holding on to underneath all of this: a tool for “when this happens, do that” is fundamentally different from a system for “keep these things consistent.” Most businesses buy the first and, once their operations become mission-critical, actually need the second. Recognising which one you need is most of the decision.

The principles that actually fix it, in plain English

The mainstream discipline for connecting systems properly has an off-putting name — composable architecture — and a great deal of jargon attached to it. Stripped of the vocabulary, it comes down to four sensible principles. You do not need all of them on day one; you need the right ones for your situation.

• One source of truth. Agree a single authoritative definition of each important thing — what a “customer”, an “order”, a “product” actually is — and let one system own it. Every other system maps to that shared definition. This is what ends the meeting where two reports disagree, because there is finally a right answer to point at.
• Systems talk through stable interfaces (API-first). Each system exposes a proper, supported way to ask it for what you need — the difference between “we can read your orders through a documented interface” and “we screen-scrape your reports at midnight and hope the layout didn’t change.”
• Live events instead of overnight batches. Rather than one system reaching into another on a schedule, a system announces when something happens — “order placed,” “payment received” — and anything that cares reacts in near real time. This is the direct replacement for the nightly feed, and it is what makes the stock figure correct when the salesperson looks at it.
• One integration layer in the middle. Instead of wiring every system directly to every other, each system connects once to a central layer that routes and translates between them. The tangle of direct links becomes a switchboard — far easier to understand, monitor and change.

A useful way to picture it: today every system speaks its own language, and you employ people to translate between them by hand. The fix is to put one shared language and a switchboard in the middle, so every system says things once, in real time, and everyone is finally looking at the same numbers. That is the whole idea, behind the jargon.

Right-sizing — the part that earns the trust

Here is the honest caveat that most integration sales pitches leave out: this is not free, and most businesses should not build all of it. Composability adds coordination and governance overhead, and managing many independent parts can be harder than managing one. Outside of situations where complexity is genuinely going to grow, the added sophistication rarely pays for itself. The failure to avoid is composable done wrong — bolting architecture onto a business that simply needed two systems to agree on a stock number.

So the right answer is sized to the pain, not to the trend. For the smallest estates with simple, non-critical flows where a little delay is harmless, a tidy automation tool is the correct answer — do not sell architecture there. For a growing business whose data has become mission-critical, the sweet spot is a proper integration layer plus one agreed source of truth for the two or three entities that actually cause the reconciliation pain. Only the most demanding cases — real-time operational dependence, frequent change, many channels — justify selective live events and genuinely composable parts, and even then introduced incrementally, around what already works, never as a from-scratch rebuild.

This is also where AI sits in the work — quietly, as method rather than headline. The slow, expensive parts of connecting systems are understanding an undocumented schema, reverse-engineering the script someone wrote years ago, drafting the mapping to a shared definition, and generating the tests that prove the new live flow matches the old one. AI now accelerates exactly those comprehension-and-mapping tasks, applied with engineering discipline and human review rather than guesswork. You see the outcome — your tools talking to each other in real time; AI is how the work gets done faster and more cheaply underneath.

If your team has quietly become the integration layer — copying data, reconciling by hand, arguing over which number is right — the first step is to map where the data really lives and where the staleness is costing you. Our free assessment at /application-modernisation/free-assessment does that: it traces your data flow, identifies the source-of-truth and the highest-pain feeds, and recommends the right-sized way to connect your systems — a tidy automation, a proper integration layer, or selective real-time events — without over-building or ripping out what works.