Transition architectures and work packages
This is the second of 8 Migration and Delivery modules. It explains why the enterprise needs intentionally designed interim states and how work packages should advance those transitions coherently rather than simply filling a project schedule. The module covers the C220 Part 2 and Part 3 definitions in full, including 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. No knowledge beyond Module 44 is assumed.
By the end of this module you will be able to:
- Define transition architecture using the exact TOGAF definition 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 from C220 Part 2 and Part 3, 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
Real-world case · 2021
Single-wave delivery. Half-migrated asset register. Stalled programme.
A distribution network operator 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 transition architecture 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. This module explains what transition architectures are, what makes them real, what belongs inside a work package, and how both concepts connect to the governance discipline that keeps 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 the second option 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.
“Transition architectures describe the enterprise at architecturally significant states between the baseline and the target.”
The TOGAF Standard, 10th Edition - C220 Part 1, Phase E and Phase F
The key phrase is architecturally significant. A transition state is not an accidental halfway point. It is not a sprint boundary or a release date. It has its own purpose, its own controls, and its own exit conditions. An enterprise that merely breaks delivery into phases without designing each phase as a coherent architectural state has missed the point.
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 Architecture Board 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.
45.3 The anatomy of a work package
A work package 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.
C220 Part 2 and Part 3 describe work packages as the bridge between architecture outputs and delivery planning. The following elements constitute the full anatomy of a work package as the standard describes it.
Architectural scope
Which building blocks 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 architecture principles, 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.
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
C220 Part 3 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 Architecture Board 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 Architecture Repository 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 data-authority rules and case-management spine before publication scales up. Without this state, publication improvements would amplify inconsistent data.
Known compromises: Legacy publication endpoints still active. Manual evidence verification in place. Not all metadata standards codified.
Exit conditions: Data-authority rules codified and enforced for the top ten publication types. Case-management platform operational for new connection applications. Evidence model validated against regulatory requirements.
London Transition State 2: Publication and authority control
Reason to exist: Stabilise the information foundation before larger model-led and standards improvements scale up.
Known compromises: Model pipeline not yet integrated. Planning reuse still manual. Cross-layer assurance not yet unified.
Exit conditions: Publication quality meets the transparency standard for Ofgem reporting. Authority controls enforced across all active publication channels. Legacy endpoints decommissioned or under governed exception.
London Transition State 3: Model pipeline and assurance integration
Reason to exist: Bring planning reuse, standards governance, and cross-layer assurance into a 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: Model pipeline operational. Standards board integrated into publication governance. OT, IT, and telecom assurance operating from a single cross-layer view.
London work-package examples
- WP-1: Data-authority codification. Scope: define and enforce authority rules for the ten highest-volume publication types. Dependency: none (first in sequence). Transition: supports State 1. Value: prevents publication of inconsistent data.
- WP-2: Case-management spine. Scope: deploy the connection-application case platform with evidence-model integration. Dependency: WP-1 (authority rules must be codified before the case platform enforces them). Transition: supports State 1.
- WP-3: Publication-channel migration. Scope: migrate all active publication endpoints to the governed pipeline. Dependency: WP-1 and WP-2 (authority and evidence must be stable). Transition: supports State 2.
- WP-4: Cross-layer assurance integration. Scope: unify OT, IT, telecom, and cyber assurance into a single operating view. Dependency: WP-3 (publication 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?
Key takeaways
- 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 data authority, publication quality, 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)
Parts 1, 2, and 3: Phase E, Phase F, transition architecture, and work-package guidance
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, Architecture-Led Incremental Planning
Full guide
Incremental planning 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.
You now understand transition architectures as intentionally designed interim states with five testable properties and work packages as architecture-guided units of change with full anatomical detail. The next question is how the enterprise sequences those packages into a defensible roadmap. That is Module 46.
Module 45 of 64 · Migration and Delivery