Study guide
8.1 Phase E Objectives, Consolidated Gap Analysis, and Work Package Formulation
TOGAF Enterprise Architecture Practitioner OGEA-103
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Mechanics & Foundation Overview
1.1 OGEA-103 Exam Structure, Gradient Scoring & Open-Book Strategy 1.2 The TOGAF Standard 10th Edition Structure & Core Concepts 1.3 Enterprise Architecture in Practice: Context, Scope, and Architecture Domains 1.4 The Context for Enterprise Architecture: Purpose, Capability, Security, and the Digital Enterprise
2 Chapter 2: Preliminary Phase & Establishing the EA Capability
2.1 Preliminary Phase Objectives, Inputs, and Activities 2.2 Scope of the Enterprise and Defining the Architecture Footprint 2.3 Establishing Architecture Governance, Frameworks, and Tools
3 Chapter 3: Architecture Vision & Stakeholder Management (Phase A)
3.1 Phase A Objectives, Request for Architecture Work, and Scope Definition 3.2 Stakeholder Management: Identification, Classification, the Power/Interest Grid, and the Stakeholder Map 3.3 Business Scenarios Technique for Problem Definition and Requirements Elicitation 3.4 Architecture Vision, Communications Plan, and Statement of Architecture Work Approval
4 Chapter 4: Business Architecture (Phase B)
4.1 Phase B Objectives, Steps, and Business Modeling Approaches 4.2 Business Capabilities, Capability Mapping, and Assessment 4.3 Value Streams, Value Stream Mapping, and Capability Cross-Mapping 4.4 Business Architecture Artifacts, Gap Analysis, and Architecture Definition Document Updates
5 Chapter 5: Information Systems Architectures — Data Architecture (Phase C)
5.1 Phase C Data Architecture Objectives, Approach, and Data Principles 5.2 Conceptual, Logical, and Physical Data Models and Data Management 5.3 Data Entity/Business Function Matrix, Data Architecture Gap Analysis, and Interoperability Requirements
6 Chapter 6: Information Systems Architectures — Application Architecture (Phase C)
6.1 Phase C Application Architecture Objectives, Approach, and Baseline vs. Target First 6.2 Application Portfolio Rationalization, Component Modeling, and Application Integration 6.3 Application/Organization Matrix, Application Gap Analysis, and Boundary Definitions
7 Chapter 7: Technology Architecture (Phase D)
7.1 Phase D Objectives, Cloud & Modern Platforms, and Technology Principles 7.2 Technology Standards, the Standards Library, Platform Services, and Infrastructure Modeling 7.3 Technology Gap Analysis, Non-Functional Requirements, and Reference Models
8 Chapter 8: Opportunities and Solutions (Phase E)
8.1 Phase E Objectives, Consolidated Gap Analysis, and Work Package Formulation 8.2 Architecture Building Blocks (ABBs) to Solution Building Blocks (SBBs) Transition 8.3 Transition Architectures, Incremental Delivery, and Dependency Analysis 8.4 Architecture Roadmap Development and Trade-Off Analysis 8.5 Business Transformation Readiness Assessment and Risk Management
9 Chapter 9: Migration Planning (Phase F)
9.1 Phase F Objectives, Stakeholder Collaboration, and Governance Alignment 9.2 Business Value Assessment, Cost-Benefit Analysis, and Risk/Feasibility Scoring 9.3 Implementation and Migration Plan Deliverable, Resource Allocation, and Transition Roadmaps
10 Chapter 10: Implementation Governance (Phase G)
10.1 Phase G Objectives, Implementation Governance Structure, and Project Architecture Hand-off 10.2 Architecture Contracts: Purpose, Types, Timing, and Stakeholder Commitments 10.3 Architecture Compliance Reviews: Conformance Levels, Process, Timing, and Checklists
11 Chapter 11: Architecture Change Management (Phase H) & Requirements Management
11.1 Phase H Objectives, Drivers of Architecture Change, and Value Monitoring 11.2 Change Classification: Simplification, Incremental, and Re-Architecting Changes 11.3 Ongoing Governance, Retirement of Solutions, and Maintenance vs. New ADM Cycle 11.4 Requirements Management: Central Role, Traceability, Mid-Phase Discovery, and Scope Conflict
12 Chapter 12: Architecture Governance, Boards, and Dispensations
12.1 Architecture Governance Framework, Organizational Roles, and RACI Matrix 12.2 Architecture Board Structure, Federation, Responsibilities, and Meeting Operations 12.3 Compliance Assessment, Dispensation Process, Expiration, and Remediation Tracking 12.4 Architecture Principles, the Decision Log, and Resolving Principle Conflicts
13 Chapter 13: Architecture Content Framework & Architecture Repository
13.1 The TOGAF Content Framework and Enterprise Metamodel 13.2 Deliverables, Artifacts (Catalogs, Matrices, Diagrams), and Building Blocks (ABBs vs SBBs) 13.3 Architectural Views, Viewpoints, Stakeholder Concerns, and ISO/IEC/IEEE 42010 13.4 The Enterprise Continuum and the TOGAF 10 Architecture Repository
14 Chapter 14: EA Capability, Tailoring, and Iteration
14.1 Tailoring the ADM: Enterprise Context, Process Weight, and Agile Integration 14.2 ADM Iteration Cycles, Levels, and Classes of Architecture Engagement 14.3 Architecture Maturity Models, Capability Assessment, and EA Performance Measures 14.4 Supporting the ADM Work: The TOGAF Library, Series Guides, Patterns, and Security
8.1 Phase E Objectives, Consolidated Gap Analysis, and Work Package Formulation
Key Takeaways Explain This Topic AI
Phase E has three objectives: generate the initial complete Architecture Roadmap, decide whether an incremental approach with Transition Architectures is needed, and define the overall Solution Building Blocks.
Phase E consolidates gap analysis results from Phases B to D in the Consolidated Gaps, Solutions, and Dependencies matrix and records implementation factors in the Implementation Factor catalog.
TOGAF's three basic implementation approaches are Greenfield, Revolutionary, and Evolutionary; common implementation methodologies are Quick win, Achievable targets, and the Value chain method.
Current systems are classified as Mainstream, Contain, or Replace, and gaps are grouped into work packages that deliver capability increments.
Phase E produces draft versions of the Architecture Roadmap and the Implementation and Migration Plan, which Phase F finalizes.
Last updated: October 2026
8.1 Phase E Objectives, Consolidated Gap Analysis, and Work Package Formulation
Phase E of the TOGAF Architecture Development Method (ADM), titled Opportunities and Solutions , marks the critical transition from architectural definition to implementation planning. While Phases A through D establish the "what"—articulating the Architecture Vision, Business Architecture, Information Systems Architectures (Data and Application), and Technology Architecture—Phase E is the first phase in the ADM that focuses directly on "how and when" the target architecture will be physically realized.
For enterprise architecture practitioners preparing for the OGEA-103 examination, Phase E demands a rigorous understanding of how to synthesize disparate domain-level gaps into coherent work packages, evaluate build-versus-buy implementation strategies, and construct the initial complete version of the Architecture Roadmap.
Phase E Core Objectives
The TOGAF Standard, 10th Edition states three objectives for 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.
Define the overall Solution Building Blocks (SBBs) to finalize the Target Architecture based on the Architecture Building Blocks (ABBs).
- The Eleven Steps of Phase E
- Determine/confirm key corporate change attributes, creating the Implementation Factor catalog
- Determine business constraints for implementation
Review and consolidate gap analysis results from Phases B to D, using the Consolidated Gaps, Solutions, and Dependencies matrix and, if appropriate, the Architecture Alternatives and Trade-offs technique
- Review consolidated requirements across related business functions
- Consolidate and reconcile interoperability requirements
- Refine and validate dependencies
- Confirm readiness and risk for business transformation (Section 8.5)
- Formulate the Implementation and Migration Strategy
- Identify and group major work packages
- Identify Transition Architectures
- Create the Architecture Roadmap and Implementation and Migration Plan (draft versions)
TOGAF notes that addressing dependencies "serves as the basis for most migration planning". The Level 2 learning outcomes also expect you to apply the risk and security considerations of Phases E, F, and G and to balance opportunity and viability .
Key Inputs Driving Phase E
Phase E does not generate solutions in a vacuum; it relies heavily on the architectural deliverables developed across preceding ADM iterations:
Request for Architecture Work & Architecture Vision (Phase A) : Provides the strategic business mandate, executive scope boundaries, key stakeholder goals, and overarching business constraints.
Draft Architecture Definition Document (Phases B, C, D) : Contains the baseline and target architectural models across all four core domains, accompanied by the domain-specific gap analysis results and candidate Architecture Building Blocks (ABBs).
Architecture Requirements Specification (Phases A-D) : Contains the consolidated catalog of functional and non-functional requirements (NFRs), including performance criteria, scalability thresholds, security policies, and regulatory mandates.
Capability Assessment & Business Readiness Assessment (Phases A-B) : Documents the organization's current maturity, cultural readiness for change, technical capabilities, and capability gaps that could impede implementation.
Enterprise Continuum & Architecture Repository : Catalogs reusable architectural assets, enterprise standards, reference architectures, and previous implementation deliverables available for reuse.
The Consolidated Gap Analysis Technique
In Phases B, C, and D, architects perform domain-specific gap analyses. For example, Phase B identifies gaps in business capabilities or organizational roles; Phase C identifies missing data entities or redundant applications; Phase D identifies obsolete server hardware or unencrypted network segments.
However, executing these gaps independently is an anti-pattern that leads to redundant investments, fragmented procurement, and conflicting project timelines. Phase E introduces the Consolidated Gap Analysis Technique , which synthesizes domain gaps into a unified cross-domain view.
Why Cross-Domain Consolidation is Mandatory
A gap in one architectural domain virtually never exists in isolation:
A Business Gap (e.g., establishing a 24/7 real-time fraud detection capability) directly requires an Application Gap (procuring or building a stream-processing rules engine).
That Application Gap requires a Data Gap (establishing a consolidated, real-time customer transaction schema and event topic).
That Data Gap in turn mandates a Technology Gap (deploying a managed Apache Kafka cluster and low-latency storage across multi-region cloud infrastructure).
Finally, operationalizing this chain requires a return to Business Architecture to train fraud analysts and establish new incident handling procedures.
The Consolidated Gap Analysis technique cross-references these relationships in a Consolidated Gaps, Solutions, and Dependencies Matrix . This matrix enables the architect to:
Identify Cross-Domain Synergies : Discover where a single technology investment (e.g., an enterprise API gateway) simultaneously resolves gaps in application integration, data security, and business partner onboarding.
Eliminate Redundancies : Detect duplicate initiatives across business units (e.g., three separate departments attempting to procure different customer ticketing tools).
Map Strict Predecessor-Successor Dependencies : Ensure that foundational technical enablers (such as identity federation) precede application cutovers.
Formulating Work Packages from Consolidated Gaps
In the TOGAF Standard, a Work Package is defined as a set of actions that achieves one or more architectural objectives. It represents the structural link between architecture design and project portfolio execution.
Architectural Criteria for Grouping Gaps into Work Packages
Enterprise architects use five primary criteria to cluster consolidated gaps into bounded work packages:
Functional Cohesion : Gaps that support a single business capability, business process, or customer value stream stage should be grouped together. This ensures accountability to a single business sponsor.
Technical and Architectural Coupling : Components that share tight data relationships, synchronous API contracts, or common infrastructure platforms should reside within the same work package to minimize cross-project synchronization friction.
Organizational Ownership and Governance Boundaries : Work packages should align with the organizational units or domain teams (e.g., product teams or squads) responsible for running the solution in production, avoiding split accountability.
Risk and Change Velocity : High-risk, complex changes (e.g., migrating core financial ledger data) should be isolated from lower-risk, rapid user interface enhancements to avoid stalling agile delivery streams.
Procurement and Sourcing Boundaries : Changes that depend on a specific external software vendor or systems integrator should be packaged to align with commercial contracting boundaries.
Evaluating Implementation Options: Build, Buy, Cloud, or Partner
Once work packages are formulated, the enterprise architect must guide the organization in selecting the appropriate implementation approach for each package. The TOGAF Standard emphasizes that architecture must remain objective, evaluating options against strategic business value and architectural constraints.
Implementation Option Architectural Context & When to Recommend Trade-Offs & Architectural Risks
Build (Custom Development) Core capabilities providing proprietary competitive differentiation, unique intellectual property (IP), or novel customer experiences where no commercial market solution exists. High initial capital expenditure (CAPEX), long lead times, demands skilled internal engineering talent, creates permanent technical debt and ongoing maintenance obligations.
Buy COTS (Commercial Off-The-Shelf) Standardized, non-differentiating operational processes (e.g., payroll, standard general ledger accounting, facility management) where industry best practices are mature. Rapid time-to-value and vendor-supported maintenance; risk of vendor lock-in, rigid data models, and the severe anti-pattern of over-customizing vendor software to fit legacy quirks.
Cloud SaaS / PaaS / IaaS Elastic workloads, digital collaboration tools, commoditized business services, or modern distributed applications seeking minimal data center footprint. Converts CAPEX to operational expenditure (OPEX), provides instant scalability, eliminates hardware lifecycle management; requires stringent review of data sovereignty, compliance (GDPR/HIPAA), and egress cost structures.
Outsource / Partner / Systems Integrator Large-scale one-time migrations, specialized niche legacy refactoring (e.g., COBOL decompilation), or non-core operational functions where internal expertise is absent. Frees internal personnel to focus on core strategic initiatives; requires robust vendor governance, clear Architecture Contracts, and risks losing critical institutional knowledge.
Formulating the Implementation and Migration Strategy
Step 8 first selects one of three basic approaches to implementation:
Greenfield : a completely new implementation.
Revolutionary : a radical change, in other words "switch on, switch off".
Evolutionary : a strategy of convergence, such as parallel running or a phased approach that introduces new capabilities.
It then selects an approach that addresses and mitigates the risks recorded in the Consolidated Gaps, Solutions, and Dependencies matrix. The most common implementation methodologies are Quick win (snapshots) , Achievable targets , and the Value chain method . These approaches, plus the identified dependencies, become the basis for creating work packages.
Step 9 fills in the "Solution" column of the Consolidated Gaps, Solutions, and Dependencies matrix. For every gap it indicates whether the solution should be new development, an existing product, or something purchased, and for new development whether to build in-house or by contract. It also classifies every current system under consideration as:
Mainstream : part of the future information system.
Contain : expected to be replaced or modified in the planning horizon (TOGAF's example is the next three years).
Replace : to be replaced in the planning horizon.
Top-level work packages are decomposed into increments that deliver capability increments , and work packages are grouped into portfolios and projects with their dependencies in mind.
Consolidated Gaps to Work Packages Matrix
The table below illustrates a concrete practitioner artifact developed during Phase E for a global retail enterprise modernizing its omnichannel operations:
Domain Consolidated Gap Description Architectural Implication Target Work Package Sourcing Strategy Initial Target Milestone
Business / App Inability to provide unified order tracking across retail stores, website, and mobile app. Requires omnichannel order orchestration engine and real-time inventory visibility. WP-101: Omnichannel Order Orchestration Buy (COTS SaaS) Order visibility across web and mobile within 6 months.
Data Customer profiles are fragmented across 6 regional relational databases with conflicting schemas. Requires enterprise Master Data Management (MDM) Golden Record and real-time synchronization. WP-102: Customer Master Data Consolidation Buy COTS MDM Hub + Custom Integration Golden Record operational for top 2 business units in 9 months.
Technology On-premises data center infrastructure lacks elastic auto-scaling during seasonal holiday traffic spikes. Requires multi-region cloud landing zone, container orchestration (Kubernetes), and automated CI/CD pipelines. WP-103: Cloud Foundation & Platform Services Cloud IaaS / PaaS (AWS/Azure) Production-ready landing zone and network interconnects in 3 months.
Application Legacy point-of-sale (POS) terminal software uses proprietary binary protocols incompatible with modern APIs. Incompatible with cloud event stream; requires modernization or API encapsulation layer. WP-104: POS Modernization & Edge Gateway Build Custom Edge Adapter; Plan COTS POS Replacement API Edge Adapter deployed to 500 store nodes in 12 months.
Exam Practitioner Scenario: Modernizing Omnichannel Banking
Scenario : Global Mercantile Bank operates 220 retail branches and an online portal. A Phase A Architecture Vision established two strategic goals: (1) launch instantaneous mobile account opening with real-time biometric verification within 9 months, and (2) replace the 30-year-old mainframe core deposits ledger within 3 years.
In Phase E, the enterprise architect reviews the consolidated gap analysis:
Gap 1 (Business/Application) : Mobile onboarding requires third-party biometric verification and automated credit scoring.
Gap 2 (Data) : Customer account data is locked in mainframe VSAM files, updated only via nightly batch runs.
Gap 3 (Technology) : The mainframe infrastructure cannot scale to support mobile peak concurrency.
Architectural Analysis & Work Package Formulation :
The architect must NOT attempt a single monolithic project to replace the core mainframe ledger while simultaneously launching mobile onboarding. Doing so violates risk isolation principles and guarantees missing the 9-month mobile deadline.
Instead, the architect formulates WP-A (Digital Onboarding Engine) using a modern SaaS identity and biometric verification provider (Buy/SaaS), coupled with WP-B (Core Event Streaming & Read-Only Replica) using Change Data Capture (CDC) to stream mainframe deposit data in real time to a cloud-native read-only database (Build/Cloud PaaS).
The full replacement of the core mainframe ledger is isolated into a separate, multi-phase work package: WP-C (Core Banking Ledger Modernization) , planned across a 36-month timeline.
This formulation delivers immediate business value for Goal 1 at Month 9, while laying the foundational event-driven data architecture needed for Goal 2.
Common Exam Traps & Pitfalls
Trap 1: Confusing Phase E with Phase F : Exam questions frequently ask where detailed project scheduling, cost-benefit calculations, and resource leveling take place. Candidates often mistakenly select Phase E. Remember: Phase E creates the initial, complete draft of the Architecture Roadmap and identifies candidate work packages ; Phase F (Migration Planning) finalizes the detailed project plans, prioritizes portfolios with the PMO, and creates the formal Implementation and Migration Plan .
Trap 2: Assuming Phase E Signs Procurement Contracts : While Phase E identifies candidate Solution Building Blocks (SBBs) and evaluates build-versus-buy criteria, formal contract negotiation, vendor selection sign-off, and legal execution occur in Phase F and Phase G.
Trap 3: Formulating Siloed Work Packages : Grouping gaps purely by technical domain (e.g., all Data gaps in Project 1, all Business gaps in Project 2) is a classic failure mode. Work packages must be organized around cohesive capabilities and architectural dependencies, not isolated technical silos.