Quick Navigation
- Start here — feelings are not measurements
- Why measurement usually fails
- The four delivery signals
- The five dimensions behind delivery
- Scoring, levels, and the trend
- What changes when you have a number
- Running it — 30 to 60 days
- Putting it all together
- Cheat sheet
Before we start — the one thing to hold onto
Before every flight, a pilot runs a checklist. Not because they are unsure — because the plane has a measurable state. Every dial has a reading. Every system has a status. The pilot does not say I think the fuel gauge is fine. They read the number, log the value, compare it against a threshold. Only then do they decide whether the aircraft is ready to fly.
Most organisations do not treat delivery this way. They say: our architecture is maturing, our governance is improving, we are becoming more agile.
Those are feelings, not measurements.
You cannot improve what you have not measured — and most delivery dashboards measure activity rather than the thing that is actually slow.
Keep it in mind.
1. Feelings are not measurements — start with "where are you now?"
When organisations want to improve delivery or architecture, they usually start by hiring consultants to draw a target architecture, adopting a new framework, running a transformation programme, or reorganising the architecture function.
These are answers. But they are answers to a question nobody has asked precisely.
The real question is: where are you now?
Not where you want to be. Not which framework you should adopt. Where are you, right now, across the dimensions that actually determine whether delivery works?
Without that answer, every investment is a guess. And a guess that costs a year of programme budget still looks like progress on a slide, which is why it survives.
flowchart LR
F["🗣️ Feeling\n'We are maturing'"] --> G["🎲 Guess\nWhich layer to invest in?"]
G --> W["💸 Wrong-layer investment\nEffort with no movement"]
M["📊 Measurement\nA score per dimension"] --> T["🎯 Target\nThe weakest dimension"]
T --> R["📈 Movement\nEvidence of improvement"]
Try it yourself — The three questions
Answer these before reading further. Answer them honestly, out loud, in the room.
| Question | Your answer | Did you guess? |
|---|---|---|
| If you had to score your architecture maturity today, which dimension would you score lowest? | ||
| Can you trace a sprint ticket from last month back to a named business objective? | ||
| When did governance last operate continuously, rather than waiting for the next review meeting? |
If the answers required guessing, you do not have a score. You have a feeling.
2. Why measurement usually fails — three failure modes
Plenty of organisations do measure. They still cannot act on what they measure. Most maturity and delivery assessments fail for one of three reasons.
They measure documentation, not behaviour. A framework is documented. A diagram exists. A policy has been written. None of these tell you whether architecture actually influences decisions, or whether the pipeline actually stops a bad change.
They produce levels, not signals. Level 1. Level 2. Level 3. These feel meaningful. But they do not tell you which dimension is holding you back, or which one to fix first. A level is a badge. A signal is a direction.
They are done once and filed. An assessment done in 2022 tells you nothing about 2026. Maturity is not static. It drifts. It degrades under delivery pressure. It needs to be scored regularly.
The same three failure modes show up in delivery dashboards. Story points closed is documentation of activity, not behaviour. A red-amber-green programme status is a level, not a signal. A quarterly delivery review that nobody revisits is measurement filed and forgotten.
A number you cannot act on is not a measurement. It is decoration.
3. The four delivery signals — what DORA actually asks
DORA — the DevOps Research and Assessment metrics — is the public, well-established baseline for measuring software delivery performance. It asks four questions, and only four:
- Deployment frequency — how often do you ship to production?
- Lead time for changes — how long from commit to running in production?
- Change failure rate — what proportion of changes cause an incident?
- Mean time to recovery (MTTR) — how long to restore service when something breaks?
What makes these four useful is what they refuse to measure. None of them counts effort. None of them counts tickets. Two measure throughput, two measure stability, and together they resist the trade-off that teams usually make silently — shipping faster by shipping worse, or getting safer by getting slower.
The shift is from did it work? to how often does it work? That reframing is usually the moment things click. Success stops being the story of one good release and becomes the distribution across all of them.
flowchart TD
D["📊 Four Delivery Signals"] --> TP["Throughput"]
D --> ST["Stability"]
TP --> F["Deployment Frequency\nHow often do we ship?"]
TP --> L["Lead Time for Changes\nCommit to production"]
ST --> C["Change Failure Rate\nHow often do changes break things?"]
ST --> M["Mean Time to Recovery\nHow fast do we restore?"]
Useful targets to work toward: deployment frequency moving from monthly toward weekly and then daily; change failure rate under ten percent; lead time falling; MTTR falling. Treat these as directions of travel with a baseline behind them, not as a pass mark.
Try it yourself — The DORA baseline
Look at your last month of deployments and fill this in from evidence, not memory.
| Signal | Where you are now | Where you want it in 90 days |
|---|---|---|
| Deployment frequency — how many? | ||
| Lead time — commit to deploy? | ||
| Change failure rate — how many caused incidents? | ||
| MTTR — how long to recover? |
If you cannot fill the first column from data, that is the finding. Stop the exercise and go get the numbers — everything after this depends on them.
4. The five dimensions behind delivery — measuring the system, not the output
The four delivery signals tell you that delivery is slow. They do not tell you why. A team with a twelve-day lead time and a fifteen percent change failure rate has a number and no diagnosis.
That diagnosis comes from scoring the system that produces the delivery. The Enterprise Architecture Maturity Score (EAMS) is a five-dimension scoring model built for exactly this — giving an architecture function a number it can act on, rather than a level or a badge.
Strategic Alignment — does architecture reflect what the business is trying to do, or what was decided three years ago? Low: architecture is a technical function with no direct line to business strategy. High: architecture decisions trace directly to named business outcomes.
Decision Velocity — how long does a decision take to move from insight to execution? This measures the mechanical speed of the decision system, not the quality of the decisions. Low: decisions wait in queues, approvals and review cycles for weeks. High: routine decisions are pre-authorised; only high-risk decisions require manual review.
Governance Cadence — is governance a gating mechanism or a guiding system? Low: governance meets monthly and decisions wait for the next meeting. High: governance runs continuously and decisions are validated at the point they are made.
Standards Adoption — do standards exist on paper, or in practice? Low: standards documents exist and teams build differently. High: standards are embedded in tooling, pipelines, and review gates.
Execution Traceability — can a sprint ticket be traced back to a business objective? This measures how much strategic meaning survives the journey from leadership to delivery. Low: strategy is translated three times before it reaches engineering, and meaning is lost at each step. High: strategic intent is traceable from the architecture decision all the way to the delivery artefact.
flowchart TB
A["📐 Maturity Score"]
A --> B["Strategic Alignment\nDoes architecture reflect\ncurrent business priorities?"]
A --> C["Decision Velocity\nInsight to execution —\nhow long?"]
A --> D["Governance Cadence\nContinuous or batched?"]
A --> E["Standards Adoption\nOn paper or in tooling?"]
A --> F["Execution Traceability\nTicket back to objective?"]
Note how each dimension maps to a delivery symptom you can already feel. Slow lead time is often Decision Velocity or Governance Cadence. A high change failure rate is often Standards Adoption. Work that ships and does not matter is Strategic Alignment or Execution Traceability. The dimensions are the why behind the four signals.
5. Scoring, levels, and the trend
Each dimension scores from 0 to 20. The total is 100.
flowchart LR
A["0–20\nReactive"] --> B["21–40\nEmerging"]
B --> C["41–60\nStructured"]
C --> D["61–80\nManaged"]
D --> E["81–100\nOptimized"]
| Level | Score | What it means |
|---|---|---|
| Reactive | 0–20 | Architecture is informal. Decisions are made without architectural input. |
| Emerging | 21–40 | Architecture exists but operates as documentation, not as a decision system. |
| Structured | 41–60 | Processes are defined. Standards exist. But consistency is uneven. |
| Managed | 61–80 | Architecture influences decisions systematically. Governance is active. |
| Optimized | 81–100 | Architecture, governance, and delivery operate as a continuous system. |
Two rules make the score honest.
Score where the evidence places you, not where you aspire to be. An aspirational score is a feeling with a number painted on it, which is worse than no number at all — it is harder to argue with.
Expect regression. The score can go down. Architecture quality degrades silently under delivery pressure: standards slip, traceability weakens, decision speed drops. If your score never moves backward, you are not scoring — you are reporting.
6. What changes when you have a number
Three conversations change immediately.
From feeling to evidence. Instead of "our architecture is improving," the organisation says: our score increased from 44 to 61 in six months, Standards Adoption moved from 8 to 16, Decision Velocity is still at 6 — that is where we invest next.
From framework adoption to targeted investment. Instead of "we need to adopt a framework," the question becomes: which of our five dimensions is weakest? And the investment goes to the layer that will move the score.
From annual reviews to continuous signal. Instead of "we did a maturity assessment in 2023," the assessment runs quarterly. It tracks movement. It spots regression early. It shows when delivery pressure is degrading governance cadence.
The asymmetry most organisations miss
flowchart LR
A["Architecture Investment ↑"] --> B["Architecture Output →"]
B --> C["Architecture Impact →"]
Investment goes up. Impact does not follow. Because the investment is targeting the wrong dimension.
A team that builds beautifully documented architecture with no traceability to delivery has high Standards Adoption and near-zero Execution Traceability. Adding more documentation moves nothing. The score reveals this. The feeling does not.
What breaks when nothing is measured
- Investment hits the wrong layer. A governance programme runs for two years when the real problem was Strategic Alignment. Governance was never the bottleneck — nobody measured precisely enough to know.
- Regression goes undetected. Standards slip, traceability weakens, decision speed drops, and the organisation does not notice until a delivery failure surfaces. By then the cause is invisible.
- Maturity becomes a story, not a state. Leadership says architecture is maturing. There is no baseline, no score, no trend. It is a narrative, and you cannot act on a narrative.
Try it yourself — Name the bottleneck
Score each dimension 0–20 from evidence you can point at. Then write down the single dimension you would fund next.
| Dimension | Score (0–20) | Evidence you scored it from |
|---|---|---|
| Strategic Alignment | ||
| Decision Velocity | ||
| Governance Cadence | ||
| Standards Adoption | ||
| Execution Traceability |
The bottleneck we are funding next: ______________
If two people in the room name different bottlenecks, you have not scored from evidence yet.
7. Running it — 30 to 60 days
Phase 1 — Baseline the score (weeks 1–2). Run the assessment across the architecture function, scoring each of the five dimensions honestly. Gather the four DORA signals in the same window so the diagnosis and the symptoms sit on one page. Deliverable: a baseline with dimension breakdown. Success metric: all five dimensions scored, at least one identified as the primary bottleneck.
Phase 2 — Prioritise one dimension (weeks 3–4). Do not attempt to improve all five at once. Identify the dimension with the lowest score that has the highest impact on your current strategic priorities, and build a plan for that one only. Deliverable: an improvement plan for one dimension. Success metric: three specific actions defined with measurable outcomes.
Phase 3 — Rescore and compare (weeks 5–8). Run the assessment again after six to eight weeks of targeted improvement. Compare. Measure the movement — not the intent, the movement. Deliverable: a comparative scorecard. Success metric: measurable improvement in the targeted dimension.
Then set the rhythm: quarterly scoring, dimension tracking built into governance, score movement reported to leadership alongside the delivery metrics. Use score movement as the evidence of return on architecture investment.
Evidence from practice
A retail company I worked with had been investing in architecture improvement for two years and could not tell you whether the architecture had improved. They had activities — workshops, reviews, documentation — but no measurement. The CTO described it as "improving something we have not measured."
Introducing the structured five-dimension assessment produced a baseline score of 3.2 out of 10. The team finally knew where they stood. Six months later the score was 5.1 — proof that the architecture investment was producing measurable improvement. The organisations that could not measure their architecture could not improve it. This one could.
Putting it all together
flowchart TD
SYM["Delivery symptoms\nSlow, fragile, unpredictable"] --> SIG["Four DORA signals\nFrequency · Lead time\nFailure rate · MTTR"]
SIG --> DIAG["Five-dimension score\nWhich part of the system is slow?"]
DIAG --> ONE["Fund one dimension\nThe weakest with the highest impact"]
ONE --> RESCORE["Rescore in 6–8 weeks\nMeasure movement, not intent"]
RESCORE --> DIAG
The delivery signals tell you the system is slow. The dimension score tells you which part. Funding one dimension and rescoring turns improvement from a story into a loop.
Score it. Then move the number.
Cheat Sheet — All the key terms
| Term | What it measures | Failure it prevents |
|---|---|---|
| Deployment frequency | How often you ship to production | Mistaking one good release for a capability |
| Lead time for changes | Commit to running in production | Optimising effort instead of flow |
| Change failure rate | Share of changes that cause incidents | Buying speed by shipping worse |
| Mean time to recovery | Time to restore service after failure | Treating incidents as bad luck |
| Strategic Alignment | Architecture against current business priorities | Building against three-year-old decisions |
| Decision Velocity | Insight to execution, mechanically | Decisions ageing in approval queues |
| Governance Cadence | Continuous versus batched governance | Decisions waiting for the next meeting |
| Standards Adoption | Documented standards versus practised ones | Standards that live only on paper |
| Execution Traceability | Strategic intent surviving to the artefact | Delivery that ships and does not matter |
How to know if this landed
You will know this landed when someone stops asking "can we deploy today?" and starts checking the dashboard. They can explain the four delivery signals in their own words. They can name which of the five dimensions is their bottleneck, and point at the evidence they scored it from. And when leadership asks whether architecture is improving, the answer is two numbers and a date range rather than an adjective.
The other tell is smaller and more reliable: someone reports a score going down, without softening it. That is the point where measurement has stopped being a performance.
Where this comes from
This module develops the argument in You Cannot Improve an Architecture You Have Not Measured, and runs alongside the Delivery Enablement & Quality Workshop session, where the DORA baseline and metrics dashboard are built for your own delivery data.
Book a Workshop
Ready to turn delivery maturity from a feeling into a score?
or
1-day workshop includes a DORA baseline from your own deployment history, a five-dimension maturity score with evidence notes, identification of your single bottleneck dimension, and a 30-day plan to move it.