Phase G of the TOGAF Architecture Development Method (ADM)—Implementation Governance—is often described as the "bridge" between architectural design and operational reality. While previous phases focus on what to build and how to plan it, Phase G focuses on ensuring it is built correctly.
The primary objective of Phase G is to provide architectural oversight for implementation projects. It ensures that the deployed solution conforms to the defined Target Architecture and that any deviations are managed through formal processes. This phase is not about doing the coding or construction; it is about governance, compliance, and adaptation.
This guide zooms in on the three critical deliverables of Phase G, providing detailed definitions, components, and practical examples to help architects execute this phase effectively.
The Compliance Assessment is a formal evaluation of an implementation project against the agreed-upon architecture specifications. It determines whether the solution being built adheres to the standards, principles, and designs defined in Phases B, C, and D.
To identify gaps between the designed architecture and the implemented solution.
To ensure quality, security, and interoperability standards are met.
To provide stakeholders with confidence that the investment is yielding the intended architectural value.
Assessment Criteria: The specific standards, principles, and requirements used as the benchmark (e.g., "All APIs must use OAuth 2.0").
Evidence Collection: Documentation, code reviews, test results, and configuration files gathered from the implementation team.
Gap Analysis: A comparison of the evidence against the criteria.
Rating/Status: A classification of compliance (e.g., Compliant, Non-Compliant, Waiver Granted).
Recommendations: Actions required to resolve non-compliance.
Context: The development team has completed the first release of the new Mobile Banking App. The Enterprise Architect must assess compliance before production deployment.
Compliance Assessment Document Excerpt:
| Criterion | Requirement | Evidence Reviewed | Status | Findings |
|---|---|---|---|---|
| Security | All data in transit must use TLS 1.3 | Network capture logs & Config files | Compliant | TLS 1.3 confirmed on all endpoints. |
| Identity | Must use Central Identity Service (ABB) | Code review of login module | Non-Compliant | Team built a custom local login instead of using the centralized ABB. |
| Performance | API response time < 200ms | Load test results | Compliant | Avg response time 150ms. |
| Accessibility | WCAG 2.1 AA Compliance | Automated accessibility scan | Waiver Granted | Minor contrast issues found; business accepted risk for V1 launch. |
Outcome: The assessment flags the "Custom Login" as a critical non-compliance issue because it bypasses central security monitoring. This triggers a Change Request.
A Change Request in Phase G is a formal document submitted when the implementation deviates from the planned architecture, or when external factors necessitate a change in scope, design, or timeline. It is the mechanism by which the architecture remains agile and responsive to real-world constraints.
To formally record deviations from the target architecture.
To evaluate the impact of changes on cost, schedule, and business value.
To obtain approval from the Architecture Board or stakeholders for necessary modifications.
Requestor Information: Who is requesting the change (e.g., Lead Developer, Project Manager).
Description of Change: What is changing? (e.g., replacing a technology, altering a data flow).
Reason for Change: Why is this necessary? (e.g., technical impossibility, new regulatory requirement, vendor discontinuation).
Impact Analysis:
Technical Impact: Does it break other systems?
Business Impact: Does it affect functionality or user experience?
Cost/Schedule Impact: How much extra time/money is needed?
Recommendation: Accept, Reject, or Defer.
Approval Status: Signed off by the Architecture Board.
Context: The development team explains that the Central Identity Service was not ready in time for their sprint. They built a custom login to meet the launch deadline.
Change Request Document Excerpt:
CR ID: CR-2024-089
Title: Replace Custom Login with Central Identity Service Post-Launch
Requestor: Jane Doe, Lead Mobile Developer
Description: The current V1 release uses a local authentication module. We request approval to keep this for V1 and integrate the Central Identity Service in V2 (scheduled for Q3).
Reason: The Central Identity Service API had unexpected latency issues during integration testing, risking the launch date.
Impact Analysis:
Security Risk: Medium. Local logs are not fed into the central SIEM.
Mitigation: Manual log exports will be performed daily until V2.
Schedule: No delay to V1 launch. V2 scope increased by 2 weeks.
Recommendation: Accept with Conditions. Approve V1 launch with custom login, but mandate integration of Central Identity Service in V2.
Approval: Approved by Chief Architect Sarah Chen on June 10, 2024.
While Architecture Building Blocks (ABBs) are reusable logical components defined in earlier phases (e.g., "Customer Data Service"), Solution Building Blocks (SBBs) are the actual, physical implementations of those components. In Phase G, SBBs are the delivered products, services, or code modules that are deployed into the live environment.
To document what was actually built and deployed, as opposed to what was planned.
To update the Architecture Repository with real-world specifications for future reuse.
To serve as the basis for operations and maintenance teams.
Product/Component Name: The specific vendor product or custom code module.
Version Number: The exact version deployed (e.g., v2.1.3).
Configuration Details: Key settings, dependencies, and interfaces.
Deployment Location: Where it resides (e.g., AWS US-East-1, Azure Kubernetes Cluster).
Owner/Maintainer: Who supports this SBB post-launch.
Link to ABB: Reference to the original architectural component it fulfills.
Context: After the V1 launch, the architecture team updates the repository with the actual SBBs deployed.
Solution Building Block Registry Excerpt:
| SBB Name | Type | Version | Technology Stack | Deployment Environment | Linked ABB | Owner |
|---|---|---|---|---|---|---|
| Mobile Auth Module | Custom Code | 1.0.2 | Java/Spring Boot | AWS EKS (Prod) | Central Identity Service (ABB) | Mobile Team |
| API Gateway | Commercial Product | Kong Enterprise 3.4 | Kong | AWS VPC | API Management Layer (ABB) | Platform Eng |
| Customer Data Cache | Open Source | Redis 7.0 | Redis | Azure Cache for Redis | Data Access Layer (ABB) | Data Team |
| Fraud Detection Engine | SaaS Service | v4.1 | Vendor API | Cloud (SaaS) | Fraud Analysis Service (ABB) | Security Ops |
Note: The "Mobile Auth Module" is flagged as a temporary SBB. The registry notes that it will be replaced by the standard "Central Identity Service" SBB in Q3, aligning with the approved Change Request.
These three deliverables do not exist in isolation; they form a feedback loop:
Compliance Assessment identifies a deviation (e.g., "Wrong technology used").
This triggers a Change Request to formally approve the deviation or mandate a fix.
Once the change is implemented (or waived), the Solution Building Blocks are updated in the repository to reflect the actual state of the enterprise.
This cycle ensures that the Architecture Repository remains a "single source of truth," even as the live environment evolves.
Automate Compliance Where Possible: Use DevOps pipelines to automatically check for security vulnerabilities, coding standards, and configuration drift. This reduces the manual burden of Compliance Assessments.
Keep Change Requests Lightweight: For minor changes, use a streamlined process. Reserve full Architecture Board reviews for high-impact deviations.
Update SBBs Immediately: Do not wait until the end of the project to update the SBB registry. Treat the repository as a living document that evolves with each deployment.
Collaborate, Don’t Police: Position the architect as a partner who helps developers solve problems, rather than a policeman who only finds faults. This encourages early disclosure of issues.
Phase G is where the rubber meets the road. Without rigorous Implementation Governance, even the most brilliant architecture can degrade into a fragmented, insecure, and unmaintainable mess. By mastering the three key deliverables—Compliance Assessment, Change Request, and Solution Building Blocks—architects ensure that the enterprise’s digital assets remain aligned with strategic goals, secure, and ready for future evolution.
In the next phase, Phase H: Architecture Change Management, these SBBs will become the baseline for ongoing operational changes, ensuring the architecture continues to deliver value long after the initial project closes.
