Phase H, Architecture Change Management

In plain terms, Phase H is the phase that keeps the architecture current after it has been delivered. The correct technical name is Architecture Change Management, the eighth and final phase of the Architecture Development Method (ADM). Where the earlier phases build a target architecture and deliver it, Phase H watches what happens next and decides how the enterprise should respond when the world moves on.

The reason this phase exists is simple. An architecture is a set of decisions that were correct for a moment in time. New technology appears, business priorities change, regulators publish new obligations, and incidents expose weaknesses. Each of these is a change signal. Without a phase that receives those signals and decides what to do with them, an architecture either freezes and becomes irrelevant, or it drifts and becomes untrue to its own documentation. Phase H is the controlled middle path.

The TOGAF Standard sets out what the phase is meant to achieve. Read carefully, its objectives are about maximising the value the architecture keeps delivering, and about making sure changes go through a proper process rather than around it.

The heart of Phase H is a classification. Every change request is sorted into one of three categories, and the category alone decides how much of the ADM the change needs to touch. The TOGAF Standard names the three categories as simplification, incremental, and re-architecting change.

The plain idea behind the three names is a question of reach. Does the change make the current architecture cheaper or simpler to run? Does it add something new that still fits the plan we already agreed? Or does it break the assumptions the plan was built on, so the plan itself has to be reconsidered? Those three answers are the three categories.

• Simplification change. A change driven by a need to reduce investment, cost, or complexity. It optimises what already exists without adding new capability. It is the lightest category, usually handled through routine change governance.
• Incremental change. A change that adds capability or extends the architecture, but stays within the direction and constraints of the current target architecture. It re-enters the ADM part way through, typically at implementation governance or migration planning, because the target itself still holds.
• Re-architecting change. A change whose reach is large enough that the current target architecture no longer describes where the enterprise is going. It requires the ADM to be run again from the Architecture Vision, because the strategic picture has moved.

The categories are ordered by disruption for a reason. The whole value of the scheme is that it stops a small optimisation from triggering an expensive full cycle, and stops a strategic shift from slipping through disguised as a minor edit. That is exactly the failure in the opening story: eleven incremental-looking changes that were, together, a re-architecting change nobody named.

Classification is easiest to learn on concrete cases. London Grid Distribution is a Distribution Network Operator serving 2.3 million customers across Greater London, with 4,000 staff, 36,000 km of cable, and 77 primary substations, regulated by Ofgem under the RIIO-ED2 price control. Here are three change requests it might receive, one for each category.

Simplification. An operations team notices that two systems both receive the same meter-data feed, one of them a legacy path that nothing downstream still reads. Retiring the duplicate feed removes cost and complexity and adds no new capability. This is a simplification change. It is logged, risk-assessed for the one system that touches it, and handled through routine change governance. No ADM phase needs to reopen.

Incremental. The network planning team wants to add electric-vehicle charging demand as a new load type in the network model, so that reinforcement plans account for it. This adds capability, but it fits squarely inside the current target architecture: the data model, the platform, and the integration pattern all already anticipate new load types. This is an incremental change. It re-enters the ADM at the later phases, refreshing the relevant architecture definition and the migration plan, without questioning the overall direction.

Re-architecting. Ofgem signals that distribution operators are expected to move toward an active Distribution System Operator (DSO) role, actively balancing local generation, storage, and flexible demand in near real time. This is not an addition to the current target architecture; it changes what the enterprise is for. Capacity, data latency, market-facing interfaces, and control assumptions all shift. This is a re-architecting change. It restarts the ADM from the Architecture Vision, because the strategic picture, not just a component, has moved.

Notice how the same triage question separates all three: how far does the change reach against the current target architecture? Inside a component points to simplification; inside the plan points to incremental; beyond the plan points to re-architecting.

