10.1 Phase G Objectives, Implementation Governance Structure, and Project Architecture Hand-off

10.1 Phase G Objectives, Implementation Governance Structure, and Project Architecture Hand-off

Phase G of the TOGAF Architecture Development Method (ADM) marks the decisive transition where strategic architecture definitions materialize into operational reality. Throughout earlier phases of the ADM, enterprise architects define the baseline and target states across Business, Data, Application, and Technology domains (Phases B through D), evaluate candidate solution building blocks (Phase E), and establish a prioritized implementation roadmap with committed funding (Phase F). However, even the most rigorously designed target architecture remains an unfulfilled conceptual exercise if real-world engineering teams deviate from architectural standards during implementation. Phase G provides the continuous, formal oversight required to guide solution delivery, protect architectural integrity, and ensure the enterprise realizes its intended business value.

---

Objectives and Steps of Phase G

The TOGAF Standard, 10th Edition states two objectives for Phase G:

1. Ensure conformance with the Target Architecture by implementation projects.
2. Perform appropriate Architecture Governance functions for the solution and any implementation-driven architecture Change Requests.

Its six steps are:

1. Confirm scope and priorities for deployment with development management: review migration planning outputs, identify EA priorities for development teams, identify deployment issues, identify building blocks for replacement or update, and perform gap analysis on the Enterprise Architecture and solutions framework.
2. Identify deployment resources and skills, including the system development methods to be used and how they will feed design information back to the architecture team.
3. Guide development of solutions deployment: formulate a recommendation for each implementation project (scope, strategic requirements, Change Requests, rules for conformance, and timeline requirements, documented in an impact analysis); document the Architecture Contract and obtain signatures from all developing organizations and the sponsoring organization; update the Enterprise Continuum directory and repository for solutions; guide business and IT operating models and operational requirements; and produce the Implementation Plan.
4. Perform Enterprise Architecture Compliance reviews of ongoing implementation governance and each building block, conduct post-development reviews, and close the development part of deployment projects.
5. Implement business and IT operations, including publishing new Baseline Architectures to the Architecture Repository.
6. Perform post-implementation review and close the implementation.

TOGAF notes that an organization-specific development process runs in parallel with Phase G, and that the favored approach deploys the target as a series of transitions, each delivering business benefit in its own right.

Establishing Governance Over Concurrent Implementation Projects

In modern enterprises, an architectural roadmap is rarely executed by a single, monolithic delivery team. Instead, transformations unfold across dozens of concurrent, asynchronous projects, programs, agile release trains, and third-party vendor work streams. Phase G establishes a multi-tiered governance structure designed to maintain enterprise coherence while enabling delivery velocity.

The Multi-Tiered Implementation Governance Model

To balance enterprise coherence with project autonomy, the implementation governance structure operates across three distinct levels:

• Enterprise Architecture Board (Strategic Governance): Serves as the ultimate cross-domain governance authority. The Architecture Board approves Architecture Contracts, adjudicates cross-project dependency conflicts, and evaluates formal requests for dispensations or architectural change.
• Project Steering Committees & Domain Architects (Tactical Governance): Bridges the enterprise roadmap with individual project charters. Domain architects (Business, Data, Application, and Infrastructure) attend project stage gates, review solution designs, and evaluate integration touchpoints.
• Solution Delivery Teams & Agile Squads (Operational Execution): Consists of software engineers, systems integrators, cloud architects, and Scrum teams responsible for physical construction, automated testing, and deployment.

RACI Division of Governance Responsibilities

A classic pitfall on the OGEA-103 examination involves confusing the responsibilities of the enterprise architect with those of the project manager. The TOGAF Standard enforces a clean boundary: architects govern architectural integrity, standards conformance, and interface specifications, while project managers govern delivery schedules, task work breakdown structures, budgets, and operational resource assignments.

---

The Project Architecture Hand-Off Mechanism

The transition from migration planning (Phase F) to implementation governance (Phase G) requires a formal project architecture hand-off. The hand-off is not an abrupt "throw it over the wall" event where enterprise architects hand over static documentation and disappear. Rather, it is a structured, collaborative briefing and operationalization process.

Key Components of the Hand-Off

