What distinguishes strong trade-off analysis from weak analysis in practice?
Show the full answer Hide the answer
What weak analysis looks like
- Listing pros and cons with no weighting, leaving the reader to do the work.
- "It depends" with no statement of what it depends on.
- False balance, presenting options as equally weighted when one is clearly better in context — which is abdication rather than neutrality.
- Criteria chosen after seeing the options, which is rationalisation.
- A hidden recommendation framed so only one option appears viable, which is detected and costs the trust that makes future recommendations acceptable.
What strong analysis looks like
1. Criteria named first, and ranked. Which two or three attributes actually decide this, given the business context. Naming them frequently collapses the decision, because one usually dominates.
2. Each option's position stated concretely. "Six weeks and 40% more to run" rather than "faster but more expensive".
3. The dominant criterion identified, with reasoning. This is the architectural judgement and where the value is.
4. A recommendation, with the reasoning visible, so it can be challenged on grounds rather than on authority.
5. What would change the recommendation. "If we expect to enter three more markets next year, the other option becomes clearly right." This is what lets a stakeholder who knows something you do not correct the analysis.
6. The cost of the do-nothing option, so deferral is visibly a choice.
The skill underneath
Recognising which dimension matters in this context. The same two options can have opposite answers at different companies, because the constraint differs — one is bounded by cost, another by time to market, another by regulatory exposure.
An architect who applies the same ranking everywhere is applying a preference rather than analysis.
The proportionality rule
Match the depth to reversibility. A decision you can undo in a sprint deserves a decision and a measurement. Extensive analysis of a reversible choice spends more than the mistake would cost — and is a common cause of slow architecture practice.