An architect must justify a two-year modernisation programme with no new customer-facing features. What makes such a business case credible?
Show the full answer Hide the answer
Why these cases usually fail
They are argued on technical virtue — the system is old, the technology is unsupported, the code is difficult — which is true and does not compete against a feature roadmap. Nobody funds tidiness.
And they ask for two years of investment before any return, which is the hardest possible funding shape.
What makes it credible
1. Quantify the current cost of not acting. In business terms, with evidence:
- Incident cost. Frequency, duration, revenue impact, engineering time consumed.
- Change cost. Lead time for a typical change now versus a comparable modern system, multiplied by change volume. "Every change takes six weeks instead of one" is a number.
- Opportunity cost. Features not built because the system cannot support them — with specific examples the business asked for and was refused.
- Risk exposure. Unsupported components, unpatchable vulnerabilities, key-person dependency, and the cost of the failure mode if realised.
- Direct costs. Licences, specialist contractors, hardware nobody else runs.
2. Deliver value incrementally. A strangler approach where each slice produces a benefit — a capability that becomes changeable, an incident class eliminated, a cost removed — is fundable in a way that a two-year rebuild is not. It also de-risks the programme, since a slice that fails is a slice, not the programme.
3. Name what is not in scope. Modernisation programmes accumulate every deferred wish, which is the second-system effect and the most common way they die. An explicit non-goals section, reviewed as seriously as the goals, is what keeps it fundable.
4. Tie slices to business events. A regulatory deadline, a market entry, a capacity ceiling, a product capability the business wants. Each gives a slice a sponsor and a date.
5. Show a credible end state and the cost of stopping halfway. Perpetual coexistence — operating both systems forever — is the characteristic failure, so the plan must include decommissioning as a deliverable with a date and an owner.
The framing that works
Not "the system is old" but "here is what it costs us each quarter, here is the first slice, here is what that slice returns, and here is how we know it worked."
That converts the argument from an aesthetic one into an investment one, and investment arguments are the only kind that get funded against a roadmap.