Configure the method
Set breadth, depth, time horizon, viewpoints, governance and delivery cadence for the problem. Do not run every technique at maximum detail.
Architecture blueprint 03
TOGAF-Aligned EA Roadmap
A practical architecture path from business capability and current-state evidence to governed delivery and continuous improvement.
- Model
- TOGAF Standard, 10th Edition-aligned
- Scope
- Strategy / portfolio / governance / change
- Status
- Illustrative target pattern
Designed outcome
A portfolio that connects investment, transition architecture and delivery sequencing to measurable business capability.
Method position
Configured around the ADM. Focused on decisions.
This practitioner roadmap is aligned to the TOGAF Standard, 10th Edition. Its ten stages are an adapted engagement sequence mapped to ADM touchpoints and deliverables; they do not rename the official ADM phases or prescribe a linear waterfall.
Requirements Management remains continuous, architecture work iterates, and the organisation should tailor artefacts and governance to the decision, risk and delivery context.
- PPreliminary
Practice, principles and governance
- AArchitecture Vision
Scope, stakeholders and value
- BBusiness Architecture
Capabilities, value and operating model
- CInformation Systems
Data and application architectures
- DTechnology Architecture
Platform and technology foundations
- EOpportunities & Solutions
Work packages and transitions
- FMigration Planning
Priority, roadmap and implementation plan
- GImplementation Governance
Conformance and Architecture Contracts
- HChange Management
Monitor, assess and evolve
- RMRequirements Management
Continuous traceability through the cycle
Iterate across phases
Evidence, requirements, options and transition constraints send work back and forward. Parallel delivery can govern one increment while another is being shaped.
Trace every decision
Connect strategy to value streams, capabilities, requirements, building blocks, work packages, controls, benefits and operational measures.
Architect the transition
Treat each intermediate state as an operable architecture with ownership, coexistence, recovery, debt and a funded exit—not a temporary diagram.
Method note: this is an illustrative, practitioner-authored alignment aid. It is not an official Open Group artefact, accredited training material or a claim of TOGAF certification.
Ten practical stages
From business pressure to measurable change.
The stages provide a decision-led route through evidence, architecture definition, migration, governance and improvement. They map to multiple ADM touchpoints and deliberately iterate when new evidence changes the answer.
Interactive stage explorer
Follow the decisions, not a rigid waterfall.
Select a stage to inspect its ADM touchpoints, evidence, work, deliverables, gate, measures and most important trade-off. Arrow keys move between stage tabs.
Stage 01 / 10Discover
Practical stage 01 / Discover
Business capability mapping
Establish why architecture work is needed and create a stable business view that connects strategy, value streams, capabilities, ownership and measurable pressure for change.
ADM touchpoints
- Preliminary
- Phase A
- Phase B
- Requirements Management
Decision question
Which capability and value-stream constraints materially block the outcomes the enterprise is trying to achieve?
Evidence in
What should be true before the work starts
- Strategy, mandates, risk appetite and measurable business outcomes
- Value-stream demand, delay, failure demand, customer friction and unit economics
- Capability ownership, performance, maturity, investment and change pressure
- Stakeholder concerns, organisation maps, process evidence and information needs
Architecture work
What the team needs to do
- Tailor the method, governance, breadth, depth and time horizon for the engagement
- Map value stages to the capabilities and information that enable them
- Heat capabilities using triangulated performance, risk, cost and change evidence
- Name outcome owners and capture initial principles, requirements, assumptions and constraints
Deliverables out
Decision-ready architecture evidence
- Capability map and capability heat assessment
- Value-stream map with pain points, measures and accountable owners
- Stakeholder map, concerns and initial architecture requirements
- Architecture Vision and configured Statement of Architecture Work inputs
Measures
How progress and quality stay visible
- Strategic outcomes mapped to owned capabilities
- Priority capabilities with evidence-backed baselines
- Value-stream lead-time, quality, cost or experience measures agreed
Decision gate
Mandate and scope
Executive sponsor with the Architecture Board or equivalent design authority
- The business problem and intended outcomes are measurable
- Accountable capability and value-stream owners are engaged
- Scope, depth, time horizon, governance and decision rights are explicit
Practical stage 02 / Discover
Current-state assessment
Build an evidence-led baseline across business, data, application, technology, security and integration viewpoints without turning discovery into an endless inventory exercise.
ADM touchpoints
- Phase B
- Phase C
- Phase D
- Requirements Management
Decision question
Which baseline constraints, dependencies and risks are material enough to shape the target and its transition?
Evidence in
What should be true before the work starts
- Application, interface, data, platform and supplier inventories with named owners
- Lifecycle, total-cost, incident, service, security, resilience and recovery evidence
- Data quality, lineage, access and decision-use evidence
- Delivery capacity, operational skills, technical debt and in-flight change
Architecture work
What the team needs to do
- Describe baseline viewpoints at a level proportionate to the decisions in scope
- Validate inventories and dependencies with service, product, data and business owners
- Trace service failure and cost back to capability and value-stream impact
- Record evidence confidence, assumptions, constraints, risks and unresolved questions
Deliverables out
Decision-ready architecture evidence
- Baseline architecture views within the Architecture Definition Document
- Portfolio, interface, data-flow and dependency maps
- Lifecycle, technical-debt, control-gap and operational-risk register
- Evidence-confidence assessment and updated requirements catalogue
Measures
How progress and quality stay visible
- Material services with validated owners and lifecycle status
- Critical interfaces and data flows with traceable dependencies
- Baseline evidence confidence and unresolved high-impact assumptions
Decision gate
Baseline accepted
Business and service owners with domain architects
- Material dependencies and systems of record are understood
- Cost, risk and performance claims have an owner and a source
- Known uncertainty is visible and does not invalidate the next decision
Practical stage 03 / Define
Target-state architecture
Define the future business, information, application and technology structure as a coherent set of outcomes, requirements, boundaries and architecture building blocks.
ADM touchpoints
- Phase A
- Phase B
- Phase C
- Phase D
- Requirements Management
Decision question
Which target option best satisfies the required outcomes and quality attributes within the enterprise constraints?
Evidence in
What should be true before the work starts
- Architecture Vision, principles, requirements and stakeholder concerns
- Capability and value-stream priorities with baseline performance
- Current-state constraints, reusable assets, reference models and standards
- Security, resilience, data, interoperability, cost and regulatory requirements
Architecture work
What the team needs to do
- Develop credible target options before committing to products or delivery structures
- Describe target business, data, application and technology viewpoints consistently
- Define architecture building blocks, service boundaries, ownership and quality attributes
- Evaluate options, trade-offs and fitness against requirements and outcome measures
Deliverables out
Decision-ready architecture evidence
- Target views within the Architecture Definition Document
- Architecture Requirements Specification and traceability
- Architecture principles, option assessment and decision records
- Target service measures, control objectives and building-block definitions
Measures
How progress and quality stay visible
- Priority requirements satisfied or explicitly dispositioned
- Target building blocks with owners and measurable service qualities
- Material decisions supported by evaluated alternatives
Decision gate
Target direction approved
Executive sponsor and Architecture Board with affected domain owners
- The selected option demonstrably addresses priority capabilities and requirements
- Cross-domain boundaries, ownership and quality attributes are coherent
- Material trade-offs, assumptions and residual risks are explicitly accepted
Practical stage 04 / Define
Gap analysis
Compare baseline and target using consistent viewpoints, then turn meaningful differences into traceable change rather than an indiscriminate list of missing features.
ADM touchpoints
- Phase B
- Phase C
- Phase D
- Phase E preparation
Decision question
Which gaps require change, which can be tolerated, and which existing assets should be retained, reused, replaced or retired?
Evidence in
What should be true before the work starts
- Approved baseline and target views using comparable scope and viewpoints
- Requirements, principles, control objectives and target service measures
- Existing initiatives, contracts, lifecycle commitments and portfolio constraints
- Capability and value-stream impact associated with each material difference
Architecture work
What the team needs to do
- Classify change as retain, reuse, improve, build, buy, replace, retire or tolerate
- Trace each material gap to requirements, capabilities, value and risk
- Identify overlap with in-flight work, shared dependencies and orphan initiatives
- Form candidate work packages without prematurely fixing the delivery sequence
Deliverables out
Decision-ready architecture evidence
- Cross-domain gap catalogue with disposition and ownership
- Requirement-to-gap-to-capability traceability
- Impact assessment covering value streams, controls and operating model
- Candidate work packages, retirement candidates and unresolved decisions
Measures
How progress and quality stay visible
- Material gaps traced to requirements and business outcomes
- Duplicate initiatives and avoidable building blocks removed
- Retain, retire and reuse decisions with accountable owners
Decision gate
Gaps dispositioned
Capability owners, domain architects and portfolio representatives
- Every material gap has value, risk, ownership and a proposed disposition
- Duplicate or conflicting initiatives are exposed
- Retirement and reuse receive equal consideration to new build
Practical stage 05 / Mobilise
Roadmap & sequencing
Group candidate work into coherent work packages, transition increments and dependency-aware change horizons that can create value without destabilising the enterprise.
ADM touchpoints
- Phase E
- Phase F preparation
- Requirements Management
Decision question
What is the smallest coherent sequence that releases value, reduces risk and preserves a safe route to the target?
Evidence in
What should be true before the work starts
- Prioritised gaps, candidate building blocks and work packages
- Value, cost, risk, capacity, lifecycle and contractual constraints
- Business, data, application, technology and organisational dependencies
- Change readiness, delivery confidence and critical operational windows
Architecture work
What the team needs to do
- Cluster work packages around outcomes and architecture building blocks
- Define candidate transition architectures and the capabilities each increment releases
- Model dependencies, critical paths, prerequisites, concurrency and retirement points
- Prioritise using transparent value, risk, cost and readiness criteria
Deliverables out
Decision-ready architecture evidence
- Candidate work-package portfolio and dependency network
- Candidate Transition Architectures and implementation increments
- Architecture Roadmap with outcomes, timing, owners and decision points
- Implementation and Migration Strategy inputs and portfolio assumptions
Measures
How progress and quality stay visible
- Work packages with explicit prerequisites and outcome owners
- Roadmap horizons with measurable capability or risk movement
- Critical dependencies with confidence, owner and decision date
Decision gate
Coherent path agreed
Portfolio leadership with the Architecture Board and delivery owners
- Dependencies and operational constraints make the sequence executable
- Each horizon releases value or retires material risk
- Transition states, retirement points and decision options remain visible
Practical stage 06 / Mobilise
Business case
Translate the roadmap into a decision-ready investment case with owned benefits, whole-life costs, delivery capacity, risk and the consequences of doing nothing.
ADM touchpoints
- Phase E
- Phase F
- Organisation investment governance
Decision question
Is this sequence worth funding now, and are the enterprise and its owners capable of realising the claimed benefits?
Evidence in
What should be true before the work starts
- Architecture Roadmap, work packages, dependencies and transition costs
- Capability and value-stream baselines with named benefit owners
- Change, run, supplier, decommissioning and opportunity costs
- Delivery confidence, organisational readiness, risk exposure and option value
Architecture work
What the team needs to do
- Create a benefit map that links investment to capability and value-stream movement
- Model whole-life cost ranges, uncertainty and scenario sensitivity
- Test funding, delivery capacity, readiness, disbenefits and the do-nothing option
- Assign benefit owners, leading indicators, review points and stop or pivot conditions
Deliverables out
Decision-ready architecture evidence
- Organisation-specific business case or investment decision paper
- Benefits-realisation map with baselines, owners and review dates
- Cost, capacity and scenario model with confidence ranges
- Funding increments, readiness assessment and investment conditions
Measures
How progress and quality stay visible
- Benefits with baselines, owners, leading indicators and review dates
- Whole-life cost and risk ranges with stated confidence
- Funded capacity aligned to roadmap dependency and transition needs
Decision gate
Investment authorised
Executive sponsor and investment or portfolio governance body
- Benefits, costs, risks and disbenefits are comparable and evidence-based
- Capacity, funding and accountable benefit owners are credible
- Conditions, review points and stop or pivot decisions are explicit
Practical stage 07 / Govern
Delivery governance
Keep delivery aligned to the approved outcomes and architecture through explicit decision rights, risk-based guardrails, Architecture Contracts and timely conformance decisions.
ADM touchpoints
- Preliminary governance
- Phase G
- Requirements Management
Decision question
What must delivery conform to, who can approve change, and how will exceptions be resolved before they become operational debt?
Evidence in
What should be true before the work starts
- Approved Architecture Definition, Requirements Specification and Roadmap
- Delivery plans, solution decisions, risks, dependencies and quality evidence
- Architecture principles, standards, control objectives and accepted trade-offs
- Governance bodies, decision rights, escalation paths and repository assets
Architecture work
What the team needs to do
- Agree Architecture Contracts or equivalent governance agreements suited to the organisation
- Set proportionate compliance checkpoints around material and irreversible decisions
- Trace requirements and decisions through solution design, delivery and acceptance
- Time-box waivers, resolve deviations and update architecture assets when change is valid
Deliverables out
Decision-ready architecture evidence
- Architecture Contract or equivalent delivery-governance agreement
- Compliance-review plan, tailored criteria and assessment records
- Architecture decision, exception, waiver and risk logs
- Solution views, requirement traceability and repository updates
Measures
How progress and quality stay visible
- Architecture decision turnaround at delivery pace
- Material exceptions with owner, expiry and treatment
- Compliance findings resolved before release commitment
Decision gate
Delivery conformant or consciously excepted
Architecture Board or design authority with the delivery sponsor
- Material solution decisions satisfy requirements and principles
- Exceptions have impact, owner, expiry and remediation or acceptance
- Architecture decisions arrive early enough to influence delivery
Practical stage 08 / Govern
Transition architecture
Design each material intermediate state as an operable architecture with explicit coexistence, migration, recovery and exit conditions—not as an accidental half-built target.
ADM touchpoints
- Phase E
- Phase F
- Phase G refinement
Decision question
Can the enterprise operate safely at every intermediate state, and is there a credible, funded exit from temporary complexity?
Evidence in
What should be true before the work starts
- Candidate Transition Architectures, work packages and release plans
- Legacy dependencies, data migration, integration and identity coexistence
- Cutover windows, rollback needs, recovery objectives and service constraints
- Supplier commitments, decommission prerequisites and operational capacity
Architecture work
What the team needs to do
- Refine business, data, application and technology views for each transition state
- Design coexistence, migration, cutover, rollback and recovery patterns
- Link work packages and releases to entry, acceptance and exit criteria
- Fund decommissioning and make residual transition debt visible
Deliverables out
Decision-ready architecture evidence
- Approved Transition Architecture descriptions
- Migration, coexistence, cutover, rollback and recovery views
- Work-package and release dependency map with entry and exit criteria
- Updated Architecture Roadmap and Implementation and Migration Plan
Measures
How progress and quality stay visible
- Transition dependencies ready before cutover commitment
- Rollback, recovery and migration evidence completed
- Temporary components with funded and dated exit plans
Decision gate
Transition safe to execute
Delivery, security, operations and architecture authorities together
- Intermediate services meet agreed control and service thresholds
- Migration, rollback, recovery and decommission paths are testable
- Residual debt has an owner, cost, expiry and funded exit
Practical stage 09 / Evolve
Operational readiness
Prove the implemented service can be owned, secured, supported, observed, recovered and adopted after the project team steps away.
ADM touchpoints
- Phase G
- Requirements Management
- Service acceptance governance
Decision question
Is the service genuinely ready to operate at the required quality, risk and support level—not merely ready to deploy?
Evidence in
What should be true before the work starts
- Conformance findings, implemented requirements and open exceptions
- Service levels, telemetry, capacity, security, backup and recovery tests
- Runbooks, support model, ownership, supplier and escalation arrangements
- Training, adoption, data migration, cutover and business-continuity evidence
Architecture work
What the team needs to do
- Validate functional and quality requirements through operational evidence
- Exercise monitoring, support, incident, recovery, continuity and security processes
- Confirm service, data, control and benefit ownership after transition
- Close, accept or time-box residual risks and establish outcome measurement
Deliverables out
Decision-ready architecture evidence
- Operational-readiness assessment and service acceptance decision
- Service model, ownership matrix, runbooks and escalation paths
- Recovery, continuity, security and performance evidence
- Final conformance report, accepted exceptions and benefits-measurement baseline
Measures
How progress and quality stay visible
- Service and recovery objectives evidenced before acceptance
- Critical support roles, runbooks and monitoring coverage ready
- Users trained and adoption measures established
Decision gate
Ready to operate
Accountable service owner with operations, security and business ownership
- Service qualities and recovery objectives are evidenced
- Ownership, support, funding and escalation are active
- Residual risk and transition debt are explicitly accepted and tracked
Practical stage 10 / Evolve
Continuous improvement
Measure whether capability and value-stream outcomes were realised, govern emerging change and keep architecture, requirements and the roadmap useful as the enterprise evolves.
ADM touchpoints
- Phase H
- Requirements Management
- New ADM cycles
Decision question
Do results and environmental change justify sustaining the course, adapting an increment or initiating a new architecture cycle?
Evidence in
What should be true before the work starts
- Benefit, capability and value-stream performance against agreed baselines
- Operational telemetry, cost, incidents, adoption and customer feedback
- Technology, supplier, regulatory, security and strategic change signals
- Exceptions, transition debt, architecture decisions and repository freshness
Architecture work
What the team needs to do
- Review benefits, quality attributes and operational outcomes with accountable owners
- Assess change materiality and route it through continuous improvement or a new ADM cycle
- Update requirements, baseline, target, roadmap and repository assets
- Retire obsolete assets and use delivery evidence to improve principles and governance
Deliverables out
Decision-ready architecture evidence
- Benefits and architecture-outcome review
- Architecture change requests and materiality decisions
- Updated requirements, architecture descriptions, roadmap and repository
- New or refreshed Statement of Architecture Work where material change warrants it
Measures
How progress and quality stay visible
- Benefits and capability outcomes realised against baseline
- Material change assessed within an agreed decision window
- Transition debt retired and architecture assets kept current
Decision gate
Sustain, adapt or re-enter
Executive sponsor, Architecture Board and capability or service owners
- Outcome evidence is reviewed against the original motivation
- Material changes trigger proportionate architecture work
- Roadmap, requirements and repository reflect the current decision state
Six architecture lenses
One roadmap. Six connected decision views.
Use the tabs to inspect how business, application, data, technology, security and integration concerns cross the practical stages. Arrow keys move between tabs.
View 01 / 6
Business architecture
Capabilities, value streams, ownership and measurable outcomes.
Decision question
Where will change create measurable value, and who owns the outcome?
Evidence in
- Strategy, operating model and customer journeys
- Capability heat, ownership and performance measures
- Value streams, pain points and regulatory obligations
Architecture out
- Capability map and investment priorities
- Outcome measures and accountable owners
- Value-stream implications for the change portfolio
Roadmap touchpoints
Phase 01Phase 04Phase 05Phase 06Phase 10
View 02 / 6
Application architecture
Service boundaries, portfolio rationalisation and lifecycle choices.
Decision question
Which application capabilities should be retained, replaced, retired or reused?
Evidence in
- Portfolio inventory, lifecycle and total cost
- Capability overlap, dependencies and support risk
- User experience, service performance and change demand
Architecture out
- Target application landscape and service boundaries
- Rationalisation decisions with transition states
- Lifecycle standards and delivery guardrails
Roadmap touchpoints
Phase 02Phase 03Phase 04Phase 05Phase 08
View 03 / 6
Data architecture
Ownership, movement, quality, lineage and trusted decision models.
Decision question
Which data products are trusted, who owns them, and how should they move?
Evidence in
- Critical entities, sources and decision use cases
- Quality, lineage, retention and classification evidence
- Movement patterns, latency and access requirements
Architecture out
- Owned data domains and authoritative sources
- Movement, quality and governance patterns
- Curated models and measurable trust thresholds
Roadmap touchpoints
Phase 02Phase 03Phase 04Phase 07Phase 09Phase 10
View 04 / 6
Technology architecture
Cloud foundations, infrastructure, endpoints, resilience and observability.
Decision question
What platform foundation can carry the target services safely and economically?
Evidence in
- Cloud, network, endpoint and infrastructure baselines
- Capacity, resilience, observability and support constraints
- Platform cost, vendor lifecycle and engineering capability
Architecture out
- Reference platforms and deployment patterns
- Resilience, observability and environment standards
- Platform roadmap with cost and lifecycle implications
Roadmap touchpoints
Phase 02Phase 03Phase 04Phase 05Phase 08Phase 09
View 05 / 6
Security architecture
Identity, control objectives, risk treatment, recovery and evidence.
Decision question
Which risks must the architecture prevent, detect, withstand and evidence?
Evidence in
- Threats, obligations, data classification and risk appetite
- Identity, control coverage and recovery evidence
- Supplier, operational and transition-state exposure
Architecture out
- Control objectives mapped to architecture boundaries
- Identity, recovery and evidence requirements
- Risk treatment decisions with named ownership
Roadmap touchpoints
Phase 01Phase 02Phase 03Phase 04Phase 07Phase 08Phase 09
View 06 / 6
Integration architecture
APIs, events, workflow orchestration and decoupled capability reuse.
Decision question
How can capabilities exchange information without creating brittle dependencies?
Evidence in
- Interface inventory, volumes and failure characteristics
- Business events, workflows and ownership boundaries
- Contract, latency, retry and observability requirements
Architecture out
- API, event and workflow interaction patterns
- Versioned contracts and service ownership
- Migration sequencing for point-to-point dependencies
Roadmap touchpoints
Phase 02Phase 03Phase 04Phase 05Phase 07Phase 08
Deliverable spine
Architecture evidence that earns the next decision.
Deliverables are managed bodies of evidence, not a mandate for maximum documentation. Their exact names and boundaries should be configured for the organisation, scope and risk.
PACK-01Stages 01–02
Mandate & evidence
Enough shared truth to bound the architecture work and make the current state decision-useful.
- Architecture Vision and Statement of Architecture Work
- Stakeholder concerns and Architecture Requirements register
- Capability and value-stream maps with owners and measures
- Baseline views, inventories, dependencies, risks and evidence confidence
PACK-02Stages 03–04
Architecture definition
A coherent baseline-to-target argument with explicit options, requirements and material gaps.
- Architecture Definition Document across relevant domains
- Architecture Requirements Specification and traceability
- Principles, options, trade-offs and architecture decision records
- Gap catalogue, dispositions, impacts and candidate work packages
PACK-03Stages 05–06 / 08
Portfolio & transition
An investable path from candidate change to sequenced increments and safe intermediate states.
- Work-package portfolio and dependency network
- Transition Architectures and Architecture Roadmap
- Implementation and Migration Strategy and Plan
- Benefits map, readiness evidence and organisation-specific business case
PACK-04Stages 07 / 09–10
Govern & learn
The controls and feedback needed to protect intent through implementation and operation.
- Architecture Contract or equivalent governance agreement
- Compliance assessments, decisions, exceptions and waivers
- Operational-readiness, recovery, acceptance and ownership evidence
- Outcome reviews, change requests and refreshed repository assets
Decision gates
A gate is a decision, not a presentation meeting.
Each horizon ends with accountable owners deciding whether the evidence is sufficient to proceed, whether conditions are needed, or which earlier work must be revisited.
- GATE-01
Mandate & baseline
Sponsor + capability owners + Architecture Board
Are the outcome, scope, ownership and current-state evidence strong enough to direct architecture work?
Feedback route: Weak measures return to capability mapping; material unknowns return to discovery.
- GATE-02
Target & gaps
Sponsor + domain owners + Architecture Board
Does the selected target address requirements, and are its options, gaps and residual risks understood?
Feedback route: Unsupported options return to target design; incomparable views return to baseline work.
- GATE-03
Portfolio & investment
Investment or portfolio board + benefit owners
Is the roadmap valuable, affordable, dependency-aware and realistic about readiness and capacity?
Feedback route: Unowned value returns to the business case; unsafe sequence returns to roadmap design.
- GATE-04
Governed transition
Delivery sponsor + design authority + security and operations
Do solution and transition decisions conform, or carry consciously accepted, time-bounded exceptions?
Feedback route: Material deviation returns to architecture; unsafe coexistence returns to transition design.
- GATE-05
Operate & evolve
Service and capability owners + sponsor + Architecture Board
Can the service operate safely, and do measured outcomes support sustain, adapt or a new ADM cycle?
Feedback route: Readiness gaps block acceptance; material change initiates proportionate architecture work.
Risks & trade-offs
Good architecture makes tension discussable.
These are not defects to eliminate. They are recurring choices to expose, evidence and govern at the right level.
Breadth vs depth
Enterprise coverage can crowd out the detail needed for the next material decision.
Architecture response: Fix the breadth, depth and time horizon explicitly; deepen only where value, risk or dependency needs it.
Option value vs commitment
Too many options delay action; premature product selection locks the enterprise into weak assumptions.
Architecture response: Decide irreversible boundaries and quality attributes early, while deferring reversible product detail.
Early value vs transition debt
A fast increment may introduce duplicate data, bridge integrations and extended coexistence.
Architecture response: Price temporary complexity, give it an owner and expiry, and fund the retirement path with the release.
Control vs team autonomy
Central review can become a bottleneck; unbounded autonomy can fragment shared capabilities.
Architecture response: Govern high-impact and irreversible decisions, publish guardrails and delegate within explicit tolerances.
Precision vs honesty
False confidence in costs, benefits or dates can hide uncertainty from investment decisions.
Architecture response: Use ranges, confidence and sensitivity; make assumptions and stop or pivot conditions part of approval.
Contract vs collaboration
An Architecture Contract can be mistaken for a static legal document or used as a punitive checklist.
Architecture response: Configure it as a living governance agreement covering outcomes, conformance, measures, decisions and accountability.
Measures & continuous improvement
Measure the enterprise movement, not the volume of architecture.
Architecture succeeds when capability, value, risk and service outcomes move—not when repositories accumulate diagrams. Phase H and continuous Requirements Management keep that evidence connected to change.
Business & capability
- Value-stream lead time, quality, cost and customer outcome
- Capability performance, maturity or risk movement
- Benefits realised against owned baselines
Portfolio & transition
- Dependency confidence and work-package outcome delivery
- Legacy retirement and transition-debt burn-down
- Whole-life spend against value and risk released
Delivery & conformance
- Decision turnaround and compliance findings resolved early
- Exceptions by materiality, age, owner and expiry
- Requirements and quality attributes evidenced at acceptance
Operation & architecture
- Service, recovery, security, adoption and cost-to-serve outcomes
- Architecture change assessed within agreed lead time
- Roadmap, requirements and repository freshness
- 01
Observe
Collect business, service, risk, cost and adoption evidence.
- 02
Compare
Test outcomes against requirements, benefits and target measures.
- 03
Classify
Assess whether change is local, roadmap-level or architecturally material.
- 04
Decide
Sustain, improve, accept, retire or start proportionate ADM work.
- 05
Refresh
Update requirements, architectures, roadmap, governance and repository.
Architecture principles
The rules that survive product change.
Technology choices can evolve. These decision rules keep the architecture coherent as delivery moves from target state to transition and operation.
Start with capability and value, not products
Make the current state evidence-led
Design transition states as deliberately as the destination
Keep architecture close to delivery decisions