9.1 Phase F Objectives, Stakeholder Collaboration, and Governance Alignment

9.1 Phase F Objectives, Stakeholder Collaboration, and Governance Alignment

Phase F of the TOGAF Architecture Development Method (ADM) represents the critical juncture where architectural strategy transforms into an executable operational plan. While earlier ADM phases focus on understanding business context, defining architecture domains, and identifying candidate solutions, Phase F establishes the binding agreements and operational roadmaps that govern real-world implementation. Operating at the intersection of enterprise architecture, corporate finance, and portfolio delivery, Phase F ensures that technical transformations deliver tangible business value within the practical boundaries of funding, risk, and organizational capacity.

---

Primary Objectives of Phase F

The TOGAF Standard, 10th Edition states three objectives for Phase F:

1. Finalize the Architecture Roadmap and the supporting Implementation and Migration Plan.
2. Ensure that the Implementation and Migration Plan is coordinated with the enterprise's approach to managing and implementing change in its overall change portfolio.
3. Ensure that the business value and cost of work packages and Transition Architectures are understood by key stakeholders.

In practice the second objective means close cooperation with portfolio, program, and project management, finance, and operations, so the plan fits how the enterprise already funds and runs change.

---

Phase E vs. Phase F: The Architectural Shift

A central theme on the OGEA-103 examination is distinguishing between Phase E (Opportunities & Solutions) and Phase F (Migration Planning). Many candidates mistakenly view these phases as interchangeable. However, they represent fundamentally different architectural mindsets and levels of operational certainty:

• Phase E Focus (Architectural Feasibility & 'What' to Build): Phase E is exploratory and visionary. It gathers the gaps identified across the Business, Data, Application, and Technology architectures (Phases B through D), groups them into logical work packages, examines Solution Building Blocks (SBBs), and outlines candidate Transition Architectures. Phase E asks: What technical solutions can bridge our capability gaps, and are they architecturally viable?
• Phase F Focus (Execution Planning & 'How and When' to Deliver): Phase F is operational and pragmatic. It evaluates the candidate work packages against real-world enterprise constraints—such as annual capital budgets, regulatory deadlines, vendor delivery commitments, and organizational change readiness. Phase F asks: How do we prioritize, sequence, resource, fund, and govern these work packages to maximize business value while controlling operational risk?

---

Interfacing with Enterprise Portfolios and the PMO

Enterprise architecture cannot implement change in isolation. To succeed, enterprise architects must actively collaborate with enterprise Project Management Offices (PMO), program managers, and portfolio steering committees. This partnership requires a clear division of governance responsibilities to avoid friction and operational confusion.

The RACI Division Between Architecture and Project Management

A balanced governance model respects the core competencies of both disciplines. Enterprise architects govern architectural integrity, capability alignment, and technical standards, while project managers govern delivery execution, project schedules, and resource management.

Resolving Strategic vs. Tactical Conflict

A frequent scenario tested on the exam involves conflicts between strategic architecture roadmaps and tactical business unit demands. Business unit leaders often push for quick, uncoordinated point-to-point solutions to resolve immediate operational pain points. In Phase F, the enterprise architect must not simply veto tactical requests. Instead, the architect collaborates with the PMO to demonstrate how modular work packages and intermediate Transition Architectures can deliver early business value without incurring crippling technical debt or violating enterprise standards.

---

Governance Alignment with Corporate Budgeting and Fiscal Cycles

One of the most common reasons enterprise architectures fail in practice is a disconnection from the corporate budgeting calendar. An architect can design an elegant multi-year target architecture, but if the work packages are not aligned with how the enterprise allocates money, the roadmap remains an unfulfilled theoretical exercise.

Capital Expenditures (CapEx) vs. Operational Expenditures (OpEx)

In Phase F, architects must collaborate with corporate finance to classify migration investments correctly:

• Capital Expenditures (CapEx): Investments in long-term enterprise assets, such as purchasing perpetual software licenses, building dedicated data center facilities, or funding major new application developments that provide multi-year economic life. CapEx requires formal capital budgeting approval, business cases demonstrating Return on Investment (ROI), and multi-year depreciation schedules.
• Operational Expenditures (OpEx): Ongoing costs incurred to operate and maintain the business, such as cloud infrastructure subscriptions (Software-as-a-Service, Infrastructure-as-a-Service), third-party maintenance agreements, and professional managed services. OpEx must be accommodated within recurring divisional operational budgets.

