No Large Company Actually Knows What Systems It Has

Ask the IT leadership of a large organisation how many systems they run and you will get a number. Then run an actual inventory and the number will be wrong, usually by a lot, and always in the same direction.

There will be systems nobody has owned since a reorganisation three years ago. Integrations built by a contractor whose documentation consists of the code. A nightly job on a server under someone's desk that a downstream report has depended on since 2019. A "temporary" file transfer between two departments that has been running for six years and now carries data the compliance team does not know exists.

This is not incompetence. It is the natural end state of any organisation large enough that no single person can hold the whole picture, over a long enough period that the people who built things have moved on.

And it is why integration projects fail — not because the wrong middleware was chosen.

The Failure Is Upstream of the Technology

The typical post-mortem on a failed integration programme blames the platform, the vendor, or the estimates. Look earlier and the pattern is consistent: the project was scoped against a model of the environment that was incomplete, and the gap surfaced during implementation, when it is most expensive.

The specific shape it takes:

A dependency nobody documented turns out to be load-bearing. You replace a system with a modern equivalent, and three weeks after cutover a regulatory report comes out wrong, because it was reading a field the old system populated as a side effect that nobody knew about.

The data does not mean what the schema says. A field called customer_status holds four documented values and, in production, eleven — because two departments encoded extra meaning in it years ago rather than requesting a schema change. Any transformation built from the documentation silently mishandles the other seven.

The system of record is contested. Two systems both hold customer addresses. Both are updated. Neither is authoritative. Every integration built on either one produces defensible, contradictory answers, and nobody can adjudicate because the ambiguity predates everyone in the room.

None of these are discovered by reading documentation. They are discovered by examining what the systems actually do, in production, with real data — which is slow, unglamorous, and the single highest-return activity in the whole programme.

Why the Sprawl Happens

The underlying dynamic is worth understanding because it explains why this keeps recurring.

Each individual integration is built point-to-point because that is the cheapest way to solve the immediate problem. System A needs data from System B, so someone writes a connection from A to B. Entirely correct as a local decision.

Do that for years and the count of connections grows roughly with the square of the number of systems. Thirty systems can host hundreds of pathways. At that density, nobody can reason about the whole, changing any system means investigating an unknown number of consumers, and the cost of every subsequent change rises.

The organisation did not decide to build this. It accumulated, one reasonable decision at a time — which is the same mechanism that produces most institutional problems, and it is why the answer is never "be more careful next time."

What Actually Reduces the Cost

Three things, in order.

Establish what is true before designing anything. A real inventory: what systems exist, who owns each one, what data each holds, what actually connects to what. Derived from observation — network traffic, database connections, job schedulers, log analysis — rather than from asking people, because people will describe the intended architecture rather than the operating one.

This phase feels like delay to executives who want to see progress. It is the cheapest possible time to find the eleven-values field.

Decide what the integration is for, in business terms. Not "integrate the CRM with the ERP." What decision gets made faster, what error stops happening, what does a customer experience differently. Integration projects that cannot answer this produce technically successful outcomes that nobody uses, and the gap between "the interface works" and "anything changed" is where a great deal of enterprise IT budget goes.

The related discipline is traceability: each technical requirement should map back to a stated business objective. Requirements that map to nothing are how scope grows, and they are always defended by someone with a good reason.

Move from point-to-point to something with a shape. Whether that is a hub, an event backbone, an API layer, or a service mesh matters far less than the fact that connections stop being bespoke. The value is not the technology — it is that a new system integrates once, against a known contract, rather than N times against N systems.

The sequencing is the part people get wrong. Introducing a platform before the inventory is done means building a modern integration layer around a model of the environment that is incorrect, which produces a well-architected system with the same undiscovered landmines underneath.

The Constraint Nobody Plans For

Every one of these programmes runs into the same wall eventually: the knowledge lives in a small number of people, and their time is the actual bottleneck.

The person who knows why the reconciliation job has that exception is also the person keeping the current systems running, and their calendar is already full. Programmes routinely plan for platform licensing, integration developers, and testing capacity, and fail to plan for the twenty hours a week of a handful of long-tenured people that the discovery phase genuinely requires.

When that time is not allocated, discovery does not stop. It just moves to implementation, where each missing fact arrives as a defect instead of a design input, at somewhere between ten and a hundred times the cost.

Integration is not fundamentally a technology problem. It is an archaeology problem with a technology deliverable at the end, and the projects that succeed are the ones that budget for the digging.

Designing Solutions Architecture for Enterprise Integration covers the full method — aligning integration with business goals, requirements gathering and traceability, assessing the current IT landscape, mapping data flows and dependencies, and the architectural patterns that follow.