In architecture evaluation, what is the difference between a 'sensitivity point' and a 'trade-off point', and how do you find them in a design?

## Where the vocabulary comes from **ATAM** — the Architecture Trade-off Analysis Method, from the Software Engineering Institute — is a structured, scenario-based review that asks whether a proposed architecture satisfies its quality-attribute goals, and where those goals conflict. Its output vocabulary is worth knowing even if you never run the full ceremony: - **Quality-attribute scenario:** a testable statement in the form *source → stimulus → environment → artefact → response → response measure*. Example: "A logged-in user (source) submits checkout (stimulus) during peak seasonal load (environment) to the order service (artefact); the order is accepted (response) with p99 under 300 ms (measure)." - **Utility tree:** a hierarchy — utility → quality attributes → refinements → concrete scenarios — with each leaf rated for *business importance* and *technical difficulty* (typically High/Medium/Low each). Only the high-importance leaves get analysed. - **Architectural approach/decision:** a chosen tactic — replication, quorum sizes, layering, a queue, a cache, TLS termination point. - **Sensitivity point:** a decision whose variation causes a **large change in one** attribute's response measure. - **Trade-off point:** a decision that is a sensitivity point for **two or more** attributes that move in **opposite** directions. - **Risk:** a decision that may prevent a scenario from being met. **Non-risk:** a decision that is fine *given stated assumptions* (record the assumptions — they expire). **Risk theme:** a pattern across several risks pointing at a systemic gap (e.g. "no story for degraded operation anywhere"). ## Concrete examples | Decision knob | Sensitive for | Trade-off? | |---|---|---| | Replication factor N | Durability, availability, cost, write latency | Yes — durability and availability up, cost and write latency up | | Write quorum W (with R + W > N) | Consistency, write latency, write availability | Yes — stronger reads, slower and more fragile writes | | Cache TTL | Read latency, data freshness, origin load | Yes — longer TTL is faster and cheaper but staler | | TLS termination at edge vs at each service | In-cluster confidentiality, latency, CPU cost, operational complexity | Yes | | Thread-pool or connection-pool size | Throughput, tail latency, memory, downstream pressure | Yes — a bigger pool can raise throughput while worsening queueing at the dependency | | Choice of logging library | Almost nothing at architecture level | No — not even a sensitivity point; do not spend review time here | | Batch window size in a pipeline | Freshness, cost per record, backpressure | Yes | The 'no' row matters: much design debate is spent on decisions that are sensitivity points for *nothing*. Identifying that is as valuable as finding a trade-off point. ## How to find them 1. **Build the utility tree** with stakeholders; rate leaves by business importance and technical risk. This bounds the analysis — you analyse the (High, High) leaves, not everything. 2. **Walk the top scenarios through the design.** For each, trace the request or change path and list every decision it depends on. 3. **Cross-index decisions against scenarios.** A decision touched by many scenarios is a sensitivity hotspot; a decision touched by scenarios whose desired responses conflict is a **trade-off point**. 4. **Quantify where you can.** "W = 2 costs about +8 ms p99 versus W = 1" is far more useful than "slower". Prototype or benchmark exactly at the trade-off points — that is where measurement pays for itself. 5. **Record risks, non-risks and assumptions**, then group risks into themes and map each theme to the business driver it endangers. ## Why it matters practically Trade-off points are where the architecture's competing goals collide, so they deserve disproportionate attention: they are the right places to spike, benchmark, expose a configuration knob, write an ADR, and add monitoring so you notice when the balance drifts. They are also the natural agenda for a stakeholder conversation, because they are exactly the decisions that cannot be made on technical grounds alone — someone must say which attribute wins. You do not need the full ATAM ceremony (multiple workshops, many participants) to use this: a lightweight version — five prioritised scenarios walked through the design in an afternoon — captures most of the value.