Phase G: Implementation Governance

This is where the action begins. We have been planning all along and now we try to put things in place, to get something work. Phase G defines how the architect should constrain the implementation projects, monitor them, and produces a signed Architecture Contract.


The objective here is simple. We need to ensure that the implementation projects conform with the Target Architecture. We need to ensure that the implementation projects are doing what they should. Here, we perform appropriate Architecture Governance functions for the solution. This phase also looks into any implementation-driven architecture Change Requests.


In order to achieve this objective, TOGAF recommends the following steps for the 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


All the documents from the previous phases are finalized by now. All of them form an input to this phase

  • Request for Architecture Work (Preliminary Phase)
  • Capability Assessment (Phase A)
  • Organization Model for Enterprise Architecture (Phase A)
  • Tailored Architecture Framework (Preliminary Phase and Phase A)
  • Statement of Architecture Work (Phase A)
  • Architecture Vision (Phase A)
  • Architecture Repository
  • Architecture Definition Document (Built over all phases and finalized in Phase F)
  • Architecture Requirements Specification (Built over all phases and finalized in Phase F)
  • Architecture Roadmap (Built over all phases and finalized in Phase F)
  • Implementation Governance Model (Phase F)
  • Architecture Contract (This is still a Draft, to be finalized in this phase)
  • Request for Architecture Work identified in Phases E and F
  • Implementation and Migration Plan (Phase E, F)


Based on all the hard work here, we generate a Signed Architecture Contract. The implementation is assessed based on the governance requirements to generate a Compliance Assessment. And the formal Change Request is defined.

Finally, architecture compliant solutions are deployed. That includes

  • The implemented system - that complies with the specified architecture
  • Architecture Repository populated with all that was generated over this iteration.
  • Architecture compliance recommendations and dispensations
  • Recommendations on the requirements for the service delivery
  • Recommendations on performance metrics used to monitor the progress
  • Updated Service Level Agreements (SLAs) for the enterprise
  • Architecture Vision, updated post-implementation - what we made instead of what we wanted to make
  • Architecture Definition Document, updated post-implementation - an architecture, however precise, has limitations that are identified during implementation. One should meticulously update the ADD to ensure correspondence between the implementation and architecture.
  • Business and IT operating models for the implemented solution