← ADM cycle0/6 steps · 0%

Phase G: Implementation Governance

Govern the implementation: Architecture Contracts, compliance reviews, and architectural oversight of delivery projects.

About this phase

Phase G provides architectural oversight of the implementation. While delivery projects build and deploy the solutions, the architecture function ensures that what is built conforms to the Target Architecture — and that the architecture itself responds sensibly where full conformance isn't practical.

The central instruments are the Architecture Contract — a joint agreement between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of the architecture — and Architecture Compliance reviews, which assess implementation projects against the architecture.

Phase G runs in parallel with delivery: it starts when implementation begins and closes when the solution is fully deployed. Deviations are handled through dispensations or Change Requests via the Requirements Management process, and the phase ends with a post-implementation review.

Objectives

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 in this phase

0/6 · 0%

1.Confirm scope and priorities for deployment with development managementReview migration project priorities, identify enterprise and project-level building blocks, and identify areas where the architecture will guide development.
2.Identify deployment resources and skillsIdentify the system development methods and required skills of the delivery organization; educate teams on the architecture deliverables they must consume.
3.Guide development of solutions deploymentFormulate project recommendations, document the Architecture Contract, and update the Enterprise Continuum/repository with implementation learnings.
4.Perform Enterprise Architecture compliance reviewsReview projects against the architecture using the compliance assessment process; grant dispensations or raise Change Requests where justified.
5.Implement business and IT operationsCarry out the deployment: delivery of operations training, data migration, solution cut-over, and publication of the new baseline architectures to the repository.
6.Perform post-implementation review and close the implementationConduct post-implementation reviews, confirm business value delivery, and formally close the implementation projects for this increment.

Key inputs

Request for Architecture Work and Statement of Architecture Work
Architecture Vision
Organizational Model for Enterprise Architecture and Tailored Architecture Framework
Architecture Repository
Architecture Definition Document, Architecture Requirements Specification, Architecture Roadmap (finalized)
Implementation and Migration Plan
Implementation Governance Model
Architecture Contract (standard template)
Request for Architecture Work identified in Phases E and F

Key outputs

Architecture Contract (signed), as recommended in the compliance assessments
Compliance Assessments
Change Requests
Architecture-compliant solutions deployed — including the implemented system, populated Architecture Repository, compliance recommendations and dispensations, service delivery requirements, performance metrics, SLAs, Architecture Vision and Definition Document updated post-implementation, and Business and IT operating models for the implemented solution

Worked example — Meridian Retail Group

Generated sample documents for a fictional company, showing what this phase consumes and produces. They are illustrative study aids, not templates from the standard.

Example inputs

PFrom Preliminary Phase

AFrom Phase A: Architecture Vision

CFrom Phase C: Information Systems Architectures

DFrom Phase D: Technology Architecture

EFrom Phase E: Opportunities and Solutions

FFrom Phase F: Migration Planning

RMFrom ADM Architecture Requirements Management

example inputDeliverablefrom PreliminaryThe document from the sponsoring organization that triggers an ADM cycle — the key handoff from the Preliminary Phase into Phase A.

Request for Architecture Work

Sponsoring organization: Meridian Retail Group — Office of the COO Date: 2 April 2026 Reference: RAW-2026-001 Addressed to: Architecture Board (submitted via the Lead Architect)

Organization sponsors

Chief Operating Officer (business sponsor); Chief Information Officer (executive sponsor for architecture).

Mission statement

Deliver the "One Meridian" unified customer experience: any customer, recognized in any channel, served from a single view of orders, inventory, and preferences.

Business goals and changes

Increase repeat-purchase rate from 31% to 40% within 24 months
Enable buy-online-pickup-in-store (BOPIS) in all 240 stores
Consolidate 4 customer databases into a governed single customer view
Reduce integration spend by 20%

Strategic plans

Responds to the One Meridian strategy (FY26–FY28) and Board Directive 26-04. Goals map to drivers DRV-01 to DRV-04 in the Driver/Goal/Objective catalog.

Time limits

Architecture definition (Target Architecture and roadmap) approved before the 1 Nov 2026 peak trading freeze
First Transition Architecture in production before the FY27 peak freeze

Changes in the business environment

Competitors now offer click-and-collect as standard; digital revenue at 26% and rising; POS v9 reaches end of life in 2027.

Organizational constraints

Peak trading freeze: no production change 1 Nov – 15 Jan
Franchise stores operate their own POS until contract renewal (FY27)

Financial constraints

Indicative program envelope of $18M over 2 years, subject to Investment Committee approval per tranche.

External and business constraints

GDPR and PCI-DSS compliance mandatory
3PL logistics contract fixes EDI message formats until 2027

Current business system description

Channel-based operating model: Digital Commerce, Store Operations, and Customer Care each run their own customer processes and service standards.

Current systems description

4 customer databases, 3 order management systems, in-store POS (v9, EOL 2027), monolithic e-commerce platform, nightly-batch warehouse integration.

Developing organization and resources available

Meridian EA team (Lead Architect plus 4 domain architects), working under the Tailored Architecture Framework v1.0 and Architecture Principles v1.0. Business subject-matter experts released for up to 2 days per week during Phases B–D.

Success criteria

An approved Target Architecture and Implementation and Migration Plan for the One Meridian program, with the first Transition Architecture delivered before the FY27 peak trading freeze.

Submitted by: COO, 2 April 2026 · Accepted for Phase A: Architecture Board, 9 April 2026

Example outputs

