A team is told to build against a target architecture that was approved 20 months ago, in what the EA function called Phase C. Nobody has revised the document since, and two of its nine named products have been discontinued by their vendors. The Open Group's ADM runs a Preliminary phase and Phases A to H with Requirements Management at the centre. Which phase do organisations actually skip, and what does skipping it cost?

The mechanism

The ADM is a cycle, and the phase that closes it is Phase H, Architecture Change Management — the phase whose job is to watch for technology and business change, decide whether it invalidates the architecture, and raise a new Request for Architecture Work when it does (The Open Group's published Phase H chapter, TOGAF 9 edition). Requirements Management sits at the centre of the diagram for the same reason: requirements arrive continuously rather than once in Phase A.

Almost every organisation runs Phases A to F, because those produce deliverables somebody asked for: a vision, a target architecture, a migration plan. Phase H produces no deliverable and has no obvious sponsor, so it is the phase that quietly does not happen. The cycle becomes a line, and a line ends at a document.

The consequence people miss

A target architecture has a shelf life, and nobody writes it on the cover. In a 20-month-old target state, a realistic decay rate is one to three of nine named components becoming wrong: a product discontinued, a vendor acquired, a team reorganised, a build-versus-buy answer reversed by a price change. The architecture is not 100% right or 0% right; it is roughly 70% right and nobody knows which 70%.

That uncertainty is what does the damage, because the parts that are still correct give the document authority over the parts that are not. A team that queries one component is told the architecture is approved. A team that quietly ignores the whole thing is right for the wrong reason, and the next team copies the deviation without knowing which deviations were justified.

What running Phase H actually looks like

It is small, and it is a standing job rather than a project:

1. A review date on the target architecture itself — 6 months is a defensible default for a fast-moving estate, 12 for a stable one. An artefact with no review date is asserting that the world stopped.
2. A short list of assumptions each component rests on, each with the event that would break it: the vendor's support end date, a licence renewal, the owning team's existence.
3. A standing trigger — a discontinued product, a failed proof of concept, or a team no longer able to own a component raises a change request rather than a workaround.
4. A published decision when the review happens: unchanged, amended, or withdrawn. Withdrawn is a valid and under-used outcome.

When this is the wrong answer

Below roughly 50 engineers and one or two products, the formal loop costs more than it returns: the people who would review the architecture are the people building it, and they already know the two components that went wrong. The signal that the loop is needed is not headcount, it is distance — when the person who approved a target state no longer talks weekly to the people building against it, the review date is doing work no conversation is doing.

Common weak answers

• "They skipped Phase G, Implementation Governance." Governance during delivery is usually present in some form, because delivery has a sponsor and a deadline. The missing phase is the one after delivery, when the architecture and the world start to diverge.
• "The framework is the problem." The ADM being used as a waterfall is a real failure, and it is a different one. Here the phases were run; the cycle was just never closed.
• "Re-run the whole ADM annually." That produces a fresh 200-page target state each year and the same decay. A review that can amend or withdraw single components is cheaper and lands faster.