From 200 systems to one operating layer
Why a sprawling technology estate costs more in the gaps than in the tools themselves, and how large firms replace it with one architecture that actually holds.
Twenty systems. Fifty. Two hundred. None of it planned, all of it accreted through growth, acquisition and quick fixes made under deadline pressure. Processes cross boundaries that were never designed to be crossed. Gaps appear where nobody was looking. Compliance becomes a manual prayer, assembled from memory and spreadsheets the night before it is due.
Every individual system in that estate was, in isolation, a reasonable decision at the time. The real cost was never the tools themselves. It has always lived in the gaps between them, and at the scale a large firm operates at, those gaps multiply far faster than most people realise.
How a firm ends up with two hundred systems
Growth outpaces architecture
As a firm grows, new services, new teams and new client types each tend to arrive with their own system, chosen to solve an immediate need rather than to fit a wider plan that, in a growing firm, may not yet exist in any formal sense.
Acquisition brings someone else’s patchwork with it
Every acquisition adds not just clients and staff, but an entire existing technology estate, rarely integrated fully, often left running in parallel because untangling it feels riskier than leaving it alone. A firm that has grown through several acquisitions is, in effect, running several other firms’ patchwork simultaneously.
Quick fixes solve today’s deadline and tomorrow’s problem
Under pressure, the fastest way to solve an immediate gap is almost always a new, narrow tool, built or bought to close one specific hole. It works. It also becomes one more system nobody centrally owns, adding to an estate that was already harder to reason about than anyone wants to admit.
None of these decisions were wrong in the moment they were made. The problem is that nobody was ever responsible for the sum of them.
The cost lives in the gaps, not the tools
Licensing a large number of systems is rarely, on its own, what makes a patchwork estate expensive. The real cost sits in the space between systems, where nothing was ever designed to connect.
| Where the cost hides | What it actually looks like |
|---|---|
| Manual reconciliation | Someone checking that two systems agree with each other, on a recurring basis, because nothing does it automatically |
| Duplicate data entry | The same client information typed into several systems by hand, each entry a fresh chance for an error to creep in |
| Compliance assembled under pressure | Evidence for an audit or a regulator pulled together from a dozen places at the last minute, rather than produced on demand |
| Institutional memory as infrastructure | Knowledge of how two systems actually relate to each other living in one person’s head, not in any documented process |
The gaps between your systems cost more than the systems do. They just never appear as a single line on any invoice.
Why the problem grows faster than the tool count
It is tempting to think a firm with two hundred systems has, roughly, two hundred problems. The reality is considerably worse, because the number of potential gaps between systems grows far faster than the number of systems itself. Every new tool does not simply add one relationship to manage. It adds a potential connection to every tool already in the estate.
Across 10 systems, that is 45 possible connections. Across 50 systems, 1,225. Across 200 systems, 19,900.
Most of those potential connections are never built deliberately, audited, or even noticed. They exist anyway, as unmanaged handoffs, manual workarounds and quiet assumptions about what the other system has already done. A firm does not need anywhere near the full mathematical maximum of connections to feel the effect. It only needs a fraction of them to be ungoverned before the gaps become the largest source of operational and compliance risk in the entire firm.
The exposure hiding inside the gaps
Patched estates are not only expensive. They are exposed, in a specific sense worth naming plainly. Every unmanaged connection between systems is also an unmonitored path for client data, and a large firm’s security posture is only ever as strong as the least visible of these gaps, not the average of its best defended systems.
Access control rarely survives two hundred systems intact
A leaver process that works cleanly in one system often misses several others entirely. Across a large estate, this quietly produces a long tail of access nobody remembers granting, to people who may no longer even work at the firm.
Shadow connections nobody approved
Where an official integration does not exist, staff build their own, an export here, an automated email there, a personal script bridging two systems that were never meant to talk. Each one is a genuine, sensible attempt to solve a real problem, and each one is also a connection the firm’s security function does not know exists.
A patchwork estate is not just slow and expensive. It is a security perimeter with a shape nobody has actually mapped.
Signs your estate has become patchwork
Worth checking honestly, at board level:
- Nobody in the firm could produce a complete, current list of every system in use without checking with several people first
- Compliance evidence for a routine request takes days to assemble rather than minutes to retrieve
- More than one team has, at some point, built its own workaround to connect two systems that should already talk to each other
- A recent acquisition’s systems are still running largely separately, months or years after the deal closed
- Nobody can say with confidence exactly who has access to what, across the whole estate, right now
None of these signs, alone, is a crisis. Together, and left unaddressed, they describe a firm whose real technology risk lives somewhere no single diagram has ever fully captured.
Why buying one bigger tool rarely fixes it
The instinctive response to sprawl is often to look for a single, larger platform to replace everything at once. This is worth treating with real caution. A new platform, however capable, becomes tool number two hundred and one the moment it is bought, with its own integration gaps to every system it does not fully replace, and every legacy process too embedded to migrate on day one.
The firms who genuinely fix this are not the ones who found a bigger tool. They are the ones who built a single architecture that sits above and across the existing estate, rather than one more addition to it.
What one architecture actually means
Turning two hundred tools into one does not mean deleting one hundred and ninety nine systems in a single disruptive project. For a large firm, that would be exactly the kind of high risk, big bang change a cautious, well run organisation is right to avoid.
It means building a single architecture, a connected layer of data, integration, context and governance, that becomes the one place every process actually runs through, regardless of which underlying systems it touches. Legacy tools are absorbed and connected where they still add value, and retired opportunistically where they do not, rather than ripped out on an artificial deadline.
You are not replacing two hundred tools with one tool that does two hundred things. You are replacing two hundred sets of gaps with one architecture that governs, connects and monitors everything running beneath it.
Why this works so well
One source of truth, instead of several that disagree
When every process runs through the same architecture, data stops needing to be reconciled between systems, because there is only one place it genuinely lives, with everything else simply reading from it.
One place to enforce a control, instead of two hundred
A compliance requirement applied at the architecture layer covers every process that runs through it automatically. Applied system by system, the same requirement has to be implemented, checked and maintained two hundred separate times, with every one of them a chance to fall out of date.
One audit trail, instead of a dozen scattered logs
When a regulator or a client asks how something happened, the answer lives in one place, not stitched together from whichever systems happened to be involved, recovered under time pressure.
One body of institutional knowledge, instead of tribal memory
How processes actually connect becomes documented in the architecture itself, rather than living in the memory of whichever long serving member of staff has always quietly bridged the gap.
A practical path that does not require a big bang
- Map the estate honestly, gaps included. List every system genuinely in use, and be equally honest about the manual workarounds bridging the spaces between them.
- Find the costliest gaps first, not the most visible tools. Prioritise by where reconciliation, duplication or compliance risk is actually concentrated, rather than by which system feels oldest.
- Build the unifying layer around the worst offenders. Start the architecture where it closes the most expensive gaps immediately, proving the approach before extending it further.
- Retire underlying systems opportunistically. Let legacy tools fall away naturally as the architecture absorbs what they did, rather than forcing a disruptive cutover date.
- Extend the architecture to every new acquisition or quick fix. Make the architecture the new default, so growth stops recreating the same sprawl it was built to solve.
What it looks like once the gaps are closed
Firms who complete this transition describe a similar shift. Compliance evidence is produced on demand, not assembled by hand under deadline pressure. A new acquisition gets connected into one architecture, rather than adding another disconnected stack to an estate already too large to reason about. Staff no longer need years of tribal knowledge to bridge gaps that were never supposed to exist in the first place.
None of that requires two hundred systems to disappear overnight. It requires one architecture, built deliberately, that the whole estate eventually runs through, and a firm willing to stop adding new gaps the moment it starts closing the old ones.
