Trade-Off Analysis

Every architecture decision has a cost. The architect who does not name the cost is not making a decision — they are making a bet. And bets that nobody tracks have a way of coming due at the worst possible time. Trade-off analysis is the discipline of making the cost explicit before you commit to the design.

Consider a common decision: build a custom integration or use an off-the-shelf connector? The custom build gives you control, flexibility, and exact-fit performance. The cost: development time, maintenance burden, and a dependency on engineers who understand the custom code. The off-the-shelf connector gives you speed and reduced maintenance. The cost: vendor lock-in, feature constraints, and behavior you cannot control when it matters most. Neither choice is wrong. Both choices have costs. The architect's job is to name them so the stakeholder can decide which costs they prefer to pay.

1. Name the Options For every architectural decision, identify at least two viable paths. If you can only see one option, you have not looked hard enough. The architecture review that presents a single recommendation without alternatives is a pitch, not an analysis.
2. Name the Costs For each option, list what you gain and what you pay. Be specific. "More flexible" is not a cost analysis. "Custom code requires 80 hours of development and ongoing maintenance by a team that understands the integration surface" — that is a cost analysis.
3. Name the Reversibility Some decisions are easy to reverse. Others are load-bearing — once you commit, changing course is a major project. Identify which category each decision falls into. Spend proportionally more time on the irreversible ones.
4. Recommend with Rationale After naming options, costs, and reversibility, make a recommendation. State why this option, given these constraints, for this client. The recommendation should be defensible, not just preferable. If you cannot defend it in a design review, it is not ready.