Capability to System Map

Enterprise architecture produces a great many diagrams and most of them answer no question anyone asked. The layered map below is the exception, because each layer exists to answer two specific questions, and the answers are usually uncomfortable.

Capability, and why it is drawn first#

A capability is what the organisation does, expressed so that it survives reorganisation. "Sell" is a capability. "The sales division" is a department, and departments are renamed every two years while the work stays the same.

This distinction is the reason the map is useful. Architecture organised by department has to be redrawn after every reorganisation and is therefore never current. Architecture organised by capability is stable for a decade, and the changes it does record are real changes to what the business does.

Keep the top level short — most organisations have fewer than a dozen. If the list is long, it is a list of departments or processes.

Applications, and the three uncomfortable patterns#

Mapping systems onto capabilities makes three things visible that nothing else does.

One capability supported by four systems is duplication, and it is expensive in a way that does not appear on any single budget: four licences, four integrations, four sets of training, and the reconciliation work that exists because the four disagree. It usually arises from acquisitions or from departments buying independently, and nobody sees it because each purchase was reasonable.

One system supporting six capabilities is the opposite problem. It cannot be replaced without replacing six things at once, which is why it never gets replaced, which is why it is still running on a version that went out of support in 2019.

A capability with no system is running on spreadsheets and a person's memory. This is not always wrong — some capabilities do not justify a system — but it should be a decision rather than a discovery, and the person concerned is usually a single point of failure nobody has named.

Data, and the definition layer#

The system-of-record question is the one most organisations think they have answered. The layer below it — definitions — is the one that causes the arguments.

Two dashboards disagreeing about active customers is almost never a data quality problem. It is two definitions, both correct, owned by nobody. The map records one owner per term, and that owner is a business person, not a data engineer.

Personal data belongs on this layer for a practical reason: the copies are the problem. Deleting a record from the system of record while it persists in three downstream copies and a reporting extract is a deletion that did not happen.

Integration, and the count nobody believes#

Ask an organisation how many integrations it has. Then count. The second number is typically two to three times the first.

Point-to-point links are drawn separately because of how they grow. Connect every system to every other and the links grow with the square of the systems: ten systems can have 45 links, twenty can have 190. Each is individually reasonable, and the total is a network nobody can change safely.

The undocumented ones are the dangerous ones — the nightly file drop, the shared folder somebody's macro reads, the export a finance analyst built in 2019 that three reports now depend on. They are load-bearing, they have no owner, and they are found when they break.

Using this map#

Build it at one level of detail — a page, not a repository — and read it downward for one capability at a time. Two results are nearly universal: a capability with four systems that nobody had counted, and an integration layer roughly twice as large as anyone thought.

Then use it for the only purpose that matters. When someone proposes buying a system, the map answers in a minute which capability it serves, what already serves that capability, what data it will duplicate, and how many links it adds. That is architecture affecting a decision, which is the thing the artefacts are for.

Back to Enterprise Architecture