Transition architectures and work packages
A transition architecture is an intentionally designed interim state between the baseline and the target, and are the units of change that advance those transitions coherently rather than simply filling a project schedule. Together they are what this course's working framework turns into practice, drawing on the TOGAF Standard's Phase E and Phase F guidance: what makes a transition architecture real, the complete anatomy of a work package, and the governance discipline that keeps interim states from becoming permanent accidents.
By the end of this module you will be able to:
- Define transition architecture in TOGAF terms and distinguish it from an incomplete target state
- List the five properties that make a transition architecture real and governable
- Explain the full anatomy of a work package, including what belongs inside it and what does not
- Describe the governance responsibilities that apply to transition states and work packages
- Use transition thinking to reduce risk and preserve architecture integrity during change
- Apply transition-state logic and work-package design to the London publication, planning, and resilience case
Single-wave delivery. Half-migrated asset register. Stalled programme.
A approved a target architecture in 2021 that required simultaneous replacement of its asset register, planning tools, and publication pipeline. The programme board treated the target state as the only state that mattered and approved a single-wave delivery plan.
Fourteen months in, the programme was stalled. The asset register was half-migrated, the planning tools were unusable during migration, and the publication pipeline had lost its source data. The problem was not the target. The problem was that nobody had designed the states in between.
A would have made the intermediate steps explicit. Each state would have had its own logic, its own controls, and its own evidence that it was safe to proceed. That discipline was missing, and the enterprise paid for it with fourteen months of drift and nearly double the original budget.
If the enterprise approves a target architecture but nobody designs the states in between, who governs the journey?
That story illustrates what happens when the enterprise treats the target as the only state worth designing. Transition architectures, what makes them real, what belongs inside a work package, and how both concepts connect to governance are what keep interim states honest.
If you are already confident with transition-state design, use the knowledge checks to confirm your understanding and move to Module 46: Migration planning and roadmap logic.
45.1 Why transition architecture matters
Large transformations rarely move from baseline to target in one clean leap. Too many dependencies, too much operational risk, and too much organisational learning stand in the way. Transition architecture exists to make that reality governable rather than leaving it to improvisation.
The concept is straightforward. Between the current state and the desired future state, the enterprise will pass through one or more intermediate states. Each of those states can either be an accident that nobody designed or an intentional position that the enterprise has planned, reviewed, and approved. Transition architecture is the discipline of making that intentional position real.
Without transition architecture, the enterprise faces three specific risks. First, the journey becomes ungoverned: nobody can say whether the current position is safe, productive, or drifting. Second, temporary compromises become permanent because nobody documented them as temporary. Third, delivery teams make their own interim decisions without architecture guidance, creating a patchwork of local fixes that undermines the target state even as the programme claims to be building towards it.
45.2 The five properties of a real transition architecture
Not every intermediate state deserves the name transition architecture. The TOGAF Standard and its supporting guides describe properties that distinguish a genuine transition architecture from a mere project milestone. The following five properties serve as a completeness test.
Property 1: A clear reason to exist
The state removes a specific risk, creates a prerequisite that the next step depends on, or delivers a recognisable business outcome in its own right. If you cannot explain in one sentence why the enterprise should occupy this state, the transition architecture is not yet justified. For example, "Transition State 1 establishes data-authority rules before publication scales up" is a clear reason. "Transition State 1 is the first release" is not.
Property 2: Known compromises
The enterprise understands what is temporary, what remains imperfect, and what must not become permanent by accident. Every transition state involves compromise. The discipline is in making those compromises visible. A transition architecture should list what is deliberately incomplete, what workarounds are in place, and what the risks of those workarounds are. Without this, temporary arrangements drift into permanent fixtures that nobody can explain or remove.
Property 3: Visible controls
Governance, evidence, and review expectations are explicit for the interim state as well as the target. Many programmes apply governance only at the final delivery gate. That means the enterprise can drift through three transition states without any architecture review. Visible controls include which review forums apply, what evidence must be produced, and what authority the has to hold or redirect the programme at each intermediate state.
Property 4: A bounded exit path
The enterprise knows what must be true before it can move beyond the transition state safely. Exit conditions are not milestones or dates. They are testable statements about the architecture. For example: "Data-authority rules are codified and enforced across all publication endpoints" is a testable exit condition. "Q3 milestone achieved" is a calendar marker that says nothing about architectural readiness.
Property 5: Standalone value
The transition state delivers recognisable value even if the programme stops at that point. This property matters for two practical reasons. First, it maintains executive support: if each transition state delivers visible improvement, the programme retains its mandate. Second, it provides a safe fallback: if the enterprise discovers that later states are unachievable, it can stop at a transition state that is coherent rather than half-built.
Common misconception
“A transition architecture is just the target state with some features deferred.”
A transition architecture is an intentionally designed interim state with its own purpose, controls, known compromises, exit conditions, and standalone value. Treating it as 'target minus deferred items' strips out the architectural reasoning that makes the interim state governable. The result is an accidental position that nobody can evaluate, defend, or safely exit.
The specificity ladder from target state to sprint backlog
Every sprint backlog item traces back up through project, work package and transition architecture to the agreed target state, each rung adding delivery specificity, so a target state with no work packages is only intent and a backlog with no target state above it is rudderless.
Four transition states from baseline to target, each unlocked by an evidence gate
London Grid moves from its 2024 baseline to the 2027 target one dated state at a time, and no phase begins until the previous state has passed a named evidence gate, so progress is earned by proof rather than granted by the calendar.
45.3 The anatomy of a work package
A is not the same as a project name or a sprint label. It is an architecturally meaningful unit of change that advances the enterprise from one state to the next. The test is whether the work package can explain what architectural property it changes, what it depends on, and what depends on it. If it cannot answer those three questions, it is a delivery label rather than an architecture concept.
The TOGAF Standard describes work packages as the bridge between architecture outputs and delivery planning. The following elements constitute this course's working framework for the full anatomy of a work package, built on that grounding.
Architectural scope
Which does this work package create, modify, replace, or retire? The scope should be described in architecture terms, not just in delivery terms. "Replace the customer portal" is a delivery description. "Retire ABB-14 and deploy SBB-22 to provide the connection-application intake capability" is an architectural scope statement.
Dependencies
What must be true before this work package can start? What must this work package deliver before other packages can proceed? Dependencies can be technical (Platform X must be in place), informational (data-authority rules must be codified), organisational (the governance board must have approved the exception), or temporal (regulatory deadline constrains the delivery window).
Transition-state assignment
Which transition architecture does this work package support? A work package that is not assigned to a specific transition state cannot be sequenced reliably because its contribution to the overall journey is undefined. The assignment also makes it clear whether the work package must be complete before the transition state is reached or whether it can be in progress during the transition.
Business value statement
What business outcome does this work package enable or improve? The value statement connects the architecture change to the enterprise purpose that justifies the investment. Work packages without business value statements tend to lose executive support and become vulnerable to descoping when budgets tighten.
Risk and constraint register
What are the known risks to this work package, and what constraints must be respected during its delivery? This element connects the work package to the enterprise risk management framework and ensures that architectural risks are visible to delivery governance.
Compliance and standards requirements
Which , standards, and regulatory obligations apply to this work package? If the work package requires an exception to a principle, that exception should be documented here and escalated to the Architecture Board for a decision.
Work package dependency ladder from foundation to filed evidence
Five work packages run in a fixed dependency order: each depends on the rung above and unblocks the rung below, so platform and data work land before any business change and skipping a rung leaves the next package incomplete, with filed evidence proving the transition at the end.
45.4 What work packages are not
Teams often confuse work packages with delivery constructs that serve a different purpose. Each confusion weakens the architecture's ability to guide delivery.
A work package is not a sprint. A sprint is a time-boxed delivery cycle. A work package is a scope-bounded architecture change. A single work package may span many sprints, or a single sprint may contribute to multiple work packages.
A work package is not a project. A project is a management construct with a budget, a team, and a timeline. A work package is an architecture construct with a scope, dependencies, and a transition-state assignment. Projects and work packages often align, but they are not the same thing.
A work package is not a release. A release is a deployment event. A work package is a change scope. A release may deliver part of a work package, all of a work package, or parts of several work packages simultaneously.
A work package is not a budget line. Budget allocation follows its own logic. Work packages follow architecture logic. Conflating them means the architecture gets reshaped by financial reporting boundaries rather than by dependency and coherence.
Common misconception
“Work packages and projects are the same thing with different labels.”
A work package is an architecture construct that describes what changes, what depends on what, and which transition state the change supports. A project is a management construct with a budget, team, and timeline. They often align but they answer different questions and are governed by different authorities.
45.5 Governance of transition states and work packages
The TOGAF Standard connects transition architecture and work packages to the enterprise governance framework. The key principle is that governance does not apply only to the final state. Every transition state should be subject to architecture review, and every work package should be traceable to a governed transition.
Architecture Board review at each transition. Before the enterprise formally enters a new transition state, the should confirm that the exit conditions of the previous state have been met and that the new state is safe to occupy. This prevents the programme from advancing through states that are incomplete without a conscious decision to accept the risk.
Compliance review of work packages. Each work package should be reviewed for compliance with architecture principles and standards before delivery begins. This is not a bureaucratic gate. It is the mechanism that prevents delivery teams from building solutions that undermine the target architecture while claiming to advance it.
Exception management. When a work package must deviate from a principle or standard, the exception should be documented, time-bounded, and approved by the Architecture Board. Undocumented exceptions are the primary way that temporary compromises become permanent technical debt.
Repository updates. The should reflect each transition state as it is reached, not just the baseline and target. This keeps the repository truthful and prevents the enterprise from losing track of its current architectural position.
45.6 London Grid Distribution: transition states and work packages
In London, publication discipline, case management, standards control, and resilience assurance cannot all mature at once. That makes transition architecture essential rather than optional. The London transformation requires at least three transition states before the target architecture is reached.
London Transition State 1: Evidence foundation
Reason to exist: Establish the case-management spine and evidence model before publication scales up. Without this state, publication improvements would amplify inconsistent case evidence.
Known compromises: Legacy publication endpoints still active. Manual evidence verification in place. Not all metadata standards codified.
Exit conditions: Case-management platform operational for new connection applications. Evidence model validated against regulatory requirements. Evidence-quality rules stable enough for the authority and publication work that follows to consume.
London Transition State 2: Publication and modelling discipline
Reason to exist: Stabilise the information foundation, settled data authority, governed publication, and a consistent model and standards pipeline, before cross-layer assurance work scales up.
Known compromises: Cross-layer assurance not yet unified. Foundational assurance controls in place but OT, IT, and telecom views still separate.
Exit conditions: Publication quality meets the transparency standard for Ofgem reporting. Authority controls enforced across all active publication channels. Model pipeline operational and the standards board integrated into publication governance. Legacy endpoints decommissioned or under governed exception.
London Transition State 3: Cross-layer assurance integration
Reason to exist: Bring OT, IT, telecom, and cyber assurance into a single governed operating state before the target architecture is declared complete.
Known compromises: Some legacy planning tools retained under exception. Cyber assurance tooling integrated but not yet fully automated.
Exit conditions: OT, IT, telecom, and cyber assurance operating from a single cross-layer view. Assurance findings reaching the Architecture Board through one governed route.
London work-package examples
- WP1: Case spine and evidence model. Scope: deploy the connection-application case platform with governed evidence-quality rules. Dependency: none (first in sequence). Transition: supports State 1. Value: traceable connection cases and the evidence foundation the later packages depend on.
- WP2: Authority and publication controls. Scope: codify data-authority rules for the highest-volume publication types and migrate active publication endpoints to the governed pipeline. Dependency: WP1 (the evidence model must be stable before publication controls consume it). Transition: supports State 2.
- WP3: Model and standards pipeline. Scope: establish governed network modelling, metadata standards, and planning reuse. Dependency: WP2 (authority rules must be settled before models are published as authoritative). Transition: supports State 2.
- WP4: Cross-layer assurance hardening. Scope: unify OT, IT, telecom, and cyber assurance into a single operating view. Dependency: WP2 and WP3 (the publication and modelling foundation must be stable). Transition: supports State 3.
A programme manager describes a transition architecture as 'the target state but with some features deferred to Phase 2.' What is wrong with this description?
A work package is defined as 'Data Team Sprint 7-12.' What is the most likely problem?
An enterprise has three transition states planned. Transition State 2 has no documented exit criteria. What risk does this create?
A work package lists its architectural scope but has no dependencies recorded. The programme plans to run it in parallel with three other packages. What should an architecture reviewer ask?
Core distinctions
- A transition architecture is an intentional interim state with five properties: reason to exist, known compromises, visible controls, bounded exit path, and standalone value.
- A work package is an architecture construct, not a project label or sprint boundary. It describes scope, dependencies, transition-state assignment, value, and compliance.
- Governance applies at every transition state, not just at final delivery. The Architecture Board should review exit conditions before the enterprise advances.
- Temporary compromises must be documented as temporary or they become permanent technical debt.
- The London case requires at least three transition states, each with explicit exit conditions tied to evidence quality, publication and data authority, and assurance integration.
- Work packages should be traceable from architecture scope to transition state to business value.
Standards and sources cited in this module
The TOGAF Standard, 10th Edition (C220)
Phase E, Phase F, and the ADM guidance on transition architecture and work packages
The core standard and primary authority for transition architecture design, work-package definition, and governance of interim states.
G186, Practitioners' Approach to Developing Enterprise Architecture Following the TOGAF ADM
Full guide
Practical guidance on transition planning within the ADM, including worked examples of transition-state design.
G212, Digital Technology Adoption: A Guide to Readiness Assessment and Roadmap Development
Full guide
Readiness-assessment and roadmap techniques that support transition-state design and work-package sequencing.
Connections reform programme, Ofgem
Programme overview
Regulatory context for the London Grid case study transitions.
Module 45 of 72 · Migration and Delivery
Try it in the workspace
One tool reinforces this module.