Target-State Decay
also called Architecture Plan Decay, Target Architecture Drift
The rate at which an approved target architecture stops being correct - mostly for organisational reasons rather than technical ones - and the reason a plan with no review date turns into a set of case-by-case exceptions.
A target-state architecture is signed off with nine named components, a three-year sequence and a funded programme. Twenty months later two of the nine products have been discontinued by their vendors, the team named as owner of the integration layer has been reorganised out of existence, and the event backbone has been in production for a year with two of its fourteen planned producers. The document is roughly 70% right, and nobody knows which 70%.
That is target-state decay: not the failure of a plan but its loss of fitness while it retains full authority. The damage comes from the part that is still correct, because it lends credibility to the part that is not. A team that queries one component is told the architecture is approved.
The decay is mostly organisational. Products get discontinued, but the faster causes are that owning teams disappear, build-versus-buy answers reverse on a licence price, and adoption assumptions fail quietly. Technology reviews catch none of those.
Why it matters
Half-migration costs more than either end state. A backbone at 2 of 14 producers means the estate maintains two integration paths — two sets of credentials, two monitoring approaches, a schema change made twice — while programme reporting shows the component as delivered because it is running.
The second-order cost outlasts the programme: each point-to-point integration approved as an exception is individually reasonable, and collectively they teach the organisation that architecture documents are things you route around. A planning figure: expect 15 to 30% of a nine-component target state to be wrong at 18 to 24 months, weighted towards ownership and adoption rather than technology choice.
Implementation patterns
- A review date on the artefact itself — 6 months for a fast-moving estate, 12 for a stable one.
- One recorded assumption per component with the event that breaks it: the vendor's support end date, a licence renewal, the owning team's existence. That turns an annual re-plan into a trigger list anyone can watch.
- Adoption thresholds as funding gates. Release the next tranche at 6 of 14 producers rather than at technical go-live, because a platform below its threshold is a liability rather than partial progress.
- Exceptions counted against the component they bypass, so the second or third raises a decision instead of a pattern.
- Withdrawal as a first-class review outcome. Amending three of nine components takes a week; a full re-plan takes a quarter and produces the same decay with a newer date.
Industry example
The Open Group's TOGAF names the mechanism: Phase H, Architecture Change Management, monitors technology and business change and raises a new Request for Architecture Work when the architecture no longer fits, with Requirements Management running continuously at the centre of the ADM. It is also the phase organisations reliably skip, because Phases A to F each produce a deliverable somebody asked for and Phase H produces none.
Failure scenarios
- Silent local substitution. Teams replace discontinued components case by case without amending the document, so the estate and the architecture diverge in ways recorded nowhere.
- The ownerless component. Scope shrinks to whatever each of three sharing teams needed, and the component meant to unify the estate becomes three partial implementations, which is how a programme spends its final year funding two paths.
Trade-offs
| Choose | Gains | Pays |
|---|---|---|
| Fixed multi-year target state | Fundable and easy to align behind | Decay with full authority and exceptions instead of amendments |
| Reviewed target state with triggers | Corrections cost a week and stay visible | Governance time and apparent instability to sponsors |
| Rolling six-month horizon | Nothing to decay | No case for investment that repays over years |
When not to use it
Where a regulator, a board or a contract requires a fixed committed plan, re-opening the target state has a cost the engineering argument does not see: amend within the commitment and be explicit about what changed. Equally, do not re-open a plan four months from its end for like-for-like substitutions — a month of governance to change three boxes is worse than the decay. The test is whether a component's owner or adoption path changed, not whether a product name did.
Interview question
Q: You inherit a programme executing against an 18-month-old target state and believe three of its nine components are wrong. The programme is two thirds through its funding and the sponsor presents progress to the board next month. What do you do?
What a strong answer covers: separating the three by consequence — substitution, ownerless, below adoption threshold — because each needs a different action; going to the sponsor with an amendment and a number rather than a warning; using the dual-running cost as the argument because that is the money a board recognises; and adding the review date and trigger list so the next divergence is a fortnight's correction.
Quick check
Quiz: Why is a platform in production with 2 of its 14 planned producers worse than one not yet built? Because the estate now maintains both integration paths, and the half-migration costs more than either end state while reporting as delivered.
Flashcard: What causes most target-state decay? — Organisational change, not technology: owning teams disappear, build-versus-buy answers reverse, adoption assumptions fail quietly. Technology reviews catch none of those.