Buying credibility: the early-value shortcut
Deliberately breaking the architecture to fund the programme — and how to make sure it gets thrown away.
The pattern above has a funding problem. Steps one and two cost a great deal and deliver nothing a user can see. On a long programme, that is a dangerous position: you are spending heavily on foundations while the business waits, and the first thing anyone asks in month six is what they have got for it.
What I have done, and would do again, is deliberately break the architecture early. Before the proper silver layer exists, build a direct bronze-to-gold transformation that serves the single highest-value business outcome you can identify. It is architecturally wrong. It bypasses the layer that gives the platform its integrity, it duplicates logic that silver will later own, and no architect would sign it off as a target state.
It is also, in my experience, the difference between a funded programme and a cancelled one.
Delivered early, it does three things. It puts a real, visibly better result in front of real users on the new platform. It converts an abstract migration business case into demonstrated value. And it gives the programme the credibility to secure funding for the much larger and much less visible work behind it.
The counter-risk is severe and you must plan for it from the start. If the shortcut delivers the most valuable outcome, you have just removed the business’s strongest reason to fund the rest. The sponsor who was desperate in month three is satisfied in month seven, and the remaining work — silver, reconciliation, the domain-by-domain rebuild, decommissioning — is all cost and no visible benefit. That is exactly the profile that gets cut in a budget round.
Two ways to manage it, and they are not equally good.
The tactical answer is to manage the narrative: keep the shortcut’s limitations visible, be candid about what it cannot do, resist pressure to extend it, and keep the next increment of value close enough to see. This works, and I have used it, but it depends entirely on the sponsor relationship and it fails the moment that sponsor changes.
The durable answer is to make disposal a condition of approval. When the shortcut is proposed, get it approved explicitly as time-boxed and disposable, with a named decommission trigger — the date, or the milestone, at which it is switched off — agreed at the same moment the funding for the whole programme is agreed. Write it into the design as a temporary component. Do not let it acquire dependencies: no downstream feeds, no second consumer group, no extension to cover an adjacent use case, however reasonable each individual request appears.
Because the failure mode here is not that the shortcut is a bad idea. It is that the shortcut is a good idea that becomes permanent. Once it has users, dependencies and a support arrangement, it stops being scaffolding and becomes a second architecture — one that bypasses your integration layer, in production, with nobody willing to fund its removal. You will have solved your funding problem by creating a smaller version of the platform you were migrating away from.
Build it knowing you are going to throw it away, and make sure everyone who approves it knows that too.