Section 1: Phase E Overview
Phase E — Opportunities & Solutions is the first ADM phase that shifts focus from describing architectures to planning how to achieve them. The four preceding phases (A–D) produced Baseline and Target architectures across all domains; Phase E synthesises that work into an initial, actionable Architecture Roadmap. It bridges the gap between architecture design and delivery.
The ADM phase that generates the initial complete version of the Architecture Roadmap. It identifies work packages, transition architectures, and implementation vehicles (projects or programmes) that together realise the Target Architecture. Phase E is the first phase primarily concerned with implementation.
| Inputs | Key Outputs |
|---|---|
| Architecture Vision (Phase A) | Architecture Roadmap (initial) |
| Business, Data, Application, Technology architectures (Phases B–D) | Transition Architecture list (T1, T2 …) |
| Gap analyses from all domains (B, C, D) | Implementation Factor Assessment |
| Technology forecasts & capability assessments | Work Package list with dependencies |
| Architecture Principles; constraints; drivers | Draft Implementation & Migration Plan |
Part 1 regularly tests the E/F distinction. Phase E generates the initial roadmap (draft, concept-level); Phase F finalises and prioritises it with detailed schedules and resource costs. Key outputs of Phase E are Work Packages and Transition Architectures; key output of Phase F is the finalised Implementation & Migration Plan. Never say Phase F "creates" the roadmap — it refines what Phase E created.
Section 2: Key Activities in Phase E
The four primary activities of Phase E map directly to its outputs and are commonly tested in Part 1:
- Consolidate gap analyses: Bring together the individual gap analyses from Phases B (Business), C (Information Systems), and D (Technology) into a single, unified view of what must change across the enterprise.
- Assess and select opportunities: For each gap, identify candidate solutions — build, buy, reuse from the Enterprise Continuum, or partner. Evaluate alignment with principles, strategic fit, and feasibility.
- Identify candidate Transition Architectures: Where the gap is too large to close in one step, define one or more intermediate stable states (T1, T2 …) that can each be delivered and operated independently.
- Create the Architecture Roadmap: Sequence the identified work packages and transition architectures on a timeline, capturing high-level dependencies and resource requirements.
Section 3: Work Packages
A discrete, manageable package of work that closes one or more architecture gaps. A Work Package is smaller than a Project (which may contain many packages) and smaller than a Transition Architecture (which is an enterprise state, not a delivery unit). Multiple work packages together may constitute a Transition Architecture.
| Attribute | Description | Exam Relevance |
|---|---|---|
| Deliverables | Architecture artefacts, components, or services produced by the package | Distinguishes the package from its container project |
| Dependencies | Other packages that must complete before or alongside this one | Critical for roadmap sequencing — "dependencies-first" prioritization |
| Resources | People, budget, and technology needed (high-level at Phase E stage) | Resource allocation detailed in Phase F, not Phase E |
| Risks | Threats to successful delivery captured in the Implementation Factor Assessment | Feeds directly into the risk register and prioritization decisions |
The relationship between the three concepts — Work Package → Project → Transition Architecture — is hierarchical in scope but not in governance. Work packages are the building blocks; projects are the delivery vehicles; transition architectures are the enterprise states that result from a set of delivered projects.
Section 4: Transition Architectures
A Transition Architecture represents a stable, deployable, and operable intermediate state of the enterprise — between the Baseline and Target. Each transition architecture must be viable on its own: the enterprise can run in this state indefinitely if needed. It is not a halfway-done Target; it is a fully coherent, governed enterprise state.
The selection criteria for defining transition architectures include: the natural boundaries of programme delivery cycles, contractual or regulatory milestones, technical dependencies (e.g., a platform must be in place before applications can migrate), risk tolerance, and the organisation's funding cycles. Phase E identifies candidate transitions; Phase F validates and finalises them.
Part 2 scenario questions routinely describe a large enterprise transformation and ask "what should the architect define?" The best answer nearly always involves defining Transition Architectures — not just a single roadmap or a big-bang cutover. Watch for scenario cues: "too large to deliver at once", "incremental rollout", "phased approach", or "programme of work". Each transition architecture must be stable, deliverable, and operable in its own right — this distinguishes it from a simple milestone or phase gate.
Section 5: Architecture Roadmap
The Architecture Roadmap is the primary output of Phase E. It is a time-sequenced view of the work packages and transition architectures required to move from the Baseline to the Target Architecture. It is a living document — first created in Phase E at a high level, refined and detailed in Phase F.
| Dimension | Architecture Roadmap | Implementation Plan |
|---|---|---|
| Origin | Phase E (initial); Phase F (refined) | Phase F (finalised) |
| Granularity | Work packages; transition architectures; high-level timelines | Project schedules; resource assignments; cost plans; milestones |
| Audience | Architecture stakeholders; sponsor; architecture board | Programme managers; project teams; PMO |
| Contains | Work package list; dependencies; transition states; timeline bands | Detailed project plans; risk registers; budgets; governance checkpoints |
Section 6: Implementation Factor Assessment
Before the roadmap can be committed, Phase E requires an Implementation Factor Assessment — a structured review of the factors that could affect the feasibility or cost of delivery. This assessment is recorded in the Implementation Factor Assessment and Deduction matrix.
| Factor | Definition | Example |
|---|---|---|
| Risks | Events or conditions that could negatively affect achievement of the Target Architecture | Vendor lock-in on a legacy platform; staff skill gaps for new technology |
| Constraints | Non-negotiable limitations that bound what solutions are possible | Regulatory requirement to retain data on-premises; fixed programme budget |
| Assumptions | Statements treated as true for planning purposes but not yet confirmed | The new ERP will be available by Q2; headcount freeze will be lifted |
| Dependencies | Relationships between work packages or external events that determine sequencing | Application migration depends on network upgrade completing first |
Section 7: Prioritization Techniques & Part 2 Scenarios
With a long list of work packages identified, Phase E must establish an initial prioritization to inform the roadmap sequence. TOGAF does not prescribe a single method, but three approaches appear frequently in Part 2 scenarios:
- Business value vs. complexity matrix: Plot each work package on a 2×2 grid. High value / low complexity = "quick wins" to do first. High value / high complexity = "strategic bets" requiring dedicated programmes. Low value items are candidates for deferral or elimination.
- Quick wins first: Deliver tangible benefits early to build stakeholder confidence and demonstrate EA value. Particularly effective when there is pressure to show ROI from the architecture programme.
- Dependencies-first approach: Sequence work packages so that foundational items (e.g., infrastructure, data platforms, identity services) are delivered before the packages that depend on them. This is the most technically rigorous approach and usually required for large transformations.
In practice, all three approaches are combined: start by mapping dependencies to determine hard sequencing constraints, then apply the value/complexity matrix within each dependency-feasible sequence to select which packages to prioritize.
Part 2 Phase E scenarios typically present a completed set of gap analyses and ask: (a) which work packages should be prioritized first? — answer using business value and dependency logic, not just business value alone; (b) how many transition architectures are needed? — answer based on the scale of change and natural delivery boundaries, not an arbitrary number; (c) what is the key output of Phase E? — always the initial Architecture Roadmap, not the finalised plan (that is Phase F). When the scenario says "the organisation cannot absorb all changes at once," the correct action is to define Transition Architectures, not reduce scope.
Revision Summary — Chapter 07
- Phase E is the first ADM phase primarily concerned with implementation; it synthesises the work of Phases A–D into an actionable Architecture Roadmap.
- Key inputs: all Phase B–D architectures and gap analyses; technology forecasts; architecture principles. Key outputs: Architecture Roadmap (initial), Transition Architecture list, Implementation Factor Assessment, Work Package list.
- A Work Package is a discrete, manageable delivery unit — smaller than a project and smaller than a Transition Architecture; it has deliverables, dependencies, resources, and risks.
- Transition Architectures represent stable, deployable, operable intermediate states between Baseline and Target — not milestones or half-finished targets.
- The T1 → T2 → Target pattern applies when the gap is too large to close in one step; each transition must be viable on its own and is governed as a complete architecture state.
- The Architecture Roadmap (Phase E) is high-level and concept-driven; the Implementation & Migration Plan (Phase F) is detailed, costed, and scheduled — these are different documents.
- The Implementation Factor Assessment captures four factor types: Risks, Constraints, Assumptions, and Dependencies — all four must be documented before roadmap commitments are made.
- Prioritization combines the business value/complexity matrix with a dependencies-first sequencing discipline; Phase E sets initial priorities and Phase F finalises them with full resource and cost plans.
Practice Questions
Five exam-style questions covering Phase E concepts. Click a question to reveal the answer and explanation.
A. Develop the Target Business Architecture and perform a gap analysis
B. Finalise and prioritise the Architecture Roadmap with detailed schedules and resource plans
C. Generate the initial complete version of the Architecture Roadmap and identify work packages and transition architectures
D. Oversee implementation projects and ensure architecture conformance through compliance assessments
Explanation: Option C is correct. Phase E is the first phase primarily concerned with implementation — it generates the initial Architecture Roadmap by consolidating gap analyses and identifying work packages and transition architectures. Option A describes Phases B/C/D. Option B describes Phase F (finalising, not generating, the roadmap). Option D describes Phase G (Implementation Governance).
A. Architecture Vision
B. Transition Architectures
C. Work Packages
D. Implementation Factor Assessment
Explanation: Option B is correct. Transition Architectures define stable, deployable intermediate states of the enterprise between Baseline and Target. Each is viable and operable on its own, allowing the enterprise to pause or re-plan at each transition point. Work Packages (C) are the delivery units within each transition, not the states themselves. The Implementation Factor Assessment (D) captures risks and constraints but does not define the intermediate states. The Architecture Vision (A) was created in Phase A.
A. Risk
B. Assumption
C. Constraint
D. Dependency
Explanation: Option C is correct. A Constraint is a non-negotiable limitation that bounds what solutions are possible. A data residency policy is a firm boundary — it cannot be optimised away or treated as an assumption. A Risk (A) is a potential negative event, not a known restriction. An Assumption (B) is something treated as true but unconfirmed. A Dependency (D) is a sequencing relationship between work packages.
A. Sequence packages so that those on which others depend are delivered first
B. Sequence packages by descending business value regardless of technical order
C. Sequence packages from lowest to highest complexity to build team capability gradually
D. Sequence packages alphabetically to ensure objectivity
Explanation: Option A is correct. Dependencies create hard sequencing constraints — if Package X depends on Package Y, delivering X before Y is technically impossible or will fail. Dependencies-first sequencing must be established before applying business value or complexity considerations. Business value (B) and complexity (C) are secondary filters applied within the feasible sequences. Option D has no architectural basis.
A. The Architecture Roadmap is created in Phase F; the Implementation & Migration Plan is created in Phase E
B. The Architecture Roadmap lists only technical work packages; the Implementation Plan lists only business change items
C. The Architecture Roadmap is owned by the PMO; the Implementation Plan is owned by the architecture team
D. The Architecture Roadmap is a high-level, architecture-owned view of work packages and transition states; the Implementation & Migration Plan is a detailed, project-level plan with schedules, costs, and resource assignments
Explanation: Option D is correct. The Architecture Roadmap (generated in Phase E, refined in Phase F) operates at the architecture level — it shows what needs to change and in what order, but does not include full project-management detail. The Implementation & Migration Plan (finalised in Phase F) provides the programme-management view with budgets, schedules, and resource plans needed to actually deliver the changes. Option A has the phases reversed. Options B and C mischaracterise the ownership and scope of both documents.