Funding Model Coupling

An organisation funds engineering through annual project business cases: each initiative gets a budget, a team assembled for it, and a closure date. The architecture team sees the same four problems in every review — unowned systems, integration nobody built, debt taken deliberately, and platform capabilities smuggled into unrelated cases.

None of these is a discipline failure. They are the predictable output of the funding model, and Conway's 1968 observation covers the structural half: a system mirrors the communication structure that produced it, so temporary teams around temporary scopes produce temporary systems with permanent lifespans.

Why it matters

Architects spend enormous effort on consequences while the cause is a template in the finance function. A single line in a business-case template — a named funded owner with a run budget for the following year — changes the behaviour of every project in the portfolio, which no amount of design review can do.

The arithmetic is also stark. Twenty projects closing a year with no funded owner adds twenty systems to the unowned register annually, against a support function that grows by perhaps two people. In estates where this has run for five years, the run-cost line typically climbs 10% to 15% a year while the change budget is flat. The run-cost line then grows faster than the change budget, and nobody can attribute it to the projects that caused it.

Implementation patterns

• Make the closure gate require a named funded owner with a run budget for the next year. The cheapest change with real effect, because it does not alter the funding model at all — one line in a template reaches 20 projects a year.
• Carry a run-cost estimate in every business case, so initiatives are compared on the liability they create as well as the value they deliver.
• Fund platform and integration as standing products even where everything else stays project-funded. These are precisely the capabilities whose benefits appear in other people's cases, so they are never built on their own merits.
• Keep long-lived teams long-lived and let projects pass through them. This does the most and is the hardest to obtain, because it breaks the one-to-one mapping between a budget and a team that makes project funding legible to finance.
• Publish the unowned-systems register with its growth rate. A number that rises every quarter is the argument; an anecdote about an unowned system is not.
• Name the integration owner in the business case of whichever project touches the seam, because the seams between cases are where no budget lives.

Industry example

The pattern is documented from both directions. The shift from project to product funding is the central argument of Mik Kersten's Project to Product (2018), which frames the problem as a mismatch between funding units and value streams. In the other direction, capitalisation rules in many regulated and listed businesses make project funding the only model the accounting policy supports, which is why "move to product funding" fails as advice: it asks the architecture function to win an argument that belongs to the finance function. The changes that succeed are the ones that leave the funding model intact and alter what a business case must contain.

Failure scenarios

• Ownership by last touch. The project disbands, and the system belongs to whoever most recently deployed it, which is nobody's plan and shows up during the first security patch.
• Integration built twice, once badly by each side, because it sat between two cases.
• Debt as the correct local choice. A project judged on scope by a date is rationally indifferent to maintenance after closure.
• Platform work funded by stealth, so shared capabilities are shaped by whichever project could afford them rather than by what the estate needs.
• The cross-estate deadline, where a vendor's end of support or a regulatory date must be delivered through dozens of unfunded conversations with teams that no longer exist.

Trade-offs

Project funding genuinely buys a defensible allocation, a named sponsor per pound, a stop decision at a gate, and a comparison between competing initiatives. An argument that ignores those loses in the room where the decision is made. Product funding buys ownership continuity and removes the seam problem, and pays with a weaker stop decision, less visible attribution of spend to outcome, and a harder conversation with auditors about what was capitalised. Neither is free, and the realistic position is usually a hybrid: standing teams for permanent capabilities, projects for finite work.

When not to use it

For genuinely finite work — a data-centre exit, a regulatory remediation, a migration with a described end state — the project is the correct shape and a standing team would be make-work. The failure is not project funding; it is project funding applied to permanent things. The test is whether someone can describe the finish line. If they cannot, funding it as a project guarantees an unowned system at the end, and that is the sentence to use in the business-case review.

Interview question

Q: You are the lead architect in an organisation where every system is built by a project team that disbands at closure. You cannot change how the company budgets. What do you change instead, and how would you demonstrate within two quarters that it worked?

What a strong answer covers: accepting the constraint rather than arguing for product funding, and naming what project funding legitimately buys · the closure-gate change as the cheapest edit with real effect · run-cost estimates in business cases so liability enters the comparison · standing funding for platform and integration specifically, with the reason stated in terms of whose business case the benefit lands in · the unowned-systems register and its growth rate as the measurement · and a two-quarter demonstration based on that rate flattening rather than on anecdote.

Quick check

Quiz: Why is integration between two projects systematically under-built? — Because each business case funds only what it named, and the seam lies between two cases, so it belongs to no budget and is built by whichever project runs last.

Flashcard: What is the single cheapest change to a project-funded portfolio's architecture outcomes? — Require a named funded owner with a run budget at the closure gate, which changes behaviour across the portfolio without altering the funding model.