The Utility Tree

Overview

You can now write requirements that can be tested. You cannot satisfy all of them equally — availability competes with cost, accuracy competes with latency, and every one of them competes for the same scarce engineering capacity.

A Utility Tree is how you decide which ones the architecture serves first, in a form you can show to the people who will be disappointed. It comes from the same SEI lineage as the six-part scenario — Bass, Clements and Kazman — where it is the step that feeds ATAM, the structured evaluation method this topic’s technique is lifted from.

What the tree is

A top-down decomposition. The root is “utility” — the overall goodness of the system. Beneath it sit the quality attributes that matter for this initiative. Beneath each of those sit refinements, and at the leaves sit the concrete scenarios from the previous topic.

graph LR
  U["Utility"] --> AQ["Answer quality"]
  U --> UC["Unit cost"]
  U --> CO["Compliance"]
  U --> MO["Modifiability"]
  AQ --> AQ1["Correct on the golden set,<br/>docs changed this week<br/><b>(H, H)</b>"]
  AQ --> AQ2["Declines rather than<br/>guessing when unsure<br/><b>(H, H)</b>"]
  UC --> UC1["Blended cost per interaction<br/>stays under the ceiling at peak<br/><b>(H, H)</b>"]
  CO --> CO1["No regulated data leaves<br/>its region, ever<br/><b>(H, L)</b>"]
  MO --> MO1["Swap model provider<br/>in under a sprint<br/><b>(L, H)</b>"]

  classDef root fill:#3F3F3F,stroke:#1F1F1F,stroke-width:2px,color:#ffffff
  classDef qa fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  classDef hh fill:#D9695B,stroke:#B4483A,stroke-width:2px,color:#ffffff
  classDef hl fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  classDef low fill:#D8D3CB,stroke:#B8B2A8,stroke-width:2px,color:#3F3F3F
  class U root
  class AQ,UC,CO,MO qa
  class AQ1,AQ2,UC1 hh
  class CO1 hl
  class MO1 low

A tree fragment. The three terracotta leaves are where the design work goes; the drained one is high-risk and low-value, which makes it a trap rather than a requirement.

Two properties make the tree useful rather than decorative. It is complete by construction — if a quality attribute has no leaves, you have just discovered a gap. And it is prioritised at the leaves, not at the top, so nobody has to rank “security” against “performance” in the abstract, which is an argument with no answer.

Two axes, not one

Each leaf gets a pair of ratings, conventionally High / Medium / Low.

Business value — how much the business cares. This is not yours to decide. It belongs to whoever owns the driver, and the ratings should be traceable to the drivers in your business-value brief.

Architectural risk — how uncertain you are that the architecture will achieve it. This is yours.

The second axis is routinely misread as “difficulty”, and the distinction matters. A scenario can be hard to implement and carry almost no architectural risk, because everyone knows exactly how it will be done. Another can be easy to implement and carry high risk, because the whole structure hinges on an assumption nobody has tested. Risk is about how much the design depends on it and how little you know.

What each quadrant tells you to do

Value	Risk	What it means	What you do
High	High	The design hinges on something uncertain	Start here. Prototype, measure, decide early
High	Low	Important and well understood	Keep it, specify it, stop agonising over it
Low	High	A risky thing nobody is asking for	Cut it, or demote it to “later”
Low	Low	Fine	Build it when convenient; it earns no design attention

The third row is the one that justifies the whole exercise. Low value with high risk is where architectural self-indulgence lives — the elegant generality, the premature abstraction, the provider-swap capability nobody asked for. Without the two-axis rating it looks like diligence. With it, it looks like what it is.

Using the tree to say no

Refusal is most of this job, and it goes badly when it sounds like personal preference.

The tree converts it into arithmetic someone else signed. “This is rated low value — by your own sponsor — and high risk. Here is what it displaces.” That is a very different conversation from “I don’t think we should do that.”

A second use, less obvious: the tree makes omissions visible. A quality attribute with no leaves under it is either genuinely irrelevant to this initiative or a hole in the elicitation. Both are worth knowing, and only the shape of the tree shows you which.

Who rates what

The division of labour is the point, and it is also a trust mechanism.

Stakeholders rate value. They are better at it than you, it is their call, and asking them makes the tree theirs rather than yours. You rate risk, because it is a technical judgement and because being wrong about it is your accountability.

Doing this in a room, on a wall, with the people who disagree, is also the cheapest architecture review available. The method that formalises it is ATAM — the Architecture Tradeoff Analysis Method, a structured evaluation in which the tree decides which scenarios get analysed against a candidate design. You do not need the full method to get most of the benefit; you need the tree and the ratings.

A tree that rules things out

Four leaves, rated with the drivers from the brief:

Scenario	Value	Risk	Why
Blended cost per handled ticket ≤ $3.00 at 18,000/month	H	H	It is the CFO’s driver and the whole business case. High risk because nobody has measured real cost per interaction yet
≥ 90% correct on a 300-question golden set	H	H	Maya Ortiz’s deflection target depends on it; the 2023 routing failure means a quiet decline would end the project
No regulated customer data leaves its region	H	L	Lena Fischer can block outright, so value is maximal — but the risk is low, because the answer is known: inference stays in-region or the feature does not exist there
Swap model provider within one sprint	L	H	Nobody in the cast is asking for it. It would add an abstraction layer, and it competes for capacity Tomas Beck does not have

The third row shows why “blocking authority” and “high risk” are not the same thing. A hard constraint from a formal blocker is usually low risk once you know it — unambiguous, and it simply removes options. The fourth row is the one to be honest about: it is the most architecturally interesting item on the list and it should not be built.

What this costs

The tree is a snapshot. Drivers change, and a tree built in month one and never revisited becomes a confident record of what used to be true. Date it, and revisit it when a driver moves.

It also compresses nuance into single letters, which is the source of its clarity and of its dishonesty. H/M/L hides the difference between “fairly sure” and “guessing”. Where a risk rating is really a guess, say so in a sentence next to it.

And it can become framework theater — a tree produced because the method says so, with ratings nobody argued about. A tree where every leaf is High value is not a prioritisation; it is a wish list with branches.

Feeds the workbook

This topic feeds the Utility Tree artifact directly. Two requirements for this module are worth reading as a pair: at least two leaves must reflect different stakeholders’ priorities, and at least two requirements must genuinely conflict. If nothing on your tree pulls against anything else, the ratings are too generous.

Check your understanding

1. Take a scenario from your own work that was easy to implement but high architectural risk. What made it risky, and who should have rated it?
2. Your sponsor rates everything High value. What do you do — and what question forces a real ranking?
3. A leaf is rated low value, high risk, and an engineer you respect wants to build it anyway. What does the tree let you say that you could not say before?

---

→ The tree is only as good as what people told you. They disagreed, and some of them will not tell you the real requirement — Eliciting from people who disagree