Measuring and reporting the value of enterprise architecture

Measuring the value of enterprise architecture means showing, with evidence, that the architecture function changed an outcome the enterprise cares about, and that the change is worth more than the function costs. Put plainly, it is the difference between saying "we reviewed forty designs" and saying "designs now reach release five weeks faster because teams reuse agreed patterns". The first is activity. The second is value.

The technical term for this is the business value of the architecture capability: the contribution the function makes to the enterprise's own objectives, expressed in terms the enterprise already uses to judge any investment. The TOGAF Standard treats the architecture capability as something the enterprise establishes deliberately and expects a return from, in the same way it expects a return from any other capability it funds.

Value measurement matters for three reasons, and each maps to a real risk when it is missing.

• Survival. A function whose value is invisible is the first thing cut when budgets tighten. If the only evidence of worth is a list of activities, the function reads as an overhead, and overheads get trimmed.
• Direction. Measures shape behaviour. What the function chooses to measure is what its teams will work to improve. Measuring the wrong thing, such as the number of documents produced, quietly steers the function towards producing documents.
• Trust. A board that can see architecture value move over time learns to treat the function as a partner rather than a gate. The measures become the shared language in which architecture and leadership discuss trade-offs.

The MIT Center for Information Systems Research has argued for years that the firms which get the most from their technology are the ones that manage it as a measured, governed investment rather than as a cost to be minimised. The same logic applies to the architecture function: it is an investment, and investments are held to account by their returns.

The single most useful distinction in value measurement is between leading and lagging measures. A leading measure moves early and predicts a future outcome. A lagging measure moves late and confirms an outcome after it has happened.

Both are needed, and they answer different board questions. Leading measures answer "are we on track?". Lagging measures answer "did it work?". A scorecard built only from lagging measures tells the board the truth too late to act on it. A scorecard built only from leading measures predicts value it can never confirm. The two together let the board see both the direction of travel and the arrival.

For an architecture function, the mapping is usually clear.

• Leading: change lead time and pattern reuse. When teams reuse agreed patterns and changes flow faster, you are watching value form before it lands.
• Lagging: risk reduction and cost avoidance. Fewer resilience gaps and retired duplicate systems are outcomes you can only count once they have occurred.

A common mistake is to report only the lagging measures because they feel more solid. They are more solid, but by the time a cost has been avoided the decisions that avoided it are months old. The leading measures are what let the function steer while there is still time to change the result.

The discipline that makes a scorecard work is restraint. A short set of measures that the board reads every time beats a long dashboard nobody opens. Four measures is a good target: enough to cover flow, coherence, resilience, and money, few enough to fit on one page and be understood in a minute. Each measure needs the same four things.

1. A plain definition. What exactly is counted, so two people would count it the same way.
2. A baseline. The value at the start, so any movement can be read as improvement or regression rather than an isolated figure.
3. A source. Where the number comes from, so it can be trusted and re-checked.
4. A link to the investment case. The promise this measure holds the function to.

A practical starter set for an architecture function covers the four dimensions the function most directly influences.

• Change lead time (leading, flow). The time from a design starting to its first release. Architecture reduces it by removing rework and supplying reusable patterns.
• Pattern reuse (leading, coherence). The share of new builds that adopt an agreed reference pattern rather than a bespoke design. Reuse is the mechanism by which coherence turns into speed and lower cost.
• Risk reduction (lagging, resilience). The number of resilience or compliance gaps caught at design review rather than discovered in delivery or production. Architecture pulls the discovery of risk earlier, where it is cheaper to fix.
• Cost avoidance (lagging, investment return). Spend removed from the plan because architecture consolidated duplicated systems or prevented a redundant build. This is the measure finance recognises fastest.

Note the deliberate spread: two leading, two lagging. That balance is what lets the same scorecard answer both "are we on track?" and "did it work?".

A measure that floats free of the money is just a statistic. The step that turns a metric into evidence is tying it back to the investment case that authorised the work. Every transformation is funded against a set of promises: faster delivery, lower run cost, fewer incidents, a retired legacy platform. Those promises are exactly what the scorecard should measure.

The link works in both directions. Reading forward, each promise in the investment case should have a measure that tracks it, so the enterprise can see whether the promise is being kept. Reading backward, each measure on the scorecard should trace to a specific promise, so nothing is measured that nobody agreed to care about. When a measure has no home in the investment case, that is a signal to drop the measure or revisit the case.

This traceability is also what makes the reporting defensible. When the finance director asks why change lead time matters, the answer is not an architecture argument. It is: the ED2 investment case promised the network could absorb change faster, and this is the measure of that promise. The scorecard becomes the ledger against which the original commitment is settled.

Business architecture has long applied the same pairing to any stated goal: name the service that delivers it, then the measure that proves it.

A scorecard is the evidence. The narrative is how it is delivered so a board can act on it. The discipline is the same one that separates a decision paper from a status update: lead with the outcome, then show the movement, then name what you want the board to do.

A working board narrative has four parts, in this order.

1. Outcome first. One sentence on what changed for the enterprise. "Changes now reach release in less than half the time they took at the start of the price control."
2. The movement. The scorecard, each measure shown as baseline to current, so the board sees direction rather than a single figure.
3. The link to the case. Which promise in the investment case each movement settles, so the value is anchored to money already committed.
4. The ask. What the board is being invited to decide or continue funding, stated as a clear question, not an implied one.

The narrative should never open with what the architecture team did. Activity belongs at the back, as supporting detail, if at all. A board reads outcome, cost, and decision. Anything that makes it work to find those three is a narrative that will be politely received and quietly ignored.

London Grid Distribution serves 2.3 million customers across Greater London with 4,000 staff, 36,000 km of cable, and 77 primary substations, all under Ofgem's RIIO-ED2 price control. Its architecture function reports value on a single-page scorecard, refreshed every board cycle, with four measures.

The four measures

• Change lead time (leading). Design to first release fell from 18 weeks to 7 weeks as teams adopted reusable patterns and rework dropped. This settles the ED2 promise that the network could absorb change faster.
• Pattern reuse (leading). The share of new builds adopting an agreed reference pattern rose from one in five to three in five, as the shared catalogue was adopted across delivery teams.
• Risk reduction (lagging). Open resilience gaps fell from nine to two, because architecture review pulled the discovery of gaps forward from delivery into design.
• Cost avoidance (lagging). Three overlapping platforms became one retired platform, removing duplicated run cost from the plan. This is the measure Ofgem's efficiency scrutiny reads first.

The link to the investment case

Each measure traces to a promise in the ED2 business plan the function was funded against. Change lead time and reuse settle the flexibility promises; risk reduction settles the resilience commitment; cost avoidance settles the efficiency commitment. Because London operates under Ofgem, the same scorecard also feeds the efficiency and deliverability evidence the regulator expects, so the internal value report and the external regulatory story stay consistent.

The board narrative

The chief architect opens the review with the outcome, not the activity: changes now reach release in under half the time, at lower run cost, with resilience gaps caught earlier. The scorecard shows each movement from its baseline. The ask is explicit: continued funding for the pattern catalogue that drives the two leading measures. The finance director now has a number to place next to the team's cost, and the conversation is about return, not overhead.