6.1 Phase E: Opportunities & Solutions
Key Takeaways
- Phase E generates the initial complete version of the Architecture Roadmap based on gap analysis and candidate roadmap components from Phases B, C, and D.
- Phase E determines whether an incremental approach is required and, if so, identifies Transition Architectures that deliver continuous business value.
- Phase E steps include consolidating gap analysis results, reconciling interoperability requirements, confirming readiness and risk, and identifying and grouping major work packages.
- TOGAF implementation and migration strategies are Greenfield, Revolutionary, and Evolutionary.
- Phase E outputs include the initial complete Architecture Roadmap, an updated Capability Assessment, and a draft Implementation and Migration Plan.
6.1 Phase E: Opportunities & Solutions
Phase E conducts initial implementation planning and identifies delivery vehicles for the architecture defined in Phases B, C, and D. The Foundation syllabus asks you to briefly explain the purpose of Phase E and describe its objectives.
Objectives of Phase E
- Generate the initial complete version of the Architecture Roadmap, based upon the gap analysis and candidate Architecture Roadmap components from Phases B, C, and D
- Determine whether an incremental approach is required, and if so identify Transition Architectures that will deliver continuous business value
Phase E is the first phase directly concerned with implementation. It concentrates on how to deliver the architecture, taking into account the complete set of gaps across all domains, the enterprise's ability to absorb change, and the constraints on implementation.
Steps of Phase E
- Determine/Confirm Key Corporate Change Attributes
- Determine Business Constraints for Implementation
- Review and Consolidate Gap Analysis Results from Phases B to D
- Review Consolidated Requirements Across Related Business Functions
- Consolidate and Reconcile Interoperability Requirements
- Refine and Validate Dependencies
- Confirm Readiness and Risk for Business Transformation
- Formulate Implementation and Migration Strategy
- Identify and Group Major Work Packages
- Identify Transition Architectures
- Create the Architecture Roadmap & Implementation and Migration Plan
The migration planning techniques in the ADM Techniques document support these steps — for example the Implementation Factor Catalog (factors affecting implementation, such as risks, issues, assumptions, dependencies, actions), the Consolidated Gaps, Solutions, and Dependencies Matrix, the Architecture Definition Increments Table, and the Transition Architecture State Evolution Table.
Reviewing and Synthesizing the Consolidated Gap Analysis
During Phases B, C, and D, architects generate domain-specific gap analysis results using the TOGAF Gap Analysis technique. In each domain, building blocks are categorized as included in both states, new in the target, or eliminated from the baseline, with each elimination checked for intent. However, analyzing gaps within isolated architectural silos creates blind spots.
In Phase E, architects perform a Consolidated Gap Analysis that synthesizes findings across all four BDAT domains:
- A business capability gap in Phase B (e.g., automated real-time fraud detection) inevitably drives data gaps in Phase C (e.g., unified transaction event streaming schemas), application gaps in Phase C (e.g., a machine-learning scoring service), and technology gaps in Phase D (e.g., low-latency distributed compute clusters).
- By evaluating these interdependencies together, architects eliminate redundant initiatives, surface cross-domain technical prerequisites, and avoid proposing isolated point solutions that fail to address systemic operational constraints.
Work Packages and Candidate Solutions
What Is a Work Package?
TOGAF defines a work package as "a set of actions identified to achieve one or more objectives for the business. A work package can be a part of a project, a complete project, or a program." In Phase E, related gaps and building blocks are grouped into work packages so they can be managed as coherent units of change. Each work package is typically classified according to how it will be delivered — new development, purchased solution, or re-use of an existing solution.
Transitioning from ABBs to SBBs
Phases A through D focus predominantly on Architecture Building Blocks (ABBs), which define capability requirements, service contracts, and technology-neutral specifications. In Phase E, architects begin identifying candidate Solution Building Blocks (SBBs).
Candidate SBBs represent candidate physical products, commercial software packages, custom software components, and infrastructure platforms that could satisfy the ABBs. For example, while an ABB specifies an "Enterprise Single Sign-On and Identity Broker Service," candidate SBBs evaluated in Phase E might include specific identity platforms, cloud-native directory services, or federated open-source protocols.
Implementation and Migration Strategy
Phase E formulates an overall Implementation and Migration Strategy. TOGAF describes three basic strategies and three implementation approaches:
| Implementation and migration strategy | Meaning |
|---|---|
| Greenfield | Starting from the beginning, with little or no existing baseline to accommodate |
| Revolutionary | Radical change, such as switching the old solution off and the new one on |
| Evolutionary | A strategy of convergence, such as parallel running or a phased approach |
| Implementation approach | Meaning |
|---|---|
| Quick win (snapshots) | Deliver early, visible results in selected areas |
| Achievable targets | Set realistic intermediate targets that the organization can reach |
| Value chain method | Sequence change along the value chain of the business |
Transition Architectures
Why Organizations Cannot Move Directly to Target States
In complex digital enterprises, moving directly from a legacy baseline architecture to a modern target architecture in a single, "big bang" release is frequently impossible. Barriers to direct implementation include:
- Excessive Business and Operational Risk: Discarding legacy systems overnight risks catastrophic service outages, data corruption, and regulatory penalties.
- Budgetary and Capital Expenditure Limits: Enterprises cannot fund all transformation initiatives simultaneously; capital allocation must be staged across fiscal quarters.
- Change Absorption Capacity: As surfaced during the Business Transformation Readiness Assessment (BTRA) in Phase A, employees, partners, and customers can only absorb a finite amount of workflow change at any given time.
- Technical and Regulatory Prerequisites: Certain foundational capabilities (e.g., enterprise master data management or network virtualization) must be fully operational before advanced customer-facing applications can function.
Defining Characteristics of Transition Architectures
When a single-step transition is unfeasible, architects define one or more Transition Architectures (e.g., Transition Architecture 1, Transition Architecture 2). Well-designed Transition Architectures share three qualities:
- Independent Architectural Coherence: It is a complete, well-defined architecture state spanning necessary BDAT domains, not merely an incomplete, unstable construction site.
- Discrete Business Value: It delivers tangible business benefit, operational improvement, or measurable risk reduction on its own merits, even if subsequent phases are delayed or cancelled.
- Viable Stepping Stone: It establishes the technical and organizational foundation required to advance toward the ultimate Target Architecture.
Evaluating Buy vs. Build vs. Reuse and Interoperability
During Phase E, architects formulate candidate solutions by conducting structured trade-off analyses across delivery alternatives:
| Delivery Strategy | When to Select | Key Architectural Trade-offs & Governance Concerns |
|---|---|---|
| Reuse Existing Assets | Established internal services or enterprise platforms already fulfill the functional requirement. | Lowest initial cost and fastest time-to-market; may carry technical debt or limit modern feature adoption. |
| Buy (Commercial COTS / SaaS) | The capability represents a standard commodity business process (e.g., general ledger, core payroll, standard CRM). | Rapid deployment and vendor-managed innovation; requires organizational compromise to adapt business processes to software defaults. |
| Build (Custom Software / Cloud Native) | The capability provides unique competitive differentiation, proprietary intellectual property, or custom algorithmic advantage. | Maximum alignment with bespoke operating models; highest upfront development expenditure, prolonged delivery timeline, and ongoing maintenance burden. |
Assessing Interoperability and Co-existence
Because Transition Architectures introduce intermediate states where modern platforms operate alongside legacy mainframes and databases, architects in Phase E must define Interoperability Requirements:
- Technical Interoperability: Establishing API gateways, event buses, schema translation layers, and protocol bridges.
- Operational Interoperability: Ensuring cross-system observability, unified identity access management, and coordinated disaster recovery.
- Co-existence Strategies: Defining dual-write mechanisms, data synchronization pipelines, and progressive retirement protocols for legacy building blocks.
Enterprise Transition Comparison: Single-Step vs. Multi-Stage Scenarios
To illustrate the application of Phase E concepts, consider an enterprise modernizing a 25-year-old core banking and customer servicing platform:
| Transformation Dimension | Single-Step ("Big Bang") Approach | Multi-Stage Transition Architecture Approach |
|---|---|---|
| Implementation Strategy | Attempting direct cutover from legacy monolithic mainframe to cloud-native microservices in one cutover weekend. | Staging delivery across two defined Transition Architectures over 24 months before reaching the Target Architecture. |
| Transition Architecture 1 | None. Organization remains entirely on legacy systems until cutover date. | Core Decoupling: API mediation layer deployed over mainframe; customer data replicated to real-time event store; digital channels read from new data store. |
| Transition Architecture 2 | None. | Service Migration: New account origination and payment microservices deployed to cloud; mainframe retained strictly as general ledger system of record. |
| Target State Architecture | All functions migrated to cloud-native platform. | Complete Core Modernization: General ledger modernized to cloud-native SaaS; legacy mainframe fully decommissioned. |
| Risk Profile & Value Delivery | Extreme catastrophic failure risk; zero business value delivered until final cutover at month 24. | Low risk; continuous incremental business value delivered at month 6 (TA 1) and month 15 (TA 2). |
Outputs of Phase E
| Output | What it contains |
|---|---|
| Refined and updated Architecture Definition Document and Architecture Requirements Specification | Updates from consolidating gaps, requirements, and dependencies |
| Capability Assessment | Enterprise Architecture maturity profile and transformation readiness assessment |
| Architecture Roadmap (initial complete version) | Work package portfolio, identification of Transition Architectures, and implementation recommendations |
| Implementation and Migration Plan (draft) | High-level implementation and migration strategy |
Common Exam Pitfalls
- Saying Phase E finalizes the plan. Phase E generates the initial complete Architecture Roadmap and a draft plan; Phase F finalizes them.
- Forgetting the second objective. Phase E decides whether an incremental approach is needed and, if so, identifies Transition Architectures that deliver continuous business value.
- Ignoring readiness and interoperability. Phase E steps confirm readiness and risk for business transformation and reconcile interoperability requirements.
- Treating work packages as always being single projects. A work package can be part of a project, a project, or a program.
Which statement is an objective of Phase E: Opportunities & Solutions?
In Phase E, what determines whether Transition Architectures should be identified?
Which implementation and migration strategy uses convergence, such as parallel running or a phased approach?
Which step belongs to Phase E?