architecture-trade-off-analysislisted

# Architecture Trade-off Analysis Determine which feasible option best fits the stated conditions, what it costs, and how sensitive that conclusion is to uncertain facts or stakeholder preferences. The result may be a recommendation, a conditional choice, or an explicit finding that evidence does not yet support selection. Always give an actionable next step; never manufacture a winner. ## Workflow 1. **Frame the decision.** Identify the affected system/operation, decision owner, deadline, current implementation and credible alternatives. Obtain requirements and constraints, workload/change/failure scenarios, relevant deployment/data ownership, and the evidence available. Separate measured facts, forecasts, assumptions and preferences. Ask only for missing inputs that can change the conclusion; analyze known constraints while waiting. 2. **Choose proportionate effort.** Use the modes below. Reversal cost depends on data, consumers, migration and commitments after adoption, not team size or a technology name. A small team can face a consequential decision; a clear, dominant feasible option does not need an invented trade-off. 3. **Make the options comparable.** Describe complete alternatives for the same boundary, required behavior and operating conditions. Include credible status quo, staged/hybrid and defer options where relevant; record material exclusions and their reasons. Components that can coexist are not necessarily rival architectures