1. Translating ABBs to SBBs: Enterprise architects guide solution architects in translating conceptual Architecture Building Blocks (ABBs) defined in earlier phases into concrete, vendor-specific Solution Building Blocks (SBBs), commercial off-the-shelf (COTS) packages, or open-source frameworks.
2. Communicating Constraints and Principles: Delivery teams are briefed on non-negotiable architectural principles, cybersecurity baselines, data sovereignty laws, latency budgets, and interoperability mandates.
3. Establishing Compliance Stage Gates: The architecture team and PMO agree on mandatory compliance review gates (typically aligned with design sign-off, mid-build verification, and pre-go-live readiness).

Bridging Enterprise Architecture with Agile and DevOps Delivery

Modern enterprises frequently implement architecture through agile delivery frameworks (e.g., Scrum, SAFe, Spotify model). Enterprise architects bridge the gap with agile delivery through three collaborative mechanisms:

• Architectural Runway: Enterprise architects provide technical enablers, shared infrastructure, and foundational APIs ahead of user-facing sprint cycles, ensuring teams do not hit architectural dead ends.
• Enabler User Stories and Guardrails: High-level architectural requirements are decomposed into enabler user stories, non-functional requirements (NFRs), and architectural guardrails within the team's product backlog.
• Definition of Done (DoD) Integration: Architecture compliance criteria—such as automated static security scans, API schema validation, and logging standards—are embedded directly into the team's Definition of Done and automated CI/CD deployment pipelines.

---

Managing Technical Constraints and Discoveries During Implementation

Even the most rigorous enterprise architecture cannot anticipate every physical constraint encountered during low-level engineering. When implementation teams begin writing code, integrating legacy systems, or configuring cloud infrastructure, they frequently discover undocumented legacy behaviors, network throughput ceilings, or vendor software limitations.

The Governance Pathway: Local Adjustment vs. Formal Change Request

When unexpected technical realities emerge, Phase G provides two distinct handling mechanisms based on the severity of the deviation:

1. Local Implementation Tuning (Within Contract Tolerances): If an issue can be resolved using alternative Solution Building Blocks that adhere fully to the existing Architecture Contract, enterprise standards, and interface schemas, the solution architect approves the adjustment locally without escalating to the Architecture Board.
2. Architectural Deviation (Breaching Contract Boundaries): If resolving the constraint requires modifying external interfaces, introducing non-standard technologies, violating security policies, or delaying downstream work packages, the project cannot implement an ad-hoc workaround. The solution architect and project manager must submit a formal Change Request (CR) to the Architecture Board.

Preventing Architectural Erosion and Rogue Workarounds

A critical failure mode in enterprise implementations is the proliferation of undocumented, quick-and-dirty "code arounds" implemented under deadline pressure. These workarounds accumulate crippling technical debt, compromise cybersecurity posture, and break cross-system interoperability. Phase G governance ensures that all trade-offs are explicitly evaluated by the Architecture Board, resulting in an approved architecture update, a time-limited dispensation, or a mandated engineering redesign.

---

Phase G Inputs and Outputs

Knowing the inputs and outputs of Phase G is essential for the OGEA-103 examination:

---

Common Exam Traps & Anti-patterns

• The 'Architect as Project Manager' Anti-Pattern: Exam questions frequently tempt candidates with options where an enterprise architect steps in to manage daily developer sprint points, assign Jira tasks, or redraw Gantt charts. This is an incorrect distracter. Architects govern architectural conformance; project managers govern project execution.
• The 'Agile Exemption' Fallacy: Assuming that agile development squads are exempt from architecture governance because they are "autonomous." While agile teams have design freedom within their sprint backlogs, they must strictly adhere to enterprise architectural guardrails, data models, and interface contracts.
• Rogue Technical Workarounds: Assuming that a project team can bypass enterprise security standards or introduce unapproved database engines if it helps them hit an aggressive delivery milestone. All deviations must be channeled through formal Change Requests.
• The 'Rubber-Stamp' Compliance Anti-Pattern: Delaying all architectural reviews until the night before production deployment. When compliance reviews occur only at go-live, discovering non-compliance forces an impossible choice between catastrophic project delay and releasing defective architecture into production.