Section 1: Phase G Overview
Phase G — Implementation Governance — is the ADM phase in which the architecture team provides oversight during the execution of projects identified in the Implementation and Migration Plan. Its core purpose is to ensure that each implementation project conforms to the agreed architecture.
The ADM phase that provides an architectural oversight of the implementation. Its objective is to ensure conformance with the defined architecture while implementations are under way, and to produce Architecture Contracts that formally bind implementation teams to the agreed architecture.
Key Distinction: Governance vs. Project Management
Phase G is not about managing implementation projects. It does not schedule tasks, allocate project resources, or track project milestones. That is the responsibility of the project management office. Phase G is purely about architecture conformance oversight — ensuring that what is being built matches what was designed. Confusing these two is a common error in Part 2 scenarios.
| Dimension | Phase F (Planning) | Phase G (Governance) | Phase H (Change Mgmt.) |
|---|---|---|---|
| Focus | Finalise the implementation plan | Oversee active implementation for conformance | Manage post-implementation changes |
| Key Output | Migration Plan, Transition Architectures | Architecture Contracts, Compliance Assessments | Change Requests assessed, ADM trigger |
| Trigger to move on | Plan is approved and funded | Solution is deployed and in production | Change magnitude assessed |
Inputs and Outputs
Key Inputs to Phase G:
- Implementation and Migration Plan (from Phase F)
- Architecture Definition Document (all domains)
- Architecture Contract (draft — from Phase E/F)
- Architecture Requirements Specification
- Architecture Roadmap
- Governance frameworks and compliance requirements
Key Outputs from Phase G:
- Architecture-compliant solutions (deployed)
- Architecture Contracts (signed by both parties)
- Compliance Assessments
- Change Requests (raised where deviations occur)
- Architecture-compliant implemented system
- Updated Architecture Repository (Governance Log entries)
Part 1 frequently asks for the primary purpose of Phase G. The answer is always about architecture conformance oversight, not project management. If an answer option says Phase G "manages implementation projects" or "allocates resources to projects," it is incorrect. The correct framing is always about ensuring what is built matches the approved architecture.
Section 2: Architecture Contracts in Phase G
A joint agreement between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture. Architecture Contracts establish a formal commitment that implementation work will conform to the architecture and meet agreed quality criteria.
Two Types of Architecture Contract
Development Architecture Contract
Agreed between the architecture team and the development team. Governs what the development team must build and to what quality standards. Focuses on the design and construction of the solution.
Operations Architecture Contract
Agreed between the architecture team and the operations team. Governs how the deployed solution will be operated, maintained, and supported. Focuses on SLAs, operational standards, and ongoing conformance.
Contract Contents
Every Architecture Contract must document the following elements:
- Introduction and background — scope, context, and reference to the Statement of Architecture Work
- Agreed deliverables — specific components, systems, or services to be produced
- Conformance requirements — the architecture standards, principles, and patterns that must be met
- Quality measures and acceptance criteria — fitness-for-purpose criteria; measurable acceptance gates
- Timescales and milestones — when deliverables are expected and when reviews will occur
- Sign-off process — who approves conformance at each milestone
Who Signs an Architecture Contract
An Architecture Contract is signed by the Architecture Board (representing the architecture function) and the project sponsor or development lead (representing the implementation team). This dual sign-off is critical — it creates mutual accountability. The Architecture Contract is directly related to the Statement of Architecture Work: the SoAW authorises the architecture work; the Architecture Contract governs how that architecture is implemented.
Know that there are two Architecture Contracts: one with the development team and one with the operations team. Part 1 may ask which type covers ongoing operational standards — that is the Operations Contract. Part 2 scenarios may present a situation where the development team has signed off but operations have not — the contract set is incomplete until both are in place.
Section 3: Compliance Review Process
When and Who
Compliance reviews are conducted at project initiation (to confirm the project will comply before it begins) and at key project milestones (design review, build completion, user acceptance testing, deployment). Reviews are conducted by the Architecture Review Board or a delegated architect acting on its behalf. The Architecture Board does not need to perform every review personally — it may delegate to a named architect, but it retains accountability.
The Compliance Spectrum
TOGAF defines four positions on the compliance spectrum. Each position has governance implications:
Fully Compliant
The implementation meets all architecture standards and principles without exception. No action required. This is the target state for all implementations.
Conformant
The implementation meets the spirit and intent of the architecture, but does not satisfy every prescriptive standard. Minor deviations are acknowledged and accepted without formal dispensation.
Non-Conformant
The implementation deviates from the architecture in a material way and no dispensation has been granted. Requires escalation. The project cannot proceed without either correcting the deviation or obtaining a dispensation.
Dispensation Granted
The Architecture Board has formally approved a specific deviation from the architecture for documented business reasons. The project may proceed as planned despite the deviation. A dispensation is time-limited and recorded in the Governance Log.
Architecture Compliance Report Contents
When a compliance review is completed, an Architecture Compliance Report is produced. It records: the project name and scope reviewed; the date and participants of the review; a list of architecture standards against which the project was assessed; the compliance status for each standard; identified deviations with their business impact; recommended actions; and the overall compliance verdict (one of the four spectrum positions).
Escalation Path for Non-Conformance
When non-conformance is identified: (1) the reviewing architect documents the deviation in a compliance report; (2) the report is escalated to the Architecture Board; (3) the Architecture Board notifies the project sponsor and issues a non-conformance notice; (4) the project team must either rectify the deviation or submit a dispensation request with business justification; (5) if dispensation is granted, it is recorded in the Governance Log; (6) if dispensation is denied, the project must correct the deviation before proceeding.
Part 1 tests the four compliance states. The most commonly confused pair is Conformant vs. Fully Compliant: Conformant means meeting the spirit but not every prescriptive standard; Fully Compliant means meeting all standards. Both are acceptable outcomes; neither requires a dispensation. Only Non-Conformant requires escalation and either remediation or a formal dispensation.
Section 4: Architecture Board Responsibilities in Phase G
The Architecture Board is the governance body that oversees Phase G. Its responsibilities during implementation governance include:
| Responsibility | Description |
|---|---|
| Approve deliverables | Sign off on architecture deliverables at project milestones; confirm they meet the Architecture Contract |
| Grant or deny dispensations | Review dispensation requests; approve deviations with documented justification and time limits; deny where business risk is unacceptable |
| Issue non-conformance notices | Formally notify the project team and sponsor when non-conformance is detected; initiate remediation process |
| Manage waivers and exceptions | Record, track, and time-limit any waivers or exceptions to architecture standards; ensure they do not become permanent |
| Maintain Governance Log | Ensure all decisions, dispensations, compliance results, and exceptions are recorded in the Governance Log within the Architecture Repository |
The Architecture Board has the authority to halt an implementation project if non-conformance is severe and no dispensation is granted. This is a governance power. Part 2 scenarios may ask what the Architecture Board should do when a project refuses to correct a deviation — the correct answer is to escalate to the Chief Architect or executive sponsor and formally issue a non-conformance notice, not to accept the deviation silently.
Section 5: Governance Log
A record maintained within the Architecture Repository that captures all governance decisions, dispensations, compliance assessment results, waivers, exceptions, action items, and risks arising during Phase G. It provides an auditable trail of governance activity.
The Governance Log records the following categories of information:
- Governance decisions — formal decisions made by the Architecture Board, with date and rationale
- Dispensations — approved deviations including scope, justification, approver, and expiry date
- Compliance results — results of each compliance review per project and milestone
- Action items — agreed remediation actions, owners, and due dates
- Risks — architecture risks identified during implementation, with mitigation actions
- Waivers and exceptions — time-limited exceptions to standards, with conditions for renewal or removal
The Governance Log is stored in the Architecture Repository (specifically in the Architecture Landscape or Governance Model sections) and is maintained by the Architecture Board or its delegated administrator.
Section 6: Implementation Support
While Phase G is primarily a governance phase, the architecture team also provides active support to implementation teams. This support role is distinct from governance and includes:
- Responding to implementation questions — clarifying architectural intent where design documents are ambiguous; providing architectural guidance on design decisions not explicitly covered in the architecture documents
- Managing change requests from implementation teams — when implementation reveals practical constraints that were not anticipated, the project team raises Change Requests to the architecture team; the architecture team assesses the impact and decides whether to accommodate the change within the existing architecture or to escalate to the Architecture Board
- Participating in project reviews — architecture team members may sit on design review boards or acceptance testing panels to provide architecture perspective
- Updating architecture documentation — where agreed changes are made, the Architecture Definition Document and related artefacts must be updated to reflect the as-built architecture
Change Requests that arise during Phase G are handled differently depending on their magnitude. Minor changes (within the approved architecture) are accommodated by the architecture team directly. Significant changes (that alter the architecture itself) must be assessed by the Architecture Board and may trigger a new ADM cycle starting at Phase A or at an appropriate re-entry point. Part 2 scenarios will test your ability to categorise the magnitude of a change and recommend the correct governance response.
Section 7: Relationship to Phase H
Phase G ends and Phase H begins when the solution being governed has been deployed into production and the governance focus shifts from implementation conformance to ongoing change management. The trigger for transitioning to Phase H is the confirmation that the implemented solution is in operation and that the architecture team's attention must now turn to managing changes to that deployed solution over its operational lifetime.
| Aspect | Phase G ends when… | Phase H begins when… |
|---|---|---|
| Trigger | Solution is deployed; Architecture Contracts are closed; compliance confirmed | Deployed solution is in production; operational change management is needed |
| Focus shifts from | Conformance during build | Managing ongoing changes to the deployed architecture |
| Artefacts handed over | Compliance Assessments, signed Contracts, Governance Log entries, updated Architecture Repository | Architecture Updates, assessed Change Requests, ADM re-entry trigger decision |
It is important to note that Phase G and Phase H can overlap in a programme context. When a programme has multiple projects, some projects may still be in Phase G (under active implementation governance) while earlier projects have already transitioned to Phase H (their changes are being managed). TOGAF explicitly supports this concurrent reality through its iteration model.
Section 8: Part 2 Scenario Guidance for Phase G
Part 2 scenarios involving Phase G almost always present a situation where a project is deviating from the approved architecture. The decision tree below guides your answer selection:
| Scenario Trigger | Correct Governance Action | Why |
|---|---|---|
| Project is deviating and deviation is minor, reversible, low-risk | Document in Governance Log; issue advisory; require correction before next milestone | Proportionate response; escalation not yet warranted |
| Project is deviating and deviation is significant but has valid business justification | Architecture Board reviews dispensation request; if approved, grant time-limited dispensation and record in Governance Log | Business reality sometimes requires approved exceptions; dispensation is the correct mechanism |
| Project is deviating and deviation is significant with no justification | Architecture Board issues formal non-conformance notice; project must remediate before proceeding | Non-conformance without dispensation cannot be permitted to proceed unchallenged |
| Project raises a change that would alter the architecture itself | Raise a Change Request; Architecture Board assesses magnitude; significant change triggers ADM re-entry | Changes to the architecture are handled through Phase H or a new ADM cycle, not within Phase G governance |
Dispensation vs. Enforcement — The Key Judgment
Part 2 questions ask you to judge when to grant a dispensation versus enforce compliance. Grant dispensation when: (1) there is a documented business reason; (2) the risk of the deviation is understood and accepted; (3) the deviation is time-limited; and (4) the deviation does not undermine the integrity of the overall architecture. Enforce compliance (deny dispensation) when: the deviation is architecturally fundamental, sets a dangerous precedent, lacks business justification, or would compromise security, interoperability, or regulatory compliance.
In Part 2 gradient-scored questions, answers that recommend doing nothing about non-conformance score zero. Answers that recommend immediate project cancellation without due process also score poorly. The highest-scoring answers follow the governance process: document, escalate appropriately, assess, decide (dispensation or remediation), and record. Always look for the answer that balances architecture integrity with pragmatic business delivery.
Revision Summary — Chapter 09
- Phase G provides architecture oversight during implementation; it ensures conformance, not project management — never confuse the two.
- Key inputs: Implementation & Migration Plan, Architecture Definition Document, Architecture Contract (draft). Key outputs: signed Contracts, Compliance Assessments, Change Requests, Governance Log entries.
- Two Architecture Contract types: Development Contract (with build team) and Operations Contract (with ops team); both signed by the Architecture Board and the relevant project sponsor.
- The compliance spectrum has four positions: Fully Compliant, Conformant, Non-Conformant, and Dispensation Granted — only Non-Conformant requires mandatory escalation and remediation or dispensation.
- The Architecture Board approves deliverables, grants or denies dispensations, issues non-conformance notices, manages waivers, and maintains the Governance Log.
- The Governance Log (stored in the Architecture Repository) records all governance decisions, dispensations, compliance results, risks, and action items — it is the audit trail for Phase G.
- Phase G ends and Phase H begins when the solution is deployed into production and the focus shifts from implementation conformance to ongoing change management.
- For Part 2 scenarios: grant dispensation when deviation has documented justification and is time-limited; enforce compliance (deny dispensation) when the deviation threatens architecture integrity, security, or regulatory compliance.
Practice Questions
Five exam-style questions covering this chapter. Click a question to reveal the answer and explanation.
A. Finalise the Implementation and Migration Plan and prioritise work packages
B. Manage the scheduling, resourcing, and delivery of implementation projects
C. Provide architecture oversight during implementation to ensure conformance with the defined architecture
D. Manage changes to the deployed architecture after it has gone into production
Explanation: Option C is correct. Phase G is about architecture oversight and conformance — ensuring that what is being built matches the agreed architecture. Option A describes Phase F (Migration Planning). Option B describes project management, not architecture governance — Phase G explicitly does not manage projects. Option D describes Phase H (Architecture Change Management), which follows Phase G.
A. The Chief Information Officer and the project manager
B. The Architecture Board and the project sponsor (or development/operations lead)
C. The enterprise architect and the business analyst
D. The Chief Executive Officer and the Chief Architect
Explanation: Option B is correct. An Architecture Contract is a joint agreement between the Architecture Board (representing the architecture governance function) and the project sponsor or development/operations lead (representing the implementation or operations team). This dual sign-off creates mutual accountability. Options A, C, and D name parties who may be involved in broader governance but are not specifically the signing parties defined by TOGAF for Architecture Contracts.
A. Conformant
B. Fully Compliant
C. Non-Conformant
D. Dispensation Granted
Explanation: Option A is correct. Conformant means the implementation meets the spirit and intent of the architecture even though it does not satisfy every prescriptive standard. This is an acceptable compliance position that does not require a formal dispensation. Option B (Fully Compliant) would mean all standards are met without exception. Option C (Non-Conformant) would mean a material deviation with no approved exception. Option D (Dispensation Granted) would mean a formal, board-approved exception exists — which the scenario states does not.
A. Cancel the project immediately as the deviation is unacceptable
B. Allow the deviation to proceed without any formal record
C. Assess the dispensation request, and if business justification is sound and risk is acceptable, grant a time-limited dispensation and record it in the Governance Log
D. Escalate to the CEO and wait for executive direction before taking any action
Explanation: Option C is correct. This is the correct dispensation process: the project team raises a dispensation request; the Architecture Board assesses it; if the business justification is sound and the risk is acceptable, a time-limited dispensation is granted; the decision is recorded in the Governance Log. Option A is disproportionate — the deviation has valid business reasons. Option B creates an unacceptable gap in the audit trail. Option D bypasses the Architecture Board's authority without cause; executive escalation is not warranted here.
A. The Architecture Board approves the final Architecture Contract
B. The implemented solution is deployed into production and ongoing change management is required
C. All dispensation requests have been resolved
D. The Implementation and Migration Plan is formally closed by the project management office
Explanation: Option B is correct. Phase G ends when the solution has been deployed into production and the governance focus shifts from implementation conformance (Phase G) to managing ongoing changes to the live architecture (Phase H). Option A (contract approval) happens within Phase G, not as a trigger to exit it. Option C (resolving dispensations) is a Phase G activity, not its end trigger. Option D (closing the migration plan) is a project management activity, not an architecture governance trigger.