Phase H: Architecture Change Management

Keep the architecture alive: monitor change, manage risk and value, and decide when a new ADM cycle is needed.

About this phase

Phase H keeps the architecture fit for purpose after deployment. It establishes continual monitoring of business and technology change — new requirements, technology developments, value realization, and risk — and manages changes to the architecture in a cohesive, governed way.

The central decision in this phase is classifying change: a simplification change (e.g., driven by cost reduction) can often be handled via change management techniques; an incremental change may be handled the same way or may justify partial re-architecting; a re-architecting change requires putting the whole architecture through the ADM cycle again.

A guideline to remember: if a change impacts two or more stakeholders, it is likely to require an architecture redesign and re-entry to the ADM. Phase H also supports the running Architecture Capability — operating the governance framework and managing the Architecture Contract through operations.

Objectives

Ensure that the architecture lifecycle is maintained.
Ensure that the Architecture Governance framework is executed.
Ensure that the Enterprise Architecture Capability meets current requirements.

Steps in this phase

0/7 · 0%

1.Establish the value realization processEnsure business projects harvest and report the business value from the deployed architecture.
2.Deploy monitoring toolsMonitor technology changes, business changes, capability maturity, and QoS performance (e.g., against SLAs) that could affect the architecture.
3.Manage risksManage architecture risks and provide recommendations for IT strategy — keeping the risk register current as the environment changes.
4.Provide analysis for architecture change managementAnalyze performance, conduct architecture performance reviews, assess Change Requests, and ensure the expected value is being realized.
5.Develop change requirements to meet performance targetsRecommend changes (with priorities) needed to keep the architecture meeting its performance targets.
6.Manage the governance processOperate the governance process and framework — Architecture Board meetings, decisions on Change Requests, dispensation reviews.
7.Activate the process to implement changeWhere a new cycle is warranted, produce a new Request for Architecture Work and ensure the change is captured in the repository and lifecycle governance.

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
Change Requests — from technology changes, business changes, and lessons learned
Implementation Governance Model and Architecture Contract (signed)
Compliance Assessments and Implementation and Migration Plan

Key outputs

Architecture updates (for maintenance changes)
Changes to the architecture framework and principles (where required)
New Request for Architecture Work — to initiate another cycle when re-architecting is required
Statement of Architecture Work (updated) and Architecture Contract (updated)
Compliance Assessments (updated)

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

DFrom Phase D: Technology Architecture

EFrom Phase E: Opportunities and Solutions

FFrom Phase F: Migration Planning

GFrom Phase G: Implementation Governance

RMFrom ADM Architecture Requirements Management

Prepared for this phase

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 outputDeliverablePhase H's assessment of a Change Request, classifying the change and deciding how it is handled.

Architecture change assessment — CR-021 (Marketplace channel)

Assessed by: Lead Architect · Decision body: Architecture Board, 25 Feb 2028 Contributors: Business Architect (T. Lindqvist), Data Architect (R. Mehta), Application Architect (S. Cho), Technology Architect (A. Duarte), DPO Change log entry: ACL-2028-01

Classification analysis

Dimension	Finding
Stakeholders impacted	Digital Commerce, Supply Chain, Store Ops, Finance (settlement), DPO — 5 stakeholder groups
Fit with Target Architecture	New channel and settlement flows not in current target; order intake extension is significant
Reuse of existing building blocks	High — Order Hub, Inventory Service, Store Fulfilment extend rather than change
Absorbable without redesign?	No — customer/consent model and settlement data flows require redesign

Impact by architecture domain

Domain	Impact	Size
Business	New "partner channel" capability; ship-from-store process; marketplace returns handling	Large
Data	Pseudonymous shopper entity; consent scope; settlement and commission entities	Large
Application	Order Hub intake adapter; stock feed; settlement interface to ERP	Medium
Technology	External partner tier on API Gateway; 24x7 support for order acknowledgement	Medium

Options considered

Option	Description	Assessment
A	Treat as incremental: build an Order Hub adapter now	Fast, but leaves consent and settlement undesigned. Repeats the point-to-point pattern One Meridian removed
B	New ADM cycle at segment scope (Commerce)	Designs data and settlement properly. Reuses existing SBBs. Fits a FY29 launch
C	Defer to the next enterprise-wide cycle	Misses the partner launch window. Revenue at risk

Decision

Classification: re-architecting change (bounded scope). Impacts more than two stakeholder groups and changes the data and application architecture fundamentals for order intake and settlement. Handle via a new ADM cycle at segment scope (Commerce segment), not as an incremental change.

Option B selected. The Board recorded that Architecture Principles v1.0 do not yet cover external partner integration or pseudonymous customers. The Lead Architect will propose principle changes before the new cycle starts Phase A.

Disposition

New Request for Architecture Work RAW-2028-002 drafted (below)
Interim guardrail: no tactical marketplace integration outside the ADM cycle (prevents point-solution regression to pre-One-Meridian patterns)
CR-021 closed as "superseded by RAW-2028-002"
Principles and Tailored Architecture Framework review scheduled for the 30 Mar 2028 Board

Risks of the decision

Risk	Mitigation
Business sees ADM cycle as delay	Segment scope only; Phase A to Phase F target of six months
Shadow integration by Marketing's agency	Guardrail above; checked in the next Compliance Assessment
Commerce Core team capacity during POS rollout (P7)	Architecture work led by the EA team; delivery in FY29

Request for Architecture Work RAW-2028-002 (summary)

Sponsor: Chief Commercial Officer; Scope: Commerce segment
Mission: marketplace channel with ship-from-store fulfilment, FY29 launch
Constraints: GDPR pseudonymous profiles; marketplace SLA (order ack < 15 min); reuse Order Hub/Inventory Service building blocks
Success criteria: approved segment Target Architecture and migration plan by Q3 FY28, launch before FY29 peak freeze

The full request is shown as a separate example below.

Study notes

Produced in: Step 4: Provide analysis for architecture change management · Step 6: Manage the governance process · Step 7: Activate the process to implement change

This is the central Phase H decision: classify the change as simplification, incremental, or re-architecting, then pick the handling. Five affected stakeholder groups point strongly to re-architecting.
High reuse of building blocks does not make a change incremental. The test is whether the change can be absorbed without redesigning fundamentals, and the consent and settlement models cannot.
Options analysis shows the Board choosing a segment-level cycle. A new ADM cycle does not have to be enterprise-wide, which is a frequent exam trap.
The disposition produces two Phase H outputs: a new Request for Architecture Work (step 7) and a recommendation to change the principles. The interim guardrail is an example of operating governance in step 6.

Study tips & key concepts

The three categories of architecture change: simplification (often cost-driven), incremental (add value within the design), and re-architecting (change the fundamentals — run the ADM again). Know which handling each gets.
Rule of thumb from the standard: a refreshment cycle is likely needed if a change impacts two or more stakeholders, and bottom-line guidance is whether the change can be absorbed without redesign.
Phase H is driven by ongoing monitoring: technology change (new/obsolete tech), business change (strategy, mergers, regulation), and value/QoS measurement.
Phase H outputs can loop back two ways: small changes → architecture updates under governance; big changes → a new Request for Architecture Work starting a new ADM cycle (possibly revisiting the Preliminary Phase).
Don't confuse Phase H (deciding on and governing change to the deployed architecture) with Requirements Management (the continuous process feeding requirements in and out of every phase).