Take every measure from stable definition and manual baseline to automated, decision-relevant evidence.
16metric roadmaps
5maturity stages
6implementation facets
Choose an outcome
Each roadmap covers mechanics, data contract, stages, readiness, anti-gaming controls and asks.
ODM-01 · Implementation roadmap
Strategic alignment of investment
KRI · % · Green ≥90, Amber ≥80 (illustrative pending PLA negotiation) · Owner: Enterprise Architecture lead · Consumer: CIO / Investment Board · Cadence: Quarterly, reported with coverage · Family: F1 Strategy, Roadmap & Investment Alignment. Organising principle: Trace money to the map: the capability model and roadmap become the index against which every material investment is filed.
Percentage of Tier-1 investment (by approved value) traced to a target-state capability or architecture roadmap item at the investment approval gate.
Why it matters
The clearest single test of whether enterprise architecture steers the organisation or merely documents it. Untraced spend is where duplication, orphaned platforms and strategic drift originate.
Numerator
Approved value of Tier-1 investments linked at approval to a target-state capability or roadmap item
Denominator
Total approved value of Tier-1 investments in the period
What counts
A link to a specific capability or roadmap item, recorded before approval - not a retrospective tag or a generic 'digital transformation' label
Reporting rule
Always publish two numbers: the ODM value AND coverage (% of Tier-1 investment decisions taken through gates that apply the capability link). Coverage is the honesty device and the improvement lever.
2. The data contract (per investment decision)
#
Field
Notes
1
Investment / business case ID
From portfolio tooling
2
Approved value (£)
Whole-life value where available
3
Approval date and gate
Links to governance record
4
Capability ID(s)
From the architecture repository capability model
5
Roadmap item ID
Transition architecture or plateau reference
6
Alignment rating
Advances / neutral / diverges - EA assessment at gate
3. Staged roadmap
Stage
Timeframe
Activity
Exit criteria
Confidence label
0 - Define
4–6 weeks
Publish the alignment definition and rating scale with worked examples. Stabilise capability model IDs in the repository. Pick one pilot portfolio board.
Definition signed by pilot board chair; capability IDs frozen for the cycle
-
1 - Manual baseline
Q1–Q2
EA records capability links for pilot approvals by hand; quarterly roll-up by value. Share untraced list with sponsors.
Two quarterly cuts published; rating applied consistently
Directional - trends only, no targets
2 - Standardise at source
Q2–Q4
Capability and roadmap link fields added to business case template and portfolio tooling; EA assessment becomes a gate input for all Tier-1 boards.
≥70% of Tier-1 value flows through linked gates
Indicative - thresholds drafted
3 - Federate & automate
Year 2 H1
Automated join of portfolio and repository data; quarterly cut produced without manual effort. Negotiate the PLA target.
Capability and roadmap IDs recorded in business case template
All Tier-1 by end of Stage 2
L3
Alignment rating used in prioritisation scoring
During Stage 3
L4
Automated feed from portfolio tooling to metrics store
With Stage 3 tooling
5. Quality and anti-gaming controls
Risk
Effect
Control
Retrospective tagging
Links added after approval to look aligned
Only links timestamped before approval count; QA sample each quarter
Over-broad capabilities
Everything maps to 'Customer Management'
Link at level-2 capability or below; EA challenges level-1 links
Low-value dilution
Many small aligned items mask one large untraced one
Report by value, not count; list top-5 untraced investments by name
Model churn
Capability IDs change and break history
Version the capability model; map retired IDs forward
6. Asks of Portfolio boards
#
Ask
1
Add capability and roadmap link fields to the business case template
2
Invite EA alignment assessment as a standing gate input
3
Nominate a portfolio data counterpart for the quarterly cut
4
Challenge untraced proposals above an agreed value threshold
5
Accept an annual review of the capability model with EA
ODM-02 · Implementation roadmap
Transition architecture delivery
KPI · % · Green ≥80, Amber ≥65 (illustrative pending PLA negotiation) · Owner: Solutions Architecture lead · Consumer: Portfolio Board / Programme Directors · Cadence: Quarterly, reported with coverage · Family: F1 Strategy, Roadmap & Investment Alignment. Organising principle: Measure roadmaps as commitments: a transition architecture that never lands is a slide, not a plan.
Percentage of architecture roadmap milestones (transition architecture plateaus) delivered within one quarter of plan.
Why it matters
Tests whether architecture roadmaps are realistic and whether delivery honours them. Persistent slippage signals either over-optimistic sequencing or governance that lets programmes diverge.
Numerator
Roadmap milestones delivered within one quarter of the baselined plan date
Denominator
Roadmap milestones due in the period
What counts
Milestones that represent a transition architecture plateau or capability increment - not internal project tasks
Reporting rule
Always publish two numbers: the ODM value AND coverage (% of Tier-1 programmes whose milestones are held in the roadmap register). Coverage is the honesty device and the improvement lever.
2. The data contract (per roadmap milestone)
#
Field
Notes
1
Milestone ID
From the roadmap register
2
Programme / project ID
Maps to delivery vehicle
3
Capability / plateau reference
Links to target-state architecture
4
Baseline date
Under change control
5
Actual or forecast date
Updated monthly
6
Dependency IDs
Upstream milestones it relies on
3. Staged roadmap
Stage
Timeframe
Activity
Exit criteria
Confidence label
0 - Define
4–6 weeks
Define what qualifies as a roadmap milestone; baseline the current architecture roadmap; agree the change-control rule for plan dates.
Roadmap register baselined for pilot programmes
-
1 - Manual baseline
Q1–Q2
SA leads update forecast dates monthly by hand; quarterly calculation with RAG narrative.
Two quarterly cuts published
Directional - trends only, no targets
2 - Standardise at source
Q2–Q4
Milestones mirrored in portfolio tooling with architecture plateau references; dependency conflicts flagged automatically.
≥70% of Tier-1 programmes in register
Indicative - thresholds drafted
3 - Federate & automate
Year 2 H1
Automated extract from portfolio tooling; slippage alerts to EA and programme boards. Negotiate the PLA target.
≥90% coverage; manual adjustment rare
PLA-grade - target negotiated; ambers actioned
4 - Institutionalise
Ongoing
Roadmap delivery reviewed at every quarterly architecture board; replanning uses the evidence.
Roadmap re-baselined annually with history retained
Sustained
4. Readiness ladder - Programmes
Level
Criteria
Target date
L0
No link between programme plans and architecture roadmap
-
L1
Architecture milestones identified in programme plan
Pilot by end of Stage 1
L2
Milestones in roadmap register with baseline under change control
All Tier-1 by end of Stage 2
L3
Dependencies recorded and monitored
During Stage 3
L4
Automated feed from portfolio tooling
With Stage 3 tooling
5. Quality and anti-gaming controls
Risk
Effect
Control
Re-baselining to green
Plan dates moved to hide slippage
Baseline change requires board approval; report against original baseline too
Milestone inflation
Trivial milestones pad the denominator
EA approves milestone list; only plateau-level items qualify
Hollow delivery
Milestone marked done without capability landing
Completion needs evidence (e.g. service accepted, legacy switched off)
Hidden dependencies
Slippage cascades unseen
Dependency field mandatory; conflicts escalated monthly
6. Asks of Programmes
#
Ask
1
Map programme milestones to architecture plateaus
2
Hold plan dates under change control
3
Update forecasts monthly
4
Nominate a data counterpart
5
Escalate cross-programme dependency conflicts to the Design Authority
ODM-03 · Implementation roadmap
Capability assessment currency
KCI · % · Green ≥90, Amber ≥75 (illustrative pending PLA negotiation) · Owner: Enterprise Architecture lead · Consumer: COO / Business Capability Owners · Cadence: Semi-annual, reported with coverage · Family: F1 Strategy, Roadmap & Investment Alignment. Organising principle: A stale capability map is worse than none: it lends false confidence to investment decisions.
Percentage of Tier-1 business capabilities with current- and target-state assessment (maturity, investment, risk) refreshed within the last 12 months.
Why it matters
Leading indicator for ODM-01. If capability assessments are out of date, alignment decisions are made against yesterday's business.
Numerator
Tier-1 business capabilities with current- and target-state assessment refreshed within 12 months
Denominator
All Tier-1 business capabilities
What counts
An assessment covering maturity, investment and risk, signed off by the capability owner - not an EA desk update
Reporting rule
Always publish two numbers: the ODM value AND coverage (% of Tier-1 capabilities with a named business owner). Coverage is the honesty device and the improvement lever.
2. The data contract (per capability)
#
Field
Notes
1
Capability ID
From the capability model
2
Tier
Agreed with COO
3
Business owner
Named individual
4
Last assessment date
Date of owner sign-off
5
Maturity / heat-map scores
Common scale
6
Linked roadmap items
Where gaps are being addressed
3. Staged roadmap
Stage
Timeframe
Activity
Exit criteria
Confidence label
0 - Define
4–6 weeks
Agree Tier-1 capability list and assessment template; name owners.
Tier-1 list and template signed off by COO
-
1 - Manual baseline
Q1–Q2
EA runs assessment workshops for a first tranche; results held in repository.
Pilot tranche assessed
Directional - trends only, no targets
2 - Standardise at source
Q2–Q4
Assessment cycle scheduled per business area; owners sign off in repository workflow.
≥70% of Tier-1 capabilities assessed
Indicative - thresholds drafted
3 - Federate & automate
Year 2 H1
Repository reports currency automatically; overdue assessments flagged to owners. Negotiate the PLA target.
≥90% current
PLA-grade - target negotiated; ambers actioned
4 - Institutionalise
Ongoing
Capability assessment feeds annual business planning and investment prioritisation.
Assessments cited in planning round
Sustained
4. Readiness ladder - Business areas
Level
Criteria
Target date
L0
No capability owners or assessments
-
L1
Owners named for Tier-1 capabilities
Pilot by end of Stage 1
L2
Assessment completed and signed off
All Tier-1 by end of Stage 2
L3
Assessment refreshed on cycle and linked to roadmap
During Stage 3
L4
Currency reported automatically from the repository
With Stage 3 tooling
5. Quality and anti-gaming controls
Risk
Effect
Control
Desk-top updates
EA refreshes dates without business input
Owner sign-off mandatory; date only counts on sign-off
Tier creep
Hard capabilities quietly demoted from Tier-1
Tier changes approved by COO
Assessment fatigue
Owners disengage
Short, templated assessments; reuse data from portfolio and ITSM
Inconsistent scoring
Scores not comparable
Common scale with calibration session each cycle
6. Asks of Business areas
#
Ask
1
Name an owner for each Tier-1 capability
2
Commit to an annual assessment slot
3
Sign off assessments in the repository
4
Use the heat-map in business planning
5
Nominate a business architecture counterpart
ODM-04 · Implementation roadmap
Design-stage defect capture
KPI · % · Green ≥80, Amber ≥65 (illustrative pending PLA negotiation) · Owner: Solutions Architecture lead · Consumer: CIO / Portfolio Board · Cadence: Quarterly, reported with coverage · Family: F2 Design Quality, Standards & Reuse. Organising principle: Catch it on the whiteboard: every design flaw found in production cost ten times what it would have at design.
Architecture and design defects identified at or before the Design gate as a percentage of all design defects found in the period (including build, test and production escapes).
Why it matters
The core quality measure for solution architecture. A low capture rate means reviews are missing, shallow or too late, and rework is being paid for downstream.
Numerator
Architecture and design defects identified at or before the Design gate (review findings, design spikes)
Denominator
All design defects in the period, including escapes found in build, test, NFR testing or production problem records
What counts
Defects whose root cause is a design decision - not coding errors or environment faults
Reporting rule
Always publish two numbers: the ODM value AND coverage (% of Tier-1 projects whose defect data meets the contract). Coverage is the honesty device and the improvement lever.
2. The data contract (six fields per defect - any tracker qualifies)
#
Field
Notes
1
Project / portfolio ID
Maps the record to a PMO and the Tier-1 scope list
2
Date and lifecycle phase found
Phase at detection, not at fix
3
Design-attributable flag (Y/N)
'Should this have been caught at design?' - governed by a written triage rule
Publish metric specification (data contract, severity mapping, Design-gate definitions, triage rule). Select one pilot portfolio. Name metric owner (SA lead) and PMO counterpart.
Specification signed by pilot PMO; Tier-1 scope list agreed
-
1 - Manual baseline
Q1–Q2
Design review findings logged in one simple register. Quarterly manual sweep of pilot trackers; SA triages design-attributability. Publish first cut with coverage.
Two quarterly cuts published; triage rule stable
Directional - trends only, no targets
2 - Standardise at source
Q2–Q4
Each PMO adds design-attributable flag and phase field to its own tracker (field mapping, not migration). Architecture review becomes a Tier-1 gate requirement. Escapes tagged at problem RCA.
Effort/cost of post-build change attributable to architecture or design decisions, as a percentage of total delivery spend on in-scope initiatives.
Why it matters
The money slide of the framework: the invisible tax of late redesign made visible. It funds the case for early engagement (ODM-15) and design-stage capture (ODM-04).
Numerator
Post-build changes flagged architecture/design-driven (integration redesign, scaling retrofit, platform change, NFR rework), costed in £ or effort-days
Denominator
Total delivery spend (or effort) on in-scope initiatives in the period
What counts
Rework caused by design decisions that could reasonably have been made at design - not new scope or genuine external change
Reporting rule
Always publish two numbers: the ODM value AND coverage (% of Tier-1 change volume passing through boards that apply the flag). Coverage is the honesty device and the improvement lever.
2. The data contract (per change record)
#
Field
Notes
1
Change record ID
From each PMO's change/delivery tooling
2
Project / portfolio ID
Maps to PMO and Tier-1 scope
3
Design-driven flag (Y/N)
Set at change triage against the written definition
Percentage of new deployments conformant with the approved reference pattern or configuration baseline that specifies them; drift detected within 30 days via configuration compliance scanning.
Why it matters
Pairs with ODM-04 and ODM-07 to check that approved designs are what actually runs. Drift is a leading cause of incidents and support cost.
Numerator
New deployments conformant with the specifying pattern or baseline at scan; drift items detected within 30 days
Denominator
All pattern- or baseline-specified deployments in the period
What counts
Conformance measured by automated scan against a version-controlled baseline - not self-attestation
Reporting rule
Always publish two numbers: the ODM value AND coverage (% of Tier-1 estate within configuration scanning coverage). Coverage is the honesty device and the improvement lever.
2. The data contract (per deployment / configuration item)
#
Field
Notes
1
CI / deployment ID
From CMDB
2
Specifying pattern / baseline ID and version
From architecture repository
3
Scan date and result
Pass / fail by rule
4
Drift detected date
First scan showing deviation
5
Dispensation ID (if any)
Approved deviation excluded from fail count
6
Remediation date
Closes the drift item
3. Staged roadmap
Stage
Timeframe
Activity
Exit criteria
Confidence label
0 - Define
4–6 weeks
Select patterns and baselines in scope; express as machine-checkable rules for one platform. Name OA lead as owner.
Rule set agreed for pilot platform
-
1 - Manual baseline
Q1–Q2
Manual or semi-automated scans on pilot platform; results reviewed monthly.
Two monthly cuts; false-positive rate understood
Directional - trends only, no targets
2 - Standardise at source
Q2–Q4
Baselines codified (policy as code) across Tier-1 platforms; scan results linked to CMDB.
≥70% Tier-1 scan coverage
Indicative - thresholds drafted
3 - Federate & automate
Year 2 H1
Continuous scanning with automated drift alerts; monthly cut automated. Negotiate the PLA target.
≥95% scan coverage; drift age reported
PLA-grade - target negotiated; ambers actioned
4 - Institutionalise
Ongoing
Conformance and drift reviewed at platform service reviews; baselines refreshed with standards.
Sustained coverage through platform change
Sustained
4. Readiness ladder - Platform teams
Level
Criteria
Target date
L0
No documented baselines
-
L1
Baselines documented for Tier-1 platforms
Pilot by end of Stage 1
L2
Baselines codified as scan rules
All Tier-1 by end of Stage 2
L3
Continuous scanning with drift alerting
During Stage 3
L4
Results feed metrics store automatically
With Stage 3 tooling
5. Quality and anti-gaming controls
Risk
Effect
Control
Baselines too loose
Everything passes
EA/OA review of rule strength; sample against pattern intent
Dispensation abuse
Deviations excluded by blanket dispensations
Only in-date, specific dispensations excluded (ties to ODM-09)
Scan blind spots
Unscanned estate assumed compliant
Report coverage alongside the value
Alert fatigue
Drift alerts ignored
Prioritise by service tier; track drift age not just count
6. Asks of Platform teams
#
Ask
1
Codify baselines for Tier-1 platforms
2
Enable scanning and link results to CMDB
3
Remediate drift within 30 days or raise a dispensation
4
Nominate a platform data counterpart
5
Review conformance at service reviews
ODM-07 · Implementation roadmap
Requirements & NFR traceability integrity
KCI · % · Green ≥95, Amber ≥85 (illustrative pending PLA negotiation) · Owner: Solutions Architecture lead · Consumer: Change / Programme Boards · Cadence: Quarterly, reported with coverage · Family: F3 Governance, Traceability & Decision Assurance. Organising principle: If you cannot trace it, you cannot prove it: every requirement, including the non-functional ones, needs a path to evidence.
Percentage of Tier-1 changes whose functional and non-functional requirements trace to design elements and verification evidence at go-live (requirement → design → evidence).
Why it matters
Non-functional requirements (performance, availability, operability, security) are the ones most often lost between design and go-live - and the ones most expensive to recover in production.
Numerator
Tier-1 changes with complete requirement → design element → verification evidence chain at go-live
Denominator
All Tier-1 changes going live in the period
What counts
Complete chains for all mandatory requirements, including NFRs - partial chains do not count
Reporting rule
Always publish two numbers: the ODM value AND coverage (% of Tier-1 changes managed in a traceable requirements tool). Coverage is the honesty device and the improvement lever.
2. The data contract (per requirement)
#
Field
Notes
1
Requirement ID
From requirements repository
2
Type
Functional / NFR (quality attribute)
3
Design element reference
Architecture repository or design document section
4
Verification method
Test, demonstration, inspection, analysis
5
Evidence reference
Test result or acceptance record
6
Status at go-live
Verified / waived / open
3. Staged roadmap
Stage
Timeframe
Activity
Exit criteria
Confidence label
0 - Define
4–6 weeks
Agree the trace model and NFR catalogue template (aligned to ISO/IEC 25010). Pilot on two projects.
Trace model approved by Design Authority
-
1 - Manual baseline
Q1–Q2
SA maintains traceability manually for pilots; broken-link review at go-live gate.
Two quarterly cuts published
Directional - trends only, no targets
2 - Standardise at source
Q2–Q4
Trace fields enforced in requirements and test tooling; link to architecture repository.
≥70% of Tier-1 changes traceable
Indicative - thresholds drafted
3 - Federate & automate
Year 2 H1
Broken-link report automated at go-live gate; quarterly cut automated. Negotiate the PLA target.
≥90% coverage; broken-link report zero at gate
PLA-grade - target negotiated; ambers actioned
4 - Institutionalise
Ongoing
Traceability evidence reused for audit and assurance; NFR catalogue refreshed annually.
Evidence accepted by audit without rework
Sustained
4. Readiness ladder - Delivery teams
Level
Criteria
Target date
L0
Requirements in documents; no traceability
-
L1
Requirements baselined including NFRs
Pilot by end of Stage 1
L2
Links from requirements to design recorded
All Tier-1 by end of Stage 2
L3
Verification evidence linked at go-live
During Stage 3
L4
Automated broken-link reporting
With Stage 3 tooling
5. Quality and anti-gaming controls
Risk
Effect
Control
Tick-box links
Links exist but point to nothing meaningful
QA sample 10% of chains per quarter
NFRs omitted
Chain complete only for functional scope
NFR catalogue mandatory for Tier-1; SA sign-off
Waiver creep
Unverified items waived to pass gate
Waivers count as incomplete; report waiver rate separately
Tool burden
Teams resist traceability admin
Minimise fields; automate links from test tooling
6. Asks of Delivery teams
#
Ask
1
Use the NFR catalogue template for Tier-1 work
2
Maintain requirement-to-design links
3
Attach verification evidence before go-live gate
4
Nominate a data counterpart
5
Treat broken links as a gate condition
ODM-08 · Implementation roadmap
Design Authority decision cycle time
KPI · working days (median) · Green ≤10, Amber ≤15 (illustrative pending PLA negotiation) · Owner: Enterprise Architecture lead · Consumer: CTO / Delivery Leadership · Cadence: Quarterly, reported with coverage · Family: F3 Governance, Traceability & Decision Assurance. Organising principle: Slow governance is bad governance: delay pushes teams around the Design Authority rather than through it.
Median working days from a complete Design Authority submission to a recorded decision (approve, approve with conditions, reject), reported by tier.
Why it matters
The counterweight to the rest of F3. Rigorous governance that takes weeks to decide creates shadow architecture and erodes early engagement (ODM-15).
Numerator
Median working days from complete submission to recorded decision
Denominator
(median - no denominator) calculated over all decisions in the period, by tier
What counts
Clock starts at complete submission against the published checklist; stops at recorded decision including conditional approval
Reporting rule
Always publish two numbers: the ODM value AND coverage (% of architecture decisions recorded in the Design Authority log (vs taken informally)). Coverage is the honesty device and the improvement lever.
2. The data contract (per submission)
#
Field
Notes
1
Submission ID
From Design Authority log
2
Tier
1/2/3 by risk and value
3
Submission-complete date
Checklist satisfied
4
Decision date
Recorded outcome
5
Outcome
Approve / conditions / reject / defer
6
Clock-stop reason (if any)
Awaiting submitter information
3. Staged roadmap
Stage
Timeframe
Activity
Exit criteria
Confidence label
0 - Define
4–6 weeks
Publish tiering, submission checklist and turnaround commitment. Stand up decision log.
Terms of reference approved
-
1 - Manual baseline
Q1–Q2
Log maintained by secretariat; quarterly median reported with distribution.
Two quarterly cuts published
Directional - trends only, no targets
2 - Standardise at source
Q2–Q4
Submission workflow in tooling with timestamps; Tier-3 decisions delegated to domain architects.
Turnaround published to delivery community; terms of reference reviewed annually.
Delivery satisfaction trend positive
Sustained
4. Readiness ladder - Design Authority and domains
Level
Criteria
Target date
L0
Ad hoc decisions; no log
-
L1
Decision log maintained
Pilot by end of Stage 1
L2
Tiering and submission checklist in use
All Tier-1 by end of Stage 2
L3
Delegated Tier-3 decisions; timestamps in workflow
During Stage 3
L4
Automated cycle-time reporting
With Stage 3 tooling
5. Quality and anti-gaming controls
Risk
Effect
Control
Clock games
Submissions judged incomplete to stop the clock
Completeness challenge logged; sample audited
Decisions offline
Informal decisions bypass the log
Only logged decisions are valid for gate passage
Speed over quality
Fast approvals with weak scrutiny
Pair with ODM-04 and ODM-09 trends
Deferral loop
Repeated deferrals avoid a decision
Deferrals count toward cycle time; second deferral escalates
6. Asks of Design Authority and domains
#
Ask
1
Submit against the published checklist
2
Accept delegated Tier-3 decisions
3
Record all architecture decisions in the log
4
Nominate a secretariat owner
5
Publish turnaround performance quarterly
ODM-09 · Implementation roadmap
Dispensation health
KRI · % · Green ≥95, Amber ≥85 (illustrative pending PLA negotiation) · Owner: Enterprise Architecture lead · Consumer: Design Authority / CTO · Cadence: Quarterly, reported with coverage · Family: F3 Governance, Traceability & Decision Assurance. Organising principle: A dispensation is a loan: it needs an owner, a term and a repayment plan.
Percentage of active architecture dispensations with a named owner, in-date expiry and a funded or scheduled remediation path; no dispensation past expiry without re-authorisation.
Why it matters
Unmanaged exceptions become the de facto standard and silently accumulate technical debt. This metric keeps deviation conscious and bounded.
Numerator
Active dispensations with named owner, in-date expiry and remediation path
Denominator
All active dispensations
What counts
Remediation path means funded or scheduled work - 'to be reviewed' does not count
Reporting rule
Always publish two numbers: the ODM value AND coverage (% of known deviations recorded as dispensations (sampled via ODM-06 scans and gate reviews)). Coverage is the honesty device and the improvement lever.
2. The data contract (per dispensation)
#
Field
Notes
1
Dispensation ID
From dispensation register
2
Standard / principle deviated from
Link to repository
3
Owner
Named accountable individual
4
Expiry date
Maximum 12 months
5
Remediation path
Funded / scheduled / none
6
Compensating measures
Where risk requires
3. Staged roadmap
Stage
Timeframe
Activity
Exit criteria
Confidence label
0 - Define
4–6 weeks
Define dispensation policy, maximum term and register fields.
Policy approved by Design Authority
-
1 - Manual baseline
Q1–Q2
Existing exceptions migrated to register; monthly lapsed report.
Register populated for Tier-1
Directional - trends only, no targets
2 - Standardise at source
Q2–Q4
Dispensation workflow in tooling; expiry alerts to owners.
≥70% of dispensations via workflow
Indicative - thresholds drafted
3 - Federate & automate
Year 2 H1
Automated health reporting; lapsed items auto-escalated. Negotiate the PLA target.
≥95% health; no unmanaged lapses
PLA-grade - target negotiated; ambers actioned
4 - Institutionalise
Ongoing
Lapsed dispensations converted to technical debt items (feeds ODM-11).
Conversion rule operating
Sustained
4. Readiness ladder - Domains
Level
Criteria
Target date
L0
Exceptions untracked
-
L1
Dispensations recorded with owner
Pilot by end of Stage 1
L2
Expiry and remediation path mandatory
All Tier-1 by end of Stage 2
L3
Workflow with alerts
During Stage 3
L4
Automated reporting and debt conversion
With Stage 3 tooling
5. Quality and anti-gaming controls
Risk
Effect
Control
Perpetual renewal
Dispensations renewed indefinitely
Second renewal requires CTO approval
Unrecorded deviation
Register looks healthy because deviations are hidden
Cross-check against ODM-06 scan failures
Vague remediation
Paths without funding
Only funded or scheduled paths count
Owner churn
Owners leave; items orphaned
Monthly orphan report; reassign within 30 days
6. Asks of Domains
#
Ask
1
Record all deviations as dispensations
2
Name an accountable owner for each
3
Plan remediation before expiry
4
Respond to expiry alerts
5
Nominate a domain register counterpart
ODM-10 · Implementation roadmap
Technology currency
KRI · % · Green ≥95, Amber ≥85 (illustrative pending PLA negotiation) · Owner: Operational Architecture lead · Consumer: CTO / Service Owners · Cadence: Monthly, reported with coverage · Family: F4 Estate Health, Technical Debt & Lifecycle. Organising principle: End of support is a date, not a surprise: every component has one, and it is published years in advance.
Percentage of Tier-1 service components (OS, middleware, database, runtime, platform) within vendor support, or covered by an approved and funded exit plan.
Why it matters
Unsupported technology drives security exposure, forced upgrades and unplanned cost. It is one of the most predictable risks in the estate - and one of the most commonly missed.
Numerator
Tier-1 service components within vendor support or covered by an approved, funded exit plan
Denominator
All Tier-1 service components
What counts
Components at product-version level (OS, database, middleware, runtime, platform); extended support counts only if contracted
Reporting rule
Always publish two numbers: the ODM value AND coverage (% of Tier-1 components with product and version recorded in CMDB). Coverage is the honesty device and the improvement lever.
2. The data contract (per component)
#
Field
Notes
1
CI ID
From CMDB
2
Product and version
Normalised against reference catalogue
3
Service and tier
Link to business service
4
Vendor end-of-support date
Reference data
5
Exit plan ID and funding status
Where out of support or within 12 months
6
Owner
Accountable platform or service owner
3. Staged roadmap
Stage
Timeframe
Activity
Exit criteria
Confidence label
0 - Define
4–6 weeks
Agree component classes in scope and reference data source for support dates.
Scope and data source agreed
-
1 - Manual baseline
Q1–Q2
Manual extract from CMDB for Tier-1 services; OA matches to support dates.
Two monthly cuts; data gaps listed
Directional - trends only, no targets
2 - Standardise at source
Q2–Q4
CMDB discovery normalised against reference catalogue; exit plans recorded.
≥70% of Tier-1 components normalised
Indicative - thresholds drafted
3 - Federate & automate
Year 2 H1
Automated currency report with 12-month horizon alerts (CI-09). Negotiate the PLA target.
≥95% CMDB completeness
PLA-grade - target negotiated; ambers actioned
4 - Institutionalise
Ongoing
Currency feeds lifecycle roadmap and annual investment planning.
Refresh funded ahead of end-of-support
Sustained
4. Readiness ladder - Platform and service owners
Level
Criteria
Target date
L0
Versions unknown
-
L1
Tier-1 versions recorded
Pilot by end of Stage 1
L2
Support dates matched and horizon reviewed
All Tier-1 by end of Stage 2
L3
Exit plans funded for at-risk components
During Stage 3
L4
Automated currency reporting
With Stage 3 tooling
5. Quality and anti-gaming controls
Risk
Effect
Control
CMDB gaps
Unknown components assumed in support
Report coverage; unknowns counted as out of support
Paper exit plans
Unfunded plans counted
Only approved and funded plans count
Extended support illusion
Paid support hides obsolescence
Report extended-support components separately
Embedded components
Libraries and appliances missed
Include SBOM and appliance data progressively
6. Asks of Platform and service owners
#
Ask
1
Keep product and version data current in CMDB
2
Plan and fund exits 12 months ahead
3
Record exit plans against components
4
Nominate a platform data counterpart
5
Review currency at service reviews
ODM-11 · Implementation roadmap
Technical debt exposure
KRI · index (baseline 100) · Green ≤100, Amber ≤130 (illustrative pending PLA negotiation) · Owner: Enterprise Architecture lead · Consumer: CTO / Investment Board · Cadence: Quarterly, reported with coverage · Family: F4 Estate Health, Technical Debt & Lifecycle. Organising principle: Debt you cannot see compounds fastest: make it visible, price it, then pay it down.
Weighted index of open technical-debt items on critical services (severity × age), baselined at 100; no item older than 12 months without owner re-authorisation.
Why it matters
Technical debt erodes delivery velocity and resilience. The index gives leadership a single trend for accumulated architectural risk, and the 12-month rule stops items going stale.
Numerator
Σ (severity weight × age factor) of open debt items on critical services
Denominator
Indexed to baseline = 100 at first stable quarter
What counts
Items with a design or technology root cause - not backlog features; includes lapsed dispensations
Reporting rule
Always publish two numbers: the ODM value AND coverage (% of critical services that have completed a debt assessment). Coverage is the honesty device and the improvement lever.
2. The data contract (per debt item)
#
Field
Notes
1
Debt item ID
From technical debt register
2
Service
Critical service reference
3
Severity
Common 4-point scale
4
Raised date
Drives age factor
5
Owner
Named accountable individual
6
Remediation status and target date
Linked to roadmap or backlog
3. Staged roadmap
Stage
Timeframe
Activity
Exit criteria
Confidence label
0 - Define
4–6 weeks
Agree debt definition, severity scale, age factor and weighting. Baseline critical services list.
Index method approved by Design Authority
-
1 - Manual baseline
Q1–Q2
Debt workshops for pilot services; register populated; first index calculated.
Baseline index set to 100
Directional - trends only, no targets
2 - Standardise at source
Q2–Q4
Debt capture embedded in design review, problem RCA and dispensation expiry (CI-11).
≥70% of critical services assessed
Indicative - thresholds drafted
3 - Federate & automate
Year 2 H1
Automated index from register; orphan report monthly. Negotiate the PLA target.
≥90% coverage; no orphaned items
PLA-grade - target negotiated; ambers actioned
4 - Institutionalise
Ongoing
Debt remediation tranches funded through investment cycle using index trend.
Index trending down for two consecutive quarters
Sustained
4. Readiness ladder - Service owners
Level
Criteria
Target date
L0
Debt untracked
-
L1
Debt register exists for service
Pilot by end of Stage 1
L2
Items owned, scored and dated
All Tier-1 by end of Stage 2
L3
Remediation linked to roadmap or backlog
During Stage 3
L4
Index calculated automatically
With Stage 3 tooling
5. Quality and anti-gaming controls
Risk
Effect
Control
Under-reporting
Teams hide debt to protect the index
Reward disclosure; index trend judged on remediation, not count
Re-scoring down
Severity lowered to improve index
Severity changes need EA approval
Closing without fixing
Items closed as 'accepted'
Accepted items stay in index unless retired with the service
Baseline drift
New services change the index base
Rebase annually with transparent restatement
6. Asks of Service owners
#
Ask
1
Record debt in the register with owner and severity
2
Review debt at each service review
3
Link remediation to funded work
4
Re-authorise items older than 12 months
5
Nominate a debt register counterpart
ODM-12 · Implementation roadmap
Rationalisation delivery
KPI · % · Green ≥80, Amber ≥65 (illustrative pending PLA negotiation) · Owner: Operational Architecture lead · Consumer: CFO / CIO · Cadence: Quarterly, reported with coverage · Family: F4 Estate Health, Technical Debt & Lifecycle. Organising principle: Rationalisation is only real when the old thing is switched off and the cost stops.
Percentage of planned rationalisation actions (TIME Migrate/Eliminate retirements and consolidations) completed within one quarter of plan, with run-cost savings evidenced.
Why it matters
Portfolio rationalisation is the most common architecture business case - and the most commonly unrealised. This metric holds it to delivered savings.
Numerator
Rationalisation actions completed within one quarter of plan with run-cost savings evidenced
Denominator
Rationalisation actions due in the period
What counts
Completion means service retired, licences and contracts exited and infrastructure removed - not 'migrated but still running'
Reporting rule
Always publish two numbers: the ODM value AND coverage (% of applications with a TIME disposition recorded). Coverage is the honesty device and the improvement lever.
2. The data contract (per rationalisation action)
#
Field
Notes
1
Action ID
From portfolio register
2
Application / service ID
From CMDB
3
TIME disposition
Tolerate / Invest / Migrate / Eliminate
4
Planned completion date
Under change control
5
Actual completion date
Evidence of switch-off
6
Savings realised (£ p.a.)
Validated by finance
3. Staged roadmap
Stage
Timeframe
Activity
Exit criteria
Confidence label
0 - Define
4–6 weeks
Agree TIME criteria and savings validation method with finance.
Method signed by finance
-
1 - Manual baseline
Q1–Q2
Portfolio assessment for pilot domain; actions and savings tracked manually.
Two quarterly cuts published
Directional - trends only, no targets
2 - Standardise at source
Q2–Q4
TIME dispositions for all Tier-1 applications; actions in portfolio register linked to CMDB.
≥70% dispositions recorded
Indicative - thresholds drafted
3 - Federate & automate
Year 2 H1
Automated tracking with decommissioning evidence (CI-17) and finance data. Negotiate the PLA target.
≥90% coverage; savings validated
PLA-grade - target negotiated; ambers actioned
4 - Institutionalise
Ongoing
Savings recycled into investment planning; portfolio reviewed annually.
Savings reported in annual accounts narrative
Sustained
4. Readiness ladder - Domains
Level
Criteria
Target date
L0
No portfolio assessment
-
L1
TIME dispositions recorded
Pilot by end of Stage 1
L2
Actions planned with dates and owners
All Tier-1 by end of Stage 2
L3
Decommissioning evidence and savings validated
During Stage 3
L4
Automated tracking
With Stage 3 tooling
5. Quality and anti-gaming controls
Risk
Effect
Control
Zombie systems
Migrated but never switched off
Completion needs decommissioning evidence
Savings double-count
Same saving claimed twice
Finance validation and savings register
Cost shift
Savings moved to another budget line
Report net run-cost at service level (CI-14)
Plan softening
Targets set to guarantee success
EA reviews plan realism; report against original plan
6. Asks of Domains
#
Ask
1
Agree TIME dispositions for owned applications
2
Commit to switch-off dates
3
Provide decommissioning evidence
4
Finance partner validates savings
5
Nominate a domain data counterpart
ODM-13 · Implementation roadmap
Operational acceptance first-time pass
KCI · % · Green ≥85, Amber ≥70 (illustrative pending PLA negotiation) · Owner: Operational Architecture lead · Consumer: Head of IT Operations / Service Owners · Cadence: Quarterly, reported with coverage · Family: F5 Operability, Resilience & Service Transition. Organising principle: If operations has to waive it to accept it, it was not ready.
Percentage of Tier-1 releases passing operational acceptance at first submission, without waivers, against the service acceptance criteria.
Why it matters
Measures whether operability is designed in or bolted on. Waivers at acceptance become incidents, toil and support cost in early life.
Numerator
Tier-1 releases accepted at first submission without waivers
Denominator
Tier-1 releases submitted for operational acceptance
What counts
Acceptance against the published service acceptance criteria; conditional acceptance with waivers counts as a fail
Reporting rule
Always publish two numbers: the ODM value AND coverage (% of Tier-1 releases passing through formal operational acceptance). Coverage is the honesty device and the improvement lever.
2. The data contract (per release)
#
Field
Notes
1
Release ID
From transition records
2
Service and tier
From service catalogue
3
Submission date
Operational readiness review date
4
Outcome
Accepted / accepted with waiver / rejected
5
Waiver reasons (coded)
Monitoring, runbook, capacity, backup, support model, documentation
6
Early-life incidents (30 days)
From ITSM - feeds CI-10
3. Staged roadmap
Stage
Timeframe
Activity
Exit criteria
Confidence label
0 - Define
4–6 weeks
Publish service acceptance criteria and waiver coding. Pilot with one service line.
Acceptance workflow in ITSM; operability requirements fed into design (OA-02, SA-15).
≥70% of Tier-1 releases via workflow
Indicative - thresholds drafted
3 - Federate & automate
Year 2 H1
Automated reporting with early-life incident correlation. Negotiate the PLA target.
≥90% coverage; waiver reasons trended
PLA-grade - target negotiated; ambers actioned
4 - Institutionalise
Ongoing
Waiver trends feed patterns and delivery onboarding.
Top waiver reasons falling
Sustained
4. Readiness ladder - Delivery and service teams
Level
Criteria
Target date
L0
No formal acceptance
-
L1
Operational readiness review held
Pilot by end of Stage 1
L2
Criteria applied and outcomes coded
All Tier-1 by end of Stage 2
L3
Operability requirements captured at Planning
During Stage 3
L4
Automated acceptance reporting
With Stage 3 tooling
5. Quality and anti-gaming controls
Risk
Effect
Control
Pressure to accept
Go-live deadlines force acceptance
Waivers recorded honestly; escalated not hidden
Criteria dilution
Criteria weakened to pass
Criteria changes approved by Head of IT Operations
Late submission
Readiness review too late to fix gaps
Operability requirements at Planning (CI-02)
Fast-track bypass
Urgent releases skip acceptance
Report fast-track volume alongside
6. Asks of Delivery and service teams
#
Ask
1
Capture operability requirements at Planning
2
Submit for readiness review in time to remediate
3
Code waiver reasons honestly
4
Nominate a service transition counterpart
5
Review early-life incidents at post-implementation review
ODM-14 · Implementation roadmap
Resilience design verification
KCI · % · Green ≥95, Amber ≥85 (illustrative pending PLA negotiation) · Owner: Operational Architecture lead · Consumer: Service Owners / Resilience Board · Cadence: Quarterly, reported with coverage · Family: F5 Operability, Resilience & Service Transition. Organising principle: Recovery that has not been exercised is a hypothesis.
Percentage of critical services whose recovery architecture has been exercised within 12 months and met agreed RTO/RPO.
Why it matters
Confirms that the recovery architecture of critical services works in practice. Maps directly to operational resilience obligations and board risk appetite.
Numerator
Critical services exercised within 12 months that met agreed RTO/RPO
Denominator
All critical services
What counts
A full or component recovery exercise with measured RTO/RPO - tabletop alone does not count
Reporting rule
Always publish two numbers: the ODM value AND coverage (% of critical services with agreed RTO/RPO recorded). Coverage is the honesty device and the improvement lever.
2. The data contract (per exercise)
#
Field
Notes
1
Service ID
From service catalogue
2
Criticality
Resilience Board list
3
Exercise date and type
Full failover / component restore / tabletop
4
RTO/RPO target
Agreed with service owner
5
RTO/RPO achieved
Measured
6
Actions raised
Linked to problem or debt register
3. Staged roadmap
Stage
Timeframe
Activity
Exit criteria
Confidence label
0 - Define
4–6 weeks
Agree critical services list, RTO/RPO and exercise standard.
List approved by Resilience Board
-
1 - Manual baseline
Q1–Q2
Exercise programme scheduled; first exercises recorded manually.
Pilot services exercised
Directional - trends only, no targets
2 - Standardise at source
Q2–Q4
Exercise records held centrally; findings tracked to closure.
≥70% of critical services exercised
Indicative - thresholds drafted
3 - Federate & automate
Year 2 H1
Automated reporting from exercise records. Negotiate the PLA target.
≥95% within 12 months
PLA-grade - target negotiated; ambers actioned
4 - Institutionalise
Ongoing
Exercise outcomes drive recovery architecture changes and patterns.
Repeat failures eliminated
Sustained
4. Readiness ladder - Service owners
Level
Criteria
Target date
L0
No RTO/RPO agreed
-
L1
RTO/RPO agreed
Pilot by end of Stage 1
L2
Tabletop exercises held
All Tier-1 by end of Stage 2
L3
Technical recovery exercised annually
During Stage 3
L4
Automated reporting
With Stage 3 tooling
5. Quality and anti-gaming controls
Risk
Effect
Control
Tabletop substitution
Paper exercises counted
Only measured technical exercises count
Easy scope
Only simple components exercised
Exercise scope approved by OA
Unrealistic targets
RTO/RPO set to guarantee pass
Targets derived from business impact analysis
Findings unclosed
Same failures recur
Actions tracked to closure; repeats reported
6. Asks of Service owners
#
Ask
1
Agree RTO/RPO for critical services
2
Schedule annual recovery exercises
3
Record measured results
4
Close actions from exercises
5
Nominate a resilience counterpart
ODM-15 · Implementation roadmap
Early engagement rate
KPI · % · Green ≥90, Amber ≥75 (illustrative pending PLA negotiation) · Owner: Solutions Architecture lead · Consumer: CIO / Delivery Leadership · Cadence: Quarterly, reported with coverage · Family: F6 Engagement & Capability. Organising principle: Architecture's value is highest before anyone has started building.
Percentage of in-scope (Tier-1) initiatives with architecture engagement completed at Strategy or Planning - before Design gate entry.
Why it matters
The leading indicator for the whole framework. Late engagement predicts rework (ODM-05), escapes (ODM-04) and dispensations (ODM-09).
Numerator
Tier-1 initiatives with architecture engagement completed at Strategy or Planning
Denominator
All in-scope (Tier-1) initiatives entering Design in the period
What counts
Engagement means an architect assigned and architecture vision or options recorded - not an email notification
Reporting rule
Always publish two numbers: the ODM value AND coverage (% of Tier-1 initiatives registered in the engagement log). Coverage is the honesty device and the improvement lever.
2. The data contract (per initiative)
#
Field
Notes
1
Initiative ID
From portfolio intake
2
Tier
Agreed tiering rule
3
Architect assigned date
From engagement log
4
Architecture vision / options recorded date
Repository reference
5
Design gate entry date
From pipeline gates
6
Engagement route
Embedded / consult / self-service
3. Staged roadmap
Stage
Timeframe
Activity
Exit criteria
Confidence label
0 - Define
4–6 weeks
Agree Tier-1 definition and engagement evidence. Stand up engagement log.
Definitions approved
-
1 - Manual baseline
Q1–Q2
Log maintained by SA leads; quarterly calculation.
Two quarterly cuts published
Directional - trends only, no targets
2 - Standardise at source
Q2–Q4
Engagement triggered automatically from portfolio intake.
≥70% of Tier-1 initiatives logged at intake
Indicative - thresholds drafted
3 - Federate & automate
Year 2 H1
Automated calculation from intake and gate data. Negotiate the PLA target.
≥90% coverage
PLA-grade - target negotiated; ambers actioned
4 - Institutionalise
Ongoing
Engagement data informs architecture capacity planning.
Capacity matched to demand
Sustained
4. Readiness ladder - PMOs
Level
Criteria
Target date
L0
Architecture engaged ad hoc
-
L1
Architect assigned before Design gate
Pilot by end of Stage 1
L2
Architecture vision recorded at Planning
All Tier-1 by end of Stage 2
L3
Engagement triggered from intake
During Stage 3
L4
Automated reporting
With Stage 3 tooling
5. Quality and anti-gaming controls
Risk
Effect
Control
Nominal engagement
Architect assigned but not involved
Evidence of vision/options required
Tier gaming
Initiatives classified below Tier-1
Tiering rule audited
Capacity bottleneck
Engagement slow because architects are scarce
Report demand vs capacity; use self-service routes (ODM-16)
Compulsion backlash
Mandated engagement seen as bureaucracy
Pair with ODM-08 turnaround
6. Asks of PMOs
#
Ask
1
Register initiatives at intake
2
Request architecture at Strategy/Planning
3
Record engagement route
4
Nominate a data counterpart
5
Include architecture in project onboarding
ODM-16 · Implementation roadmap
Reuse & capability uplift
KPI · composite trend · Green ≥10, Amber ≥5 (illustrative pending PLA negotiation) · Owner: Enterprise Architecture lead · Consumer: CIO / HR (capability) · Cadence: Annual, reported with coverage · Family: F6 Engagement & Capability. Organising principle: The mark of a mature architecture function is how much good design happens without it.
Composite trend: number of accredited architecture practitioners in delivery teams and percentage of routine designs delivered via self-served patterns without Design Authority escalation.
Why it matters
Scales architecture beyond headcount. Growth in accredited practitioners and self-served patterns frees senior architects for novel, high-risk work.
Numerator
Accredited practitioners in delivery teams; routine designs delivered via self-served patterns without escalation
Denominator
Composite trend (year-on-year change)
What counts
Accreditation against the published architecture skills framework (SFIA 9-aligned); self-served means pattern instantiated and passed gate without Design Authority escalation
Reporting rule
Always publish two numbers: the ODM value AND coverage (% of delivery teams with pattern usage telemetry). Coverage is the honesty device and the improvement lever.
2. The data contract (per practitioner / design)
#
Field
Notes
1
Practitioner ID
From accreditation register
2
Accreditation level
Aligned to SFIA 9 levels
3
Team
Delivery team
4
Design ID
From repository
5
Pattern used
Pattern catalogue ID
6
Escalated to Design Authority (Y/N)
From decision log
3. Staged roadmap
Stage
Timeframe
Activity
Exit criteria
Confidence label
0 - Define
4–6 weeks
Publish accreditation scheme and self-service criteria.
Scheme approved by CIO and HR
-
1 - Manual baseline
Q1–Q2
First accreditation cohort; pattern usage recorded manually.
First annual baseline
Directional - trends only, no targets
2 - Standardise at source
Q2–Q4
Pattern catalogue telemetry enabled; accreditation embedded in career framework.
≥70% of teams with telemetry
Indicative - thresholds drafted
3 - Federate & automate
Year 2 H1
Automated composite calculation. Negotiate the PLA target.
Composite stable
PLA-grade - target negotiated; ambers actioned
4 - Institutionalise
Ongoing
Accreditation part of role profiles; community of practice sustains uplift.