Phase G: Implementation Governance — Architecture That Survives Contact With Delivery

Phase: Phase G — Implementation Governance Perspective: Enterprise Architect

Many architecture programmes die in Phase G. Projects drift. Corners get cut. By the time you notice, the target architecture is unrecognisable. Phase G is where the EA function proves its operational value.

Key Inputs

Architecture Roadmap and transition architectures
Architecture Contracts
Project initiation documents
Change requests from delivery teams
Solution architecture deliverables
Test and review reports

The Process

Issue Architecture Contracts to projects
Review solution designs for compliance
Run Architecture Review Boards (ARBs)
Manage architecture change requests
Track implementation against architecture intent
Maintain updated architecture repository

Deliverables

Architecture Contracts
Compliance Assessments
Change Requests log
Implementation Review Reports
Updated Architecture Repository
Governance decisions record

Practitioner Perspective

Architecture governance is not bureaucracy — it is quality assurance for the enterprise's future state. The Architecture Contract is your primary instrument: it defines what projects are accountable for delivering in architecture terms, not just functional terms.

Run Architecture Review Boards consistently. They are the forum where architecture drift gets caught early — and early is the only time catching it is cheap. Establish a clear cadence: major design reviews at project initiation, checkpoint reviews at key milestones, and sign-off reviews before go-live.

When projects raise change requests, apply a structured assessment framework: does this change compromise the target architecture, or is it a legitimate refinement based on new information? Both answers are valid. The discipline is in making the assessment deliberately rather than reactively.

Build trust with delivery teams by being a problem-solver, not a blocker. The best governance is invisible — projects guided well rarely need enforcement. When you find yourself enforcing frequently, the issue is usually in how Architecture Contracts were written, not project behaviour.

The most common mistake: Running ARBs as passive review meetings rather than active governance forums. If every ARB ends with "approved," either your architecture is perfect (unlikely) or your governance is theatre (common).

Practical tips:

Create an Architecture Decision Record (ADR) template for projects — it makes compliance reviews faster and creates a valuable audit trail
Score compliance assessments on a defined rubric: fully compliant, compliant with conditions, non-compliant with approved exception, non-compliant — this creates consistency across reviewers
Track the ratio of "approved as submitted" to "approved with conditions" to "rejected" over time — a healthy ratio indicates both good project design and effective governance
Publish governance decisions openly: transparency reduces the perception that the ARB is a political rather than technical process

Part of a series: TOGAF from an Enterprise Architect's Perspective