Enterprise Architecture: Making the Whole Estate Coherent

Software architecture is about one system. Enterprise architecture is about the estate: how dozens of systems, owned by different departments, bought at different times, fit together — and how you change one without breaking three others.

It has a poor reputation, and often deservedly. Done badly it produces enormous diagrams nobody reads, a review board that slows delivery, and a model of the organisation that was accurate the month it was drawn. Done well it is the difference between an estate you can change and one that changes only through expensive projects.

What it is actually for#

Four questions a business genuinely needs answered:

What do we have? Which systems exist, what each does, who owns it, what it costs, what depends on it. Most organisations cannot answer this, which is why every project starts with a discovery phase re-learning it.

Where is the same thing done twice? Three systems holding customer records, four reporting tools, two overlapping CRMs from an acquisition. Duplication is expensive and it is invisible without a map.

What breaks if we change this? Dependency knowledge that usually lives in a few people's heads.

What should we do next? Which systems to invest in, retire or replace — and in what order, given what depends on what.

If your EA function answers those, it is earning its cost. If it produces documents that answer none, it is not.

The four layers#

The standard decomposition, in plain terms:

The layer most often skipped is data, and it is the one that causes the most pain. When nobody has agreed which system is authoritative for "customer", every integration invents its own answer and the organisation ends up with several versions of the truth.

The frameworks, briefly#

TOGAF — the most widely used. Its core is the ADM, a cycle for developing architecture from vision through to implementation and governance. Comprehensive, and heavy: applied literally it produces enormous documentation. Most successful adopters take the structure and discard perhaps three-quarters of the artefacts.

Zachman — a classification grid: six questions (what, how, where, who, when, why) against six perspectives. Not a process; a way of checking whether you have thought about everything. Useful as a completeness check.

ArchiMate — a modelling notation for describing architecture consistently. Solves the problem of every team drawing diagrams differently.

The honest position: frameworks are useful as vocabulary and as checklists. Organisations that adopt one wholesale, with all its artefacts, generally produce documentation rather than change.

Why EA functions fail#

They become a gate. A review board that must approve every design turns architects into an obstacle, and teams route around them. The board sees decisions too late to influence and too early to understand.

They model everything. A complete model of a large estate takes years and is out of date before it is finished. The value is in the parts that inform decisions, not in completeness.

They are disconnected from delivery. Architects who have not shipped anything recently produce designs that are theoretically clean and practically unbuildable.

They produce artefacts nobody consumes. If a document exists only because the framework lists it, stop making it.

They have no authority and no influence. Recommendations with neither teeth nor credibility get ignored, and then everyone concludes EA does not work.

Running one that works#

Start with the inventory. Systems, owners, purpose, cost, key dependencies. Keep it shallow and current rather than deep and stale. This alone answers more questions than any model.

Model only what informs a decision. If nobody is deciding anything about a system, do not document it in depth.

Set a small number of standards and enforce them. Fewer, clearer standards get followed. A hundred do not.

Engage early, advise rather than approve. Architects joining at the design stage as contributors are welcomed. Architects appearing at the approval gate are resented.

Publish decisions and rejected options. Same discipline as software architecture, at estate scale.

Measure something. Duplicate systems retired, integrations simplified, time-to-decision on technology questions. An EA function with no metrics cannot defend itself in a budget round, and usually does not survive one.

The pragmatic minimum#

For an organisation without a formal EA function, three artefacts deliver most of the value:

1. A system inventory — what exists, who owns it, what it costs
2. A data ownership map — which system is authoritative for each important entity
3. A decision log — significant technology decisions, with alternatives and reasoning

These fit in a few pages, can be maintained by someone part-time, and answer the questions that otherwise cost weeks of discovery on every project.

FAQ#

Do we need enterprise architecture?#

If you have more than a handful of systems and more than one team, you have enterprise architecture whether or not anyone is doing it deliberately — it is just emerging by accident. The question is whether it is managed.

Is TOGAF worth learning?#

The vocabulary and the ADM structure are genuinely useful, and the certification has recognised market value. Applying it literally and completely is where organisations get into trouble. Learn it, then use judgement about which artefacts earn their keep.

What is the difference between enterprise and solution architecture?#

Solution architecture designs one system to meet a specific need. Enterprise architecture governs how systems fit together across the organisation. Different scope, different time horizon; the same person can do both in a smaller organisation.

How do we stop EA slowing delivery?#

Advise early instead of approving late, keep the standard set small, and give teams a fast default path for common cases. Most friction comes from architects seeing work for the first time at a gate, when changing it is expensive and everyone is already committed.

How detailed should our models be?#

Detailed enough to answer a decision you are actually facing. The instinct to model completely is what produces years of work and a document nobody opens.

Who should own the data ownership map?#

The business, with architecture facilitating. Deciding that Finance owns the definition of "active customer" is a business decision, not a technical one — and it is the decision that stops two dashboards disagreeing.

How do we justify the cost?#

Point at duplication removed, projects that did not need a discovery phase, and decisions made in days rather than months. If you cannot point at those, the function is producing documents rather than value, and it is worth restructuring before someone else does it for you.

What else is coming for Enterprise Architecture