An organisation needs a repeatable method for evaluating architectural trade-offs. What should the method contain, and what makes such methods fail?
Show the full answer Hide the answer
What the method should contain
1. Quality attribute scenarios, not adjectives. "Available" is not analysable. Stimulus → environment →
response → measure is: "when a region fails during peak load, the system continues serving reads within 300 ms
at p99 and resumes writes within 15 minutes".
Without this step, the comparison is between vague preferences.
2. Criteria agreed before options are compared. Which attributes matter, and in what order, given the business context. Half of stalled architectural debates end here, because participants are optimising for different things and neither has said so.
3. Each option's position on each criterion, stated concretely — with numbers where numbers exist and an honest range where they do not.
4. Explicit identification of which criterion dominates, and why. This is the architectural judgement and where the value is; usually one criterion matters far more than the others in context, and naming it collapses the decision.
5. Sensitivity analysis. Which assumption, if wrong by a factor of two, changes the answer? That identifies what to measure early and what to design to change cheaply.
6. A recommendation with visible reasoning, so it can be challenged on grounds rather than on authority.
What makes these methods fail
- Numeric weighting that manufactures precision. Scoring options against weighted criteria produces a number that looks objective and is dominated by the weights, which were chosen by whoever wanted a particular outcome.
- Too many criteria, so nothing dominates and the result is an average that reflects no coherent position.
- Criteria chosen after seeing the options, which is rationalisation.
- No cost of the do-nothing option, so deferral appears free.
- Applied to reversible decisions, where the analysis costs more than the mistake would.
The proportionality rule
Match the method to the reversibility. A decision you can undo in a sprint deserves a decision and a measurement. One that would take a year to reverse deserves the full analysis — and applying equal effort to both is the dominant cause of slow decision-making.