Phase H is best understood as a loop, not a straight line. Change requests arrive continuously from many sources: business demand, new technology, incidents, regulatory obligations, and the ordinary wear of running the estate. Each request enters a triage step, is classified into one of the three categories, and then re-enters the ADM at the point the category demands.

A change request is simply a documented ask to alter the architecture or the systems that realise it. It should carry enough information to be triaged: what is being asked, why, what it touches, and what happens if it is refused. The triage step assesses that request against the current target architecture and answers the reach question. The answer routes the request.

• Simplification re-enters through change governance only. The change is recorded, its narrow impact is assessed, and it is approved without reopening an ADM phase.
• Incremental re-enters the ADM at a later phase, commonly implementation governance or migration planning, refreshing the affected architecture definitions and the roadmap while leaving the target direction intact.
• Re-architecting re-enters at the Architecture Vision and runs the ADM cycle again, because the target architecture itself is now in question.

The discipline that makes the loop work is that classification is explicit and recorded. Every request produces a logged decision naming its category and its re-entry point. That record is what the opening story lacked: with it, the eleventh streaming-style change would have been caught as the point where an accumulation of incremental edits had quietly become a re-architecting decision.

A common worry is that a change-management phase adds a gate that slows delivery. Read correctly, Phase H does the opposite. Its purpose is to let change happen fast where it is safe and to reserve deliberation for change that genuinely reaches further than it looks.

Simplification changes are meant to move quickly through routine governance. Incremental changes touch only the later phases. Only re-architecting changes trigger a full cycle, and those are the changes that would otherwise cause the most damage if they slipped through unexamined. By classifying honestly, the enterprise spends its scarce deliberation where it counts and lets everything else flow.

The protection is against invisible drift, not against change. A change process that classifies and records is what allows an architecture to keep moving without losing the thread of why it looks the way it does. That is why Phase H sits inside the governance framework rather than beside it.

Phase H has a second job beyond triaging change. It is where the enterprise checks whether the architecture it delivered is actually producing the benefits that justified it. The plain idea is: we promised this change would pay off in a stated way, so let us measure whether it did. The technical name for that discipline is benefits realisation, sometimes called value realisation.

Benefits realisation only works if the promised benefits were written down before delivery, with a measure and a target attached. The business case that funded the work is the source of those measures. Phase H then monitors the live architecture against them and feeds the result back into the change process. A benefit that fails to appear is itself a change signal: it may justify a simplification, an incremental adjustment, or, if the shortfall is structural, a re-architecting decision.

For London Grid Distribution, the electric-vehicle load change from earlier carried a stated benefit: reinforcement plans that account for charging demand should reduce the number of unplanned network interventions in the areas modelled. Phase H monitoring tracks that measure after the change is live. If interventions fall as predicted, the benefit is realised and recorded. If they do not, the gap re-enters the change loop as a new request to investigate, closing the loop between decision and outcome.

London Grid Distribution runs Phase H as a standing change-management loop tied to its Ofgem obligations. Two features of the regulated context shape how the phase operates.

Classification is a governance record, not an informal call

Every change request produces a logged classification: simplification, incremental, or re-architecting, with the re-entry point named. Because the classification log is a governance artefact, an accumulation of incremental changes that together shift the target architecture becomes visible. The pattern that drifted invisibly in the opening story is exactly what the log is designed to surface.

Regulatory change is a first-class change source

For a network under RIIO-ED2, and looking ahead to the next price control, regulatory obligations are one of the largest sources of change requests. A new data-publication duty is often incremental. A shift toward an active DSO role is re-architecting. Phase H gives the enterprise a consistent way to tell those apart and to route each to the right depth of response, with a record that regulatory submissions can rely on.

Benefits realisation feeds the price-control story

Under Ofgem regulation, the network has to show that spending delivered value for customers. Phase H benefits-realisation monitoring produces exactly that evidence: each funded architecture change is tracked against the benefit its business case promised, and the result becomes part of how London demonstrates value in its regulatory reporting.