A target-state architecture was signed off 18 months ago - 9 named platform components, a 3-year sequence, £11m funded. Since then 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 live for a year with 2 of its 14 planned producers. The programme continues to execute against the original document. What happens over the next 12 months?
Show the full answer Hide the answer
Month by month, what happens
Months 1 to 3. Delivery continues, because the funded plan is the path of least resistance. The two discontinued products are handled locally: one team picks a replacement without changing the document, another stays on the old version because it still works. The architecture and the estate now differ in ways recorded nowhere.
Months 4 to 8. The integration layer with no owning team becomes a coordination task shared by three teams, which means it is nobody's. Its scope shrinks to whatever each team needed for its own use case. The event backbone stays at 2 or 3 producers, so every integration that was supposed to move onto it is instead built point-to-point as an exception — each exception individually reasonable and approved.
Months 9 to 12. The backbone is now a second integration path carrying under 20% of the traffic, and the estate maintains both: two sets of credentials, two monitoring approaches, and a schema change made twice. Programme reporting still shows it as delivered, because it is running. The cost is not the failed component, it is the dual-running the half-migration created.
Where it amplifies
In the reporting, and in the next funding round. A target state that is 70% right is defended as a whole, so the 30% that is wrong is where teams learn that architecture documents are things you route around. The second-order effect outlasts the programme: the next target state, however good, starts with a credibility discount, and the exceptions granted this year become the precedent for the next.
What the teams see
Not a failure. They see a plan that answers questions nobody is asking any more, a component whose owner cannot be found, and permission - granted case by case - to do the sensible local thing. That is why this decays quietly rather than blowing up: every individual decision along the path is correct.
What stops it
- A review date on the target state and a standing trigger list. A discontinued product, a vanished owner, or an adoption number below plan raises an amendment, not a workaround. Amending three of nine components is a week of work; discovering it two years later is a programme.
- Adoption thresholds as funding gates. Release the next tranche when the backbone has, say, 6 of 14 producers, not when it is technically live. A platform at 2 of 14 producers is not 14% delivered, it is a liability, because the estate now pays for two paths.
- Every step reversible on its own. If cancelling after step 2 leaves the organisation better off than not starting, the sequence is sound. If it leaves two integration paths, the sequence was a single bet dressed as a roadmap.
- An owner per component, re-confirmed at each review. A component whose owner no longer exists should be withdrawn from the target state that week.
What would have to be true for it to self-heal
That the exception path reports upward. If each point-to-point integration granted as an exception were counted against the backbone's adoption number, the second or third exception would have triggered a decision rather than a pattern. Decay is not caused by the world changing; it is caused by the change being invisible to the people holding the plan.
When this is the wrong diagnosis
When the remaining horizon is short and the substitutions are cosmetic. If the programme finishes in four months and the two discontinued products have drop-in replacements with the same interface, re-opening the target state costs a month of governance to change three boxes on a diagram. Amend the document and keep going. The test is whether any component's owner or adoption path changed, not whether a product name did: a vendor swap is an amendment, an ownerless component and a platform at 2 of 14 producers are decisions.