Phase F migration planning must balance CapEx and OpEx constraints. For instance, transitioning from on-premises legacy mainframes to cloud-native platforms reduces capital asset acquisition but significantly expands monthly operational expenditure budgets, requiring coordination with operational cost owners.

Fiscal Calendars and Investment Stage-Gates

Corporate finance operates on strict fiscal cycles—typically annual budget planning conducted in the third and fourth quarters, supported by quarterly financial reviews. Enterprise architects must align Phase F milestones with these cycles:

1. Annual Budget Submissions: Work packages requiring new capital allocations must complete Phase F and obtain Architecture Board endorsement prior to the enterprise's annual capital planning cutoff.
2. Stage-Gate Funding Releases: Rather than releasing a $20M transformation budget in a single lump sum, modern corporate governance uses stage-gates. The corporate investment committee releases funding incrementally for each Transition Architecture only after the enterprise architect and PMO certify that the preceding transition state met its architectural compliance criteria and realized its expected business capabilities.
3. Operational Freezes: Migration planning must account for business-driven operational blackouts, such as year-end financial closing periods, seasonal retail peaks (e.g., Q4 holiday trading), or regulatory reporting deadlines, during which zero production cutovers are permitted.

---

The Phase F Seven-Step Progression

The TOGAF Standard defines seven steps for Phase F:

1. Confirm Management Framework Interactions for Implementation Planning: Coordinate with enterprise governance bodies, corporate portfolio management, and the PMO to establish shared planning vocabularies, project methodologies (e.g., Agile, Waterfall, Hybrid), and governance touchpoints.
2. Assign a Business Value to Each Work Package: Evaluate the strategic, financial, operational, and risk-reduction value of each proposed architectural initiative.
3. Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicle: Work with resource managers, technical leads, and procurement teams to determine required labor, specialized skill sets, hardware/software procurement lead times, and funding availability.
4. Prioritize the Migration Projects through the Conduct of a Cost/Benefit Assessment and Risk Validation: Execute trade-off analyses, cost-benefit evaluations, and risk scoring to determine project sequencing and identify viable Transition Architectures.
5. Confirm Architecture Roadmap and Update Architecture Definition Document: Validate that the sequenced work packages achieve the target architecture without unresolved architectural gaps; refine Transition Architecture definitions in the Architecture Definition Document (ADD).
6. Complete the Implementation and Migration Plan Deliverable: Synthesize project charters, consolidated schedules, resource allocations, funding profiles, and governance mechanisms into the formal plan.
7. Complete the Architecture Development Cycle and Document Lessons Learned: Close the development cycle, record lessons learned, and identify any changes needed to the Architecture Capability. The approved plan, finalized ADD, Architecture Requirements Specification, and Roadmap, together with any Implementation Governance Model, then guide Phase G.

---

Common Governance Pitfalls & Exam Traps

• The 'Architect as Micromanager' Anti-Pattern: Exam scenarios frequently present options where an enterprise architect attempts to direct daily engineering tasks, manage sprint backlogs, or draw detailed project Gantt charts. This is an exam distracter. Enterprise architects govern architectural constraints, interfaces, and transition states; project managers govern tasks, operational schedules, and team assignments.
• Disconnecting from Corporate Fiscal Calendars: Formulating a migration plan without verifying the corporate capital expenditure calendar produces dead-on-arrival roadmaps. Work packages requiring new funding must hit corporate budget windows.
• The 'Big Bang' Fallacy: Proposing a single, monolithic migration phase that attempts to shift directly from the baseline architecture to the target architecture without intermediate Transition Architectures introduces unacceptable risk and almost always earns low marks on OGEA-103 scenarios.
• Ignoring Existing Governance Frameworks: Architects who attempt to invent bespoke project governance procedures rather than integrating with the enterprise's existing PMO frameworks create organizational friction and governance failure.