example outputDeliverableThe joint agreement between the architecture function and a delivery program, defining conformance obligations.

Architecture Contract — Program "Commerce Core" (P5)

Reference: AC-2027-P5 · Template: Architecture Contract standard template v1.0 · Parties: Meridian Architecture Board; Commerce Core Program (SI partner: NorthBridge Consulting); Business sponsor: COO Term: Apr 2027 – Oct 2027 (to TA-2 acceptance)

1. Introduction and nature of the agreement

This contract is a joint agreement between the architecture function, the delivery program and the sponsor. The program commits to building what the architecture describes. The Architecture Board commits to timely reviews and decisions. The sponsor accepts the result as fit for purpose. It is governed under SAW-2026-001 and the Implementation and Migration Plan v1.0.

2. Scope and architecture deliverables consumed

The program shall implement Order Hub, Inventory Service, and BOPIS pilot per Architecture Definition Document v1.0 (§5–7) and Architecture Requirements Specification v1.0 (REQ-D-01..03, IR-04, REQ-T-01..07).

Deliverable consumed	Version	Use
Architecture Definition Document	v1.0	Target and TA-2 Transition Architecture
Architecture Requirements Specification	v1.0	Measurable acceptance requirements
Architecture Principles	v1.0	Principles 2 (data), 3 (buy before build), 4 (interoperability)
Technology Standards catalog	Oct 2026	Approved platform services and patterns

Out of scope: POS pilot (P6, separate contract), franchise stores, WMS changes other than the event adapter.

3. Conformance requirements

Integration exclusively via API Gateway and Event Streaming Service; no new point-to-point interfaces (Principle 4: Interoperability)
Customer data consumed only from Customer Profile Service (Principle 2)
Availability design to REQ-T-01 (99.95% checkout path), evidenced by architecture test results before Gate 4
Order Hub delivered as a configured packaged OMS (Principle 3); any custom code only through the vendor extension API
Order-lifecycle events published to the Meridian event schema standard v1.0
As a consumer of profile data, Order Hub honors GDPR erasure: requests propagate within 30 days with an audit trail (REQ-D-03), and Order Hub subscribes to the erasure event and confirms completion within 7 days (IR-04)

4. Target architecture measures (fitness for purpose)

Measure	Requirement	Evidence due
Checkout-path availability	≥ 99.95% monthly (REQ-T-01)	Gate 4 resilience test
Inventory event propagation	< 60s (REQ-T-04)	Gate 4 performance test
Peak elasticity	5× baseline checkout throughput (REQ-T-06)	Gate 4 load test
DR for Order Hub	RTO ≤ 1h, RPO ≤ 5min (REQ-T-07)	Gate 4 DR rehearsal

5. Governance touchpoints

Touchpoint	When	Evidence
Compliance review 1	PMO Gate 2 (design)	Solution design vs. ADD checklist
Compliance review 2	PMO Gate 4 (pre-deploy)	Test evidence vs. ARS requirements
Monthly architecture surgery	Ongoing	Decision log
Post-implementation review	After 2027 peak freeze	Benefit and SLA measures

6. Roles and responsibilities

Role	Party	Responsibility
Lead Architect	J. Okafor	Interprets the architecture; chairs reviews
Domain Architects	R. Mehta, S. Cho, A. Duarte	Perform compliance assessments
Program Director	L. Brennan	Delivers to contract; raises deviations early
SI partner	NorthBridge Consulting	Solution design, build, test evidence
Sponsor	COO	Accepts business fitness for purpose

7. Deviation handling

Deviations require a dispensation from the Architecture Board (max 12 months) or a Change Request via Requirements Management. The program must raise a known deviation within 10 working days and may not deploy it without a decision.

8. Acceptance

TA-2 acceptance requires: both compliance reviews passed, dispensations logged, repository updated with as-built SBB documentation.

Signed: Lead Architect · Program Director · COO — 12 Apr 2027

Study notes

Produced in: Step 3: Guide development of solutions deployment

The Architecture Contract is the main Phase G deliverable. It is a joint agreement between development partners and sponsors on deliverables, quality and fitness for purpose, signed by all three parties.
Section 3 turns Architecture Principles into obligations the program can be tested against. Section 4 adds measurable targets from the Architecture Requirements Specification. Together they form the basis of the compliance checklist.
The governance touchpoints mirror the PMO gates set up in the Preliminary Phase. Architecture governance runs inside the enterprise's delivery process instead of beside it.
Deviation handling names both routes: a time-bound dispensation or a Change Request. Exam questions often test which route fits a temporary deviation and which fits a permanent one.
Phase H later updates the contract (it is a Phase H input and output). A signed contract is not frozen for the life of the architecture.

Study tips & key concepts

The Architecture Contract is the key Phase G deliverable: a joint agreement on deliverables, quality, and fitness-for-purpose between development partners and sponsors.
Compliance terminology matters: irrelevant, consistent, compliant, conformant, fully conformant, non-conformant — learn the distinctions (e.g., 'compliant' = implements a subset of the specification correctly, nothing outside it that conflicts).
A dispensation allows a time-bound deviation from the architecture; if the deviation should become permanent, it goes through a Change Request instead.
Phase G runs concurrently with solution delivery — it isn't a gate at the end but continuous oversight, closing only when the solution is fully deployed.
Implementation learnings flow back: lessons and new building blocks are stored in the Architecture Repository, and unresolvable deviations become Change Requests feeding Phase H / Requirements Management.