6.3 Phase G: Implementation Governance
Key Takeaways
- Phase G objectives are to ensure conformance with the Target Architecture by implementation projects and to perform Architecture Governance functions for the solution and implementation-driven Change Requests.
- Phase G steps include confirming deployment scope with development management, guiding solution deployment, performing compliance reviews, and conducting a post-implementation review.
- Development organizations build the solution, while the architecture organization provides architectural oversight through Architecture Contracts and compliance reviews.
- Phase G outputs include a signed Architecture Contract, Compliance Assessments, Change Requests, and architecture-compliant solutions deployed.
- Dispensations for non-conforming work are granted for a given time period and set of operational parameters, after which compliance is re-assessed.
6.3 Phase G: Implementation Governance
Phase G provides an architectural oversight of the implementation. The Foundation syllabus asks you to briefly explain the purpose of Phase G and describe its objectives. Architecture Contracts and Architecture Compliance are covered in depth in Chapter 11; this section focuses on what Phase G does.
Objectives of Phase G
- Ensure conformance with the Target Architecture by implementation projects
- Perform appropriate Architecture Governance functions for the solution and any implementation-driven architecture Change Requests
Steps of Phase G
- Confirm Scope and Priorities for Deployment with Development Management
- Identify Deployment Resources and Skills
- Guide Development of Solutions Deployment
- Perform Enterprise Architecture Compliance Reviews
- Implement Business and IT Operations
- Perform Post-Implementation Review and Close the Implementation
Phase G brings together all the information needed for successful management of the implementation projects. The actual development is carried out by the development organization; the architecture organization provides architectural oversight, recommendations, and governance. TOGAF describes this in terms of establishing the implementation program and projects, deploying in phases according to the Implementation and Migration Plan, and making sure each implementation project is governed through an Architecture Contract and compliance reviews.
Inputs and Outputs
| Key inputs | Outputs |
|---|---|
| Implementation and Migration Plan; Implementation Governance Model (from Phase F) | Architecture Contract (signed) |
| Architecture Definition Document; Architecture Requirements Specification; Architecture Roadmap; Transition Architectures | Compliance Assessments |
| Request for Architecture Work identified during Phases E and F; Statement of Architecture Work; Architecture Vision | Change Requests |
| Architecture Contract (standard); Architecture Governance Framework; Architecture Repository | Architecture-compliant solutions deployed, including the implemented system, populated repository, compliance recommendations and dispensations, service delivery and performance recommendations, service level agreements, and post-implementation updates to the Architecture Vision and ADD |
Architecture Contracts in Phase G
An Architecture Contract is a joint agreement between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture. TOGAF says Phase G establishes the connection between architecture and the implementation organization through the Architecture Contract. At the beginning of Phase G, a contract is agreed between the architecture function and the function implementing the architecture, typically the in-house systems development function or a major contractor. Within the step Guide Development of Solutions Deployment, the architects document the Architecture Contract and obtain signatures from all developing organizations and the sponsoring organization. See Section 11.3.
Compliance Reviews in Phase G
Architecture compliance reviews check implementation projects against the architecture at defined checkpoints. The outcome is recorded in a Compliance Assessment. When a project cannot comply, it can be remediated, or a dispensation can be granted through the governance process for a given time period and set of identified services and operational parameters, with the project re-assessed when it expires. TOGAF defines six levels of conformance, from Irrelevant to Non-conformant, covered in Section 11.4.
Change Requests During Implementation
Implementation often reveals issues — new technology, a supplier constraint, or a requirement that cannot be met. Phase G handles implementation-driven architecture Change Requests as part of its governance function. Depending on their impact, these are handled within Phase G, passed to Requirements Management, or sent to Phase H for architecture change management.
Architecture Governance vs. Project Management: Distinct Responsibilities
A frequent source of confusion is conflating architecture governance with project management or software engineering practices:
| Dimension | Implementation Governance (Phase G) | Project Management (PMO / Scrum Master) |
|---|---|---|
| Primary Objective | Safeguard architectural intent, standards compliance, and long-term enterprise coherence | Deliver project scope within committed time, cost, and quality baselines |
| Primary Instrument | Architecture Contracts, Compliance Reviews, Dispensations, Architecture Board | Project Charters, Gantt Charts, Sprint Backlogs, Burndown Charts, Budgets |
| Level of Scrutiny | Architectural boundaries, API standards, data schemas, security protocols, building block reuse | Task completion, developer velocity, milestone dates, resource hours, sprint cadence |
| Authority Over Scope | Can halt deployment or reject solutions for severe architectural non-conformance | Manages scope trade-offs to meet delivery dates within contractual budget boundaries |
| Common Misunderstanding | Phase G does not write code, debug software, or run daily developer standups | Project managers do not grant architectural dispensations or redefine enterprise standards |
Scenario: Governing a Claims Platform Rollout
An insurer's Phase F plan calls for three releases of a new claims platform. In Phase G the architects confirm deployment scope and priorities with the development manager, agree an Architecture Contract with the system integrator, and review the solution design at two checkpoints. At the second review, the integrator's reporting component uses an unapproved database. The Compliance Assessment records the issue; the Architecture Board grants a six-month dispensation because a regulatory deadline cannot move, with a condition that the component migrates to the standard platform in release three. After go-live, a post-implementation review records lessons learned and updates the Architecture Definition Document.
Common Exam Pitfalls
- Thinking the architects build the solution. Development organizations implement; Phase G provides architectural oversight and governance.
- Forgetting the second objective. Phase G also performs governance functions for implementation-driven Change Requests.
- Confusing Phase G with Phase H. Phase G governs implementation; Phase H manages change to the architecture after it is in place.
- Treating dispensations as permanent. Dispensations are granted for a given time period and set of parameters, and compliance is re-assessed.
Which statement is an objective of Phase G: Implementation Governance?
Which step is performed in Phase G?
What is the role of the architecture organization during Phase G?
A compliance review in Phase G finds that a project cannot meet an architecture standard before a fixed regulatory deadline. What governance outcome does TOGAF describe?