Business Cases

Definition

A business case sets out the problem, the options, the recommended option, its costs, its benefits and its risks, in terms the funder can evaluate.

What architects contribute

• Realistic cost, including run cost and the engineering time nobody counts.
• Options, genuinely different ones — not one real proposal and two straw men, which is transparent and undermines the whole document.
• Risk, stated honestly with mitigations.
• The cost of doing nothing, which is the most under-used argument. Growing incident load, rising change cost, an approaching capacity limit, a support contract expiring.
• Option value. What this enables later, and what it forecloses.

Making the benefits credible

The weakest business cases claim large benefits with no mechanism. The strongest state the causal chain and the assumption:

"Reducing checkout latency from 1.2 s to 400 ms. Historical data across our own experiments suggests roughly a 1% conversion improvement per 100 ms in this range. At current volume that is approximately £X per year. The assumption is that our relationship matches the historical pattern, which we will validate with a controlled experiment in the first month."

Stating the assumption and the validation method is what makes an estimate credible. Claiming precision you do not have is what makes it disbelieved.

Prefer cost avoidance and risk reduction where revenue attribution is genuinely uncertain — they are easier to defend and harder to dispute.

The technical debt case specifically

Argue it in delivery outcomes, never in code quality:

"The last four changes in this area took nine days each; comparable changes elsewhere take two. That difference is about three weeks of engineering time per quarter and it is growing. Two sprints of work brings it back in line, after which adding a payment method takes a day rather than three weeks."

Evidence, trend, and an outcome expressed as capability. "The code is messy" is true, unfalsifiable from the funder's position, and loses to a feature every time.

Failure scenarios

• Benefits with no mechanism, so the number is disbelieved.
• Costs omitting run effort, so the case is later shown to have been wrong.
• Straw-man options.
• No cost of inaction, so doing nothing looks free.
• Written once and never revisited against what actually happened, which is how the next case loses credibility.

Interview question

"Write the business case for replacing a component that works but is expensive to change."