Trade-Off Analysis

"Every architecture is the result of trade-offs, whether conscious or not." — Mark Richards

TL;DR

Performs structured trade-off analysis using weighted scoring matrices, decision matrices, and ATAM to make explicit, defensible architectural and technology decisions. Use this skill when facing architectural trade-offs (consistency vs. availability, flexibility vs. simplicity), choosing between technologies, or when the team disagrees on approach. [EXPLICIT]

Procedure

Step 1: Discover

• Define the decision to be made and the options under consideration
• Identify quality attributes at stake (performance, security, maintainability, cost)
• Gather constraints: budget, timeline, team skills, existing commitments
• Collect stakeholder priorities: which quality attributes matter most

Step 2: Analyze

• Apply ATAM method:
  1. Present the business drivers and architectural approaches
  2. Identify architectural approaches and their associated quality attributes
  3. Generate quality attribute scenarios (stimulus, response, measure)
  4. Analyze approaches against scenarios to identify sensitivity points and trade-offs
• Build a weighted decision matrix with stakeholder-validated weights
• Identify risks: where an architectural decision could cause problems
• Find sensitivity points: where small changes significantly impact quality attributes

Step 3: Execute

• Produce a decision matrix with alternatives scored against weighted criteria
• Document trade-off pairs: "We chose X over Y because Z quality attribute is more critical"
• Write an Architecture Decision Record (ADR) capturing the analysis
• Create a risk catalog from identified sensitivity points and trade-offs
• Provide a recommendation with confidence level and conditions for revisiting

Step 4: Validate

• Verify weights reflect actual stakeholder priorities, not assumed ones
• Confirm scoring is evidence-based with supporting rationale
• Check that the analysis reveals genuine trade-offs (not a predetermined conclusion)
• Review sensitivity: would different weights change the recommendation?

Decision under uncertainty (quantitative)

When scores/costs/durations are uncertain, don't decide on point estimates — model the uncertainty. [DOC]

• Three-point / PERT: for each uncertain input use optimistic/most-likely/pessimistic; expected = (O + 4M + P)/6, with a spread. [DOC]
• Expected Monetary Value (EMV): for risky options, EMV = Σ(probability × outcome); compare options by EMV, not best-case. [DOC]
• Monte Carlo: when inputs interact, sample the input distributions N times → a distribution of outcomes (P50/P80), not a single number. Decide on the P80, not the mean, for commitments. [DOC]
• Sensitivity: rank which input most moves the result (tornado); invest discovery effort there first. [DOC]
• A recommendation whose ranking flips under plausible weight/estimate changes is not robust — flag it. [INFERENCE]

Quality Criteria

• Decision matrix includes at least 3 alternatives with weighted criteria
• Trade-off pairs are explicitly documented (chose X over Y because...)
• ADR captures context, decision, and consequences
• Sensitivity analysis validates robustness of recommendation
• Evidence tags applied to all claims

Anti-Patterns

• False trade-off: presenting options as mutually exclusive when they are not
• Analysis paralysis: over-analyzing when the options are close enough
• Confirmation bias: scoring to justify a predetermined decision

Related Skills

• scenario-analysis — complementary evaluation using Tree-of-Thought
• system-architecture — trade-offs drive architectural decisions
• feasibility-validation — validates that chosen trade-offs are feasible

Usage

Example invocations:

• "/trade-off-analysis" — Run the full trade off analysis workflow
• "trade off analysis on this project" — Apply to current context

Assumptions & Limits

• Assumes access to project artifacts (code, docs, configs) [EXPLICIT]
• Requires English-language output unless otherwise specified [EXPLICIT]
• Does not replace domain expert judgment for final decisions [EXPLICIT]

Edge Cases

Packet

Capas del packet, cargables bajo demanda (disciplina ICM: una capa por vez, nunca todas juntas): knowledge/ cuerpo de conocimiento · prompts/ prompts listos · examples/ salida de ejemplo · agents/ subagentes del packet · templates/ plantilla de output.