Utility Trees, Sensitivity Points, and Tradeoff Points

The Architecture Tradeoff Analysis Method exists because a design review organised around a slide deck produces opinions. Its structure replaces opinions with three artefacts: a ranked tree of scenarios, a walkthrough that names the design decisions each scenario depends on, and a list of risks derived from those decisions. The output is not a verdict on the architecture. It is a set of statements of the form “this scenario is at risk because this decision, and here is the decision that would fix it” — statements that can be argued with, priced, and assigned.

Building the tree from drivers downward

The root of the tree is utility, a placeholder for “whatever the system is for”. The second level is the quality attributes that the business drivers actually mention, not a standard list. A system whose revenue depends on a nightly settlement window gets availability and throughput at that level; a system whose cost is dominated by regulatory change gets modifiability. Attributes that nobody can connect to a business concern do not belong, however respectable they are.

The third level refines each attribute into the concerns that behave differently. Under performance, a refinement might be “latency under normal load” versus “throughput during the settlement window”, because a decision that helps one can hurt the other. Refinement stops when the next step would produce scenarios rather than categories.

Leaves are concrete scenarios, written in the six-field form that makes them checkable, as described in the scenario discussion. Each leaf carries two ratings, each on a three-point scale:

• Business importance: how much the scenario matters to the people paying for the system.
• Architectural difficulty: how hard the scenario is to satisfy, given the current or proposed design, in the assessment of the architects.

A leaf set of roughly fifteen to twenty-five is workable for a two-day exercise. Larger sets dilute the walkthrough, because the time available per scenario determines how deep the analysis goes. A hundred leaves is a requirements document with a tree drawn on it.

Leaf	Attribute	Importance	Difficulty
Settlement completes within the 02:00–04:00 window at 3x current volume	Performance	High	High
One zone lost during settlement; no duplicate postings	Availability	High	High
New tax jurisdiction added without changing the posting engine	Modifiability	High	Medium
Operator can replay a failed batch without a schema migration	Modifiability	Medium	Low
Audit log survives loss of the primary database	Security	Medium	Medium

The distribution in that table is the useful part. Two leaves are high on both axes, and those are the ones the walkthrough must reach. A tree where everything is high on both axes has not been rated; it has been agreed to.

One rating is not enough

The two ratings answer different questions and combining them into a single score destroys information. High importance and low difficulty is a scenario that will probably be satisfied by any competent design; it consumes walkthrough time but rarely produces findings. High importance and high difficulty is where the architecture is either right or wrong, and where a failed scenario costs the most. Low importance and high difficulty is a scenario that should be renegotiated rather than designed for, because it will absorb effort in proportion to its difficulty and return value in proportion to its importance.

The pairing also exposes a specific kind of dishonesty in reviews. Rating a scenario low importance after discovering that the design handles it badly is easy to do and hard to detect. Recording importance in a first pass with the stakeholders, before the architects discuss difficulty, keeps the two judgements independent.

The walkthrough, and what it produces

For each scenario, the evaluation group traces the stimulus through the design. The trace is a sequence of components and the decisions inside them that determine the response. From that trace come four classifications.

A sensitivity point is a decision that significantly affects the response measure of one quality attribute. The size of the connection pool is a sensitivity point for the throughput scenario: raising it changes the throughput measure and nothing else of consequence. Naming sensitivity points is the mechanism by which the walkthrough produces design knowledge rather than a list of components.

A tradeoff point is a sensitivity point for two or more attributes, where the effect is in different directions. The pool size is also a tradeoff point if a larger pool raises throughput while raising the p99 latency of interactive queries that share the database, because more concurrent statements contend for the same buffer pool. The tradeoff is real and the decision has to be made deliberately; the method’s contribution is to show that the two scenarios meet at that one parameter.

A risk is a decision that, on the evidence available, will not meet a high-importance scenario. A non-risk is a decision the group examined and found sound; recording non-risks matters because it prevents the same ground being re-covered in the next review.

The final artefact is a set of risk themes: risks grouped by the underlying cause rather than by the scenario that exposed them. Three risks that all trace to “the data model was designed for a single tenant” are one theme, and one theme is one decision to make.

Making a tradeoff point concrete

The settlement scenario and the interactive reporting scenario meet at the database. Settlement wants bulk writes: large batches, few round trips, aggressive parallelism. Reporting wants short reads with predictable latency: a query that waits behind a bulk load is a bad query. Both are high importance. The parameters that connect them are the write batch size, the concurrency of the settlement workers, and whether the two workloads share a database instance.

Naming the tradeoff point does not resolve it. Three resolutions exist and the method should force one to be chosen explicitly:

Separate the resource. A replica for reporting removes the contention at the cost of replication lag, which introduces a new scenario — how stale may a report be — with its own measure. The cost is infrastructure and a new failure mode during failover.

Schedule around it. Settlement runs in a window when reporting is not expected. This works when the window is genuinely quiet and fails when the business grows into a second time zone, which is a scenario worth writing down before the design is fixed.

Bound one side. Cap settlement concurrency so reporting latency stays inside its measure, accepting a longer settlement. This is the cheapest option and the one that quietly stops working as volume grows, since the cap that fit last year’s data does not fit this year’s.

The value of the utility tree here is that it makes the third option visible as a decision with a measure attached, rather than as a constant in a configuration file that nobody remembers choosing.

Cost, and the parts that do not reproduce

A full evaluation consumes the time of the architects and of the people who own the requirements for several days each, plus preparation. That cost buys a ranked set of scenarios that outlives the review and a written record of which decisions are load-bearing.

What it does not buy is repeatability. Two groups evaluating the same design produce different sensitivity points, because identifying them requires knowing what the design actually does under load, in failure, and during change. The ratings are judgements, not measurements; they are ordinal and coarse by design, and treating the numeric-looking output as data is a mistake.

What it also does not buy is an answer for scenarios nobody thought of. The tree is only as complete as the drivers that fed it, and the classic omission is the scenario the operators care about: the deploy that must be reversible, the certificate that expires, the dependency whose latency degrades rather than fails.

Typical failures of the exercise

Five failures recur.

The tree becomes a requirements catalogue. Every leaf is a scenario someone wants, and the exercise turns into prioritisation of features rather than analysis of a design.

Ratings collapse to high-high. Usually because the group cannot bear to rate anything low, which removes the ordering that makes the walkthrough tractable.

Sensitivity points are stated as components rather than decisions. “The message broker” is not a decision; the decision is whether delivery is at-least-once with idempotent consumers or exactly-once with a transactional outbox. The broker is where the decision lives.

The walkthrough stops at the happy path. Scenarios that involve degradation and recovery are the ones that produce findings, and they take longer per scenario, so they get cut when time runs short.

Risk themes are never converted into decisions. A theme without an owner and a date is a paragraph in a document that everyone agrees with and nobody acts on.

Where it feeds the rest

The tree’s outputs are inputs to the other techniques in this cluster. A sensitivity point that can be computed becomes a fitness function, since a decision that is known to govern a measure is exactly what a check should watch. A tradeoff point with two competing measures becomes a multi-criteria ranking problem, where the question shifts from “which attribute wins” to “which option is not dominated”, as treated in the Pareto analysis. And the risk themes usually name the parts of the system where change propagation is widest, which is what a structural analysis can confirm or deny.