Transition Architecture

A 30-month platform programme is cancelled at month nine when the business direction changes. The organisation now runs the old integration layer, two-thirds of a new one, a message broker with 4 producers of a planned 14, and a team reorganised out of existence. Nothing has been switched off. The estate is measurably worse than before the programme started.

That outcome was fixed at approval. The programme had a baseline and a target and nothing in between, which gave it exactly one success condition, reachable only at the end. A Transition Architecture is the correction: a described, operable state of the estate between baseline and target that is a legitimate end point. TOGAF has produced these since version 9 in 2009, in Phase E (Opportunities and Solutions) and Phase F (Migration Planning) - the two phases organisations most reliably skip, because they turn an architecture into a sequence somebody has to fund.

Why it matters

The value of a long programme is dominated by what happens when it does not finish, and most do not finish as planned. If the chance of completing a 30-month programme intact is even 50%, a plan with no intermediate states has an expected value near half its business case - and the other half is negative, because a half-migrated estate costs more to run than either end state.

Each transition state is a point where the organisation can stop having banked something: a system switched off, a licence not renewed. Funding and sponsorship also turn over on roughly annual cycles, so a plan whose first deliverable lands after two of those cycles gets re-litigated by people who did not approve it, and the only defence is a completed increment they can see.

Implementation patterns

• Name the systems switched off at the end of each increment. This is the test that separates a transition architecture from a project phase: if nothing is decommissioned and no cost leaves the budget, it is work in progress with a date on it.
• Cap increments at two funding cycles. A plan that cannot be halted at a budget boundary gets halted anyway, at a worse moment.
• Budget the throwaway explicitly: temporary adapters, dual-running, a harness you delete. Typically 10 to 20% of programme cost, bought as optionality.
• Sequence to retire the most expensive thing first, so the earliest increment funds the later ones.

Industry example

Vendor support horizons force the increments whether you write them down or not. SAP announced in February 2020 a maintenance commitment for SAP S/4HANA to the end of 2040, and set mainstream maintenance for SAP Business Suite 7 core applications to the end of 2027 with optional extended maintenance to the end of 2030, at a premium on the existing maintenance basis.

Those three dates are a transition architecture: 2027 defines an increment that must be complete, 2030 is a priced option on overrunning it, and 2040 is the horizon the target has to be good for. Programmes that plan only to 2027 and treat it as one delivery discover in the final quarter that regression and cutover windows for a dozen integrated systems do not fit.

Failure scenarios

• A target with no intermediate states, approved because the business case reads best end to end, then cancelled mid-flight.
• Increments that are project phases in disguise - "complete the design", "build the platform" - none of which switches anything off.
• An increment whose value depends on a later one. A backbone live with 2 of 14 planned producers is a new system to operate with none of the duplication removed.
• No review date on the target, so a programme executes an 18-month-old document nobody would now approve.
• Dual-running with no end date, which turns temporary cost into permanent cost.

Trade-offs

Stated honestly: transition architectures make the programme longer and less likely to leave you worse off. If the organisation's history is that long programmes complete, the single-target plan is correct. The document to check is the list of programmes cancelled in the last five years.

When not to use it

For anything under about two quarters. A three-month change needs a plan, and inventing an intermediate architecture adds gates that convene after the work is done.

When increments cannot be made independently valuable. Some migrations are genuinely atomic - a core ledger cutover, a regulatory change with a fixed date - and faking increments fools the steering committee. Spend the effort on rollback and rehearsal, where the risk actually sits.

Interview question

Q: You inherit a 30-month, £14m programme at month four. It has an approved target, six workstreams and no intermediate states, and the sponsor is unlikely to be in post at month eighteen. What do you change, and what do you tell the steering committee you are giving up?

What a strong answer covers: re-cutting the sequence so the first increment switches something off within two to three quarters, and naming what · a budget line for throwaway adapters, priced as optionality · leaving the genuinely atomic workstreams alone · a stop-or-continue gate with pre-agreed evidence per increment · and the political layer, that the increment exists partly so a new sponsor inherits a result.

Quick check

Quiz: What distinguishes a transition architecture from a project phase? — Name the systems switched off and the cost that leaves the budget at the end of it. If the answer is none, it is a phase.

Flashcard: Why does a 30-month programme with no intermediate states have negative value if stopped halfway? — The half-migrated estate runs the old system, the new one and the integration surface of both.