Pattern 2.7
Predict Before You Draw
Before the architecture workshop, write down what the money flows say the architecture should look like, keep it private, and compare it with what the group draws.
In This Context
A software architecture is a fossil record of past money flows. Per-customer code forks, duplicated toolchains in each business unit, and services split across separate networks for chargeback can all be traced to funding decisions. By the time the patron, organization, and work maps are done, much of the architecture should be predictable without any knowledge of the technology. But if the predictions are shared before the group draws, the group will either confirm them out of politeness or argue with them out of pride, and the exercise teaches nothing.
- Vague predictions (“there will be some technical debt”) can’t be tested.
- Where a prediction fails, something other than money is at work: history, a powerful individual, a genuine technical constraint, or culture.
Therefore
Using the earlier maps, write a handful of specific predictions that could turn out to be wrong, such as “each business unit will run its own CI/CD pipeline, because each funds its own engineers.” Keep them to yourself until the group has drawn the system, then reveal them and go through each one together.
Consequently
- Where the predictions hold, the architecture is explained by the money flows, and changing it will mean changing those flows.
- Where they fail, the group has found something else to investigate.
Seen In
Chapter 14, “Predict Before You Draw”, and Chapter 14, figure “Jan’s slice of CapitalMesh at the end of the architecture workshop, annotated with owners, funders, constraints, and predictions”.