8.1 Phase E Objectives, Consolidated Gap Analysis, and Work Package Formulation

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:

1. 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.
2. Determine whether an incremental approach is required, and if so identify Transition Architectures that will deliver continuous business value.
3. 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

1. Determine/confirm key corporate change attributes, creating the Implementation Factor catalog
2. Determine business constraints for implementation
3. 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
4. Review consolidated requirements across related business functions
5. Consolidate and reconcile interoperability requirements
6. Refine and validate dependencies
7. Confirm readiness and risk for business transformation (Section 8.5)
8. Formulate the Implementation and Migration Strategy
9. Identify and group major work packages
10. Identify Transition Architectures
11. 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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

---

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:

---

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.