The To-Be Architecture Is Fiction Until Something Has a Shutdown Date

Walk into almost any enterprise architecture review and you will find the same two artefacts: a dense as-is landscape diagram and a cleaner, bluer to-be diagram. What you will rarely find is a list of systems with committed shutdown dates and named owners. That absence is the whole problem. A to-be state that only adds capability is not a roadmap — it is a wish list with a budget attached. Business agility does not come from the speed at which you deploy new things. It comes from how quickly you can remove old ones.

Additive roadmaps quietly destroy agility

Every system you keep is a permanent tax on every future change: an integration to regression-test, a data model to reconcile, a security review to repeat, a vendor contract to renegotiate. Gartner's widely cited estimate that organisations would be spending around 40% of their IT budgets on servicing technical debt by 2025 is usually read as a cost story. It is really an agility story — that 40% is the share of your capacity that is unavailable for anything new.

The portfolio numbers make the point sharper. Zylo's 2025 SaaS Management Index put the average enterprise at hundreds of SaaS applications, with organisations routinely underestimating how many they actually run, alongside meaningful volumes of orphaned and unused licences. Nobody planned that landscape. It is the cumulative residue of years of roadmaps that specified what to build and stayed silent on what to retire.

The as-is model is a decision record, not a wall poster

As-is modelling gets dismissed as archaeology because teams produce it as a picture rather than as a set of decisions. A useful as-is captures, for every significant capability, four things: who owns it, what it costs fully loaded, what depends on it, and what the disposition decision is. Four dispositions are enough — invest, tolerate, migrate, retire — provided each carries a date.

• Invest: the capability is differentiating. Fund it properly and expect it to change often.
• Tolerate: it works, it is boring, and it is not worth touching this year. Re-review on a fixed date, not "eventually".
• Migrate: the target is named, the cutover window is in a plan, and the source system's shutdown date is the completion criterion — not the go-live of the replacement.
• Retire: a date, an owner, a data-retention answer, and a line in someone's objectives.

The discipline is simple and unpopular: a to-be roadmap is only approved when the retire and migrate columns are populated. If nothing switches off, the architecture has not changed — it has only grown.

Two-speed IT is a loan, so write the repayment terms

Two-speed operating models earned their reputation honestly. Separating a fast digital layer from a slower core lets teams ship customer-facing change without waiting on quarterly ERP release trains. The failure mode is not the split itself; it is that the split is treated as a permanent organisational fact rather than a time-boxed accommodation.

Treat it as debt with explicit terms. Every fast-lane component that bypasses core governance should carry a stated condition for rejoining: a data contract with the system of record, an ownership transfer, or a retirement date. Otherwise the fast lane becomes a second landscape with its own undocumented integrations — and you have doubled the surface area you now need to modernise. In SAP estates this shows up clearly, where side-by-side extensions accumulate faster than anyone audits them; our SAP and CX work consistently finds more shadow extension logic than the official architecture acknowledges.

Measure the practice on removal, not on documentation coverage

Gartner has noted that only a small minority of leaders believe they translate technology investment into measurable outcomes — and EA teams often reinforce that by reporting on model completeness and standards compliance. Those metrics reward description. Agility is better served by measuring: systems retired per year, integrations removed, average age of the oldest dependency in a critical value stream, and lead time for a change that crosses two or more domains. These numbers are uncomfortable precisely because they cannot be improved by drawing anything. We use them as the starting baseline in architecture engagements for exactly that reason.

The next few years will make removal capacity more valuable, not less. AI agents, in particular, expose landscape inconsistency instantly — they act on whatever duplicate system of record you left running. The organisations that move fastest will not be the ones with the most elegant target architecture. They will be the ones that have practised switching things off often enough that it has stopped being an event.