Module 5: Stakeholders and Quality Attributes

6. Speaking the stakeholder's language

Next →

Overview

By the end of this lesson you'll know how to do the translation that decides whether your architecture gets to exist: turning a technical trade-off into its business consequence, said in the language of whoever signs the budget. In the previous lessons you did all the work on the architect's side —translate goals to attributes (2), make them measurable (3), filter the ones that matter (4), discover the implicit ones (5)—. But that work is worth nothing if, when you sit across from the VP of finance and they ask you "why do we need to spend so much on availability?", you answer "because we need 99.99% with active-active multi-region replication". You just lost the conversation, not because your argument is bad, but because you said it in a language your interlocutor doesn't speak. The VP doesn't think in nines; they think in dollars, risk, and time. This lesson's skill is translating back: "99.99% availability" says nothing to them, but "each hour we're down on Black Friday is X dollars of sales that go and don't come back, and this investment is the insurance that avoids it" says everything. You'll execute the table that does that translation for availability —each level of nines converted into minutes down per year, into lost sales, and into infrastructure cost—, and you'll see the module's phrase made into a number: more availability = more money, in both senses (more availability protects more sales, and costs more infra).

This matters because it's the half of the craft that technically brilliant architects most neglect, and the one that most limits them. An architect can have the best design in the world, perfectly derived from the goals, measured, prioritized —and watch it die in a meeting because they couldn't explain it to whoever decides—. Architecture isn't approved by a committee of architects; it's approved by business people who control the budget and the priorities, and who evaluate your proposal with the only yardstick they know: how much does it cost, what risk does it cover, how long does it take? The architect who only speaks in technical attributes leaves that evaluation in the stakeholder's hands without giving them the tools to do it well —and a stakeholder who doesn't understand tends to cut what they don't grasp—. The architect who translates the trade-off into money and risk hands the stakeholder exactly what they need to decide, and —crucially— leaves the decision in their hands, which is where it belongs: the architect doesn't decide how much it's worth spending on availability; they present the trade-off in terms the business understands, and the business decides. Speaking the stakeholder's language isn't manipulation or "selling"; it's making it possible for the right person to make the right decision with the right information.

Connection with the module: this lesson closes the two-way direction lesson 1 announced. Lessons 2 to 5 were the first direction: translate the business to attributes to be able to design. This is the second: translate the trade-offs back to the business to be able to agree. It uses everything before as input —the lesson 2 ranking says which attributes matter; the lesson 3 scenarios give the numbers (99.95%, under 5 seconds) you translate to money here; the conflicts you detected (scalability vs cost) are exactly the ones you have to explain—. And it sets up lesson 7: once you know how to put each attribute in money, you can show why "everything at the maximum" is impossible within a budget, which is "knowing how to say no". The frontier stays firm: here you learn to communicate the trade-off in the business's language; how the level to choose is decided —the matrix, the ADR— is architecture-decisions's method, and in fact this translation is the input that makes that decision possible, because it puts the options in comparable terms for whoever decides.

The real estate agent who translates "reinforced foundations" into "sleeping soundly"

Think about it with whoever sells the house, not with whoever builds it. A structural engineer explains to a family that wants to buy: "this house has a slab foundation with grade-60 steel seismic reinforcement, load-bearing walls with confinement, and a conservative slenderness ratio". All true, all excellent engineering —and the family understood nothing—. They nod with a poker face, feel they're being sold something expensive they don't grasp, and their instinct is to distrust or ask for a discount. Now a good real estate agent comes in and translates the same thing: "this house is built to withstand a strong earthquake without cracking; in the seismic zone where you're going to live, with your kids, that means you can sleep soundly and the house will be worth more when you want to sell it, because it won't have the damage the ones next door will". The family understood perfectly. They didn't learn what grade-60 steel is —they don't need to—; they understood what it means for them: their family's safety and the value of their investment. The agent didn't lie or inflate: they translated a technical property (seismic reinforcement) into the consequence that matters to the buyer (peace of mind + resale value).

Notice what the agent did, because it's exactly this lesson's craft. They took a technical attribute the buyer can't evaluate (is the seismic reinforcement worth its cost? the buyer has no way to know) and turned it into a consequence the buyer can evaluate (is my family's peace of mind and a better resale value worth it? that I can weigh). And in doing so, they returned to the buyer the power to decide well: now the family can compare the reinforcement's premium against the value it gives them, and decide. The engineer, with all their technical rightness, had left the family unable to decide —only with the feeling of being sold something expensive—. The software architect is that real estate agent when they sit across from the business: their job isn't to impress with the engineering (that pushes away whoever decides), but to translate each attribute and each trade-off into the consequence the stakeholder can weigh —money, risk, time—, and thus put them in a position to decide well. The one who talks in "grade-60 steel" loses; the one who translates into "sleep soundly" wins, and makes whoever listens win.

Worked example: the nines translated into money

We'll execute the translation for the star attribute of these conversations: availability. The VP talks about "not going down"; the architect talks about "nines" (99%, 99.9%, 99.99%). The table that follows translates each level of nines into the three things the VP does understand: how many minutes per year the system would be down, how much sales are lost in that time (at a fixed revenue per minute), and how much the infrastructure costs to achieve that level (relative to the base level). The data is fixed: Mercado bills 1200 USD per minute, and each level has a known relative infra cost.

# The stakeholder's language isn't "availability", it's MONEY. We translate each
# availability level into what the VP understands: minutes down per year and
# lost sales. That way "more 9s" becomes "more money" -- in both senses.

MINUTES_PER_YEAR = 365 * 24 * 60          # 525600
revenue_per_minute = 1200                 # USD/min Mercado bills (fixed data)

# Availability level -> RELATIVE infra cost to achieve it (fixed data).
levels = [
    # label,     uptime,    relative infra cost
    ("99%",      0.99,       1.0),
    ("99.9%",    0.999,      2.5),
    ("99.99%",   0.9999,     6.0),
    ("99.999%",  0.99999,   15.0),
]

print(f"{'level':<10}{'down/year':>14}{'lost sales/year':>21}{'infra':>8}")
rows = []
for label, uptime, infra_cost in levels:
    downtime_min = MINUTES_PER_YEAR * (1 - uptime)
    lost = downtime_min * revenue_per_minute
    rows.append((label, downtime_min, lost, infra_cost))
    print(f"{label:<10}{downtime_min:>10.0f} min{lost:>17,.0f} USD{infra_cost:>7.1f}x")

print()
print("What the VP hears -- the margin of each extra '9':")
for i in range(1, len(rows)):
    label = rows[i][0]
    saved = rows[i - 1][2] - rows[i][2]
    infra = rows[i][3]
    print(f"  going to {label:<9}: avoids {saved:>12,.0f} USD/year of sales  (infra {infra:.1f}x)")

print()
print("Each extra '9' avoids LESS sales and costs MORE infra. There's a point where")
print("the next 9 no longer pays for itself: that's where the architect says enough.")

What to expect. Running it:

level          down/year      lost sales/year   infra
99%             5256 min        6,307,200 USD    1.0x
99.9%            526 min          630,720 USD    2.5x
99.99%            53 min           63,072 USD    6.0x
99.999%            5 min            6,307 USD   15.0x

What the VP hears -- the margin of each extra '9':
  going to 99.9%    : avoids    5,676,480 USD/year of sales  (infra 2.5x)
  going to 99.99%   : avoids      567,648 USD/year of sales  (infra 6.0x)
  going to 99.999%  : avoids       56,765 USD/year of sales  (infra 15.0x)

Each extra '9' avoids LESS sales and costs MORE infra. There's a point where
the next 9 no longer pays for itself: that's where the architect says enough.

Look at the top table first, and notice what just happened: a technical attribute became a column of dollars. "99%" says nothing to the VP; "5,256 minutes down per year —almost four days— and 6.3 million dollars of lost sales" says everything. Availability stopped being an engineering concept and became a figure in the language the VP thinks in. And notice the force of the contrast between rows: going from 99% to 99.9% cuts the downtime from almost four days (5,256 minutes) to under nine hours (526 minutes). For a business that bills 1200 USD per minute, that's the difference between losing 6.3 million and losing 630 thousand. That's the argument —not "we need one more nine", but "the first extra nine saves us 5.7 million dollars a year"—. The VP doesn't need to understand replication to approve that; they need to compare 5.7 million saved against the cost of 2.5x the infra, and that comparison they can make with their eyes closed.

Now the second table, the one of margins, which is where the translation becomes wisdom and not just communication. Notice the brutal pattern: each extra nine avoids less and less sales. The first jump (to 99.9%) avoids 5.7 million. The second (to 99.99%) avoids 568 thousand —ten times less—. The third (to 99.999%) avoids 57 thousand —again ten times less—. And at the same time, the infra column shows that each nine costs more and more: 2.5x, 6x, 15x. The two effects go in opposite directions and cross: there comes a point where the next nine avoids so little sales and costs so much infra that it no longer pays for itself. For Mercado, with these numbers, jumping to 99.9% is obvious (it avoids 5.7 million for 2.5x the infra); jumping to 99.999% is probably absurd (it avoids 57 thousand and costs 15x —surely much more than 57 thousand a year—). The architect who masters this table doesn't arrive at the meeting to ask for "the maximum availability"; they arrive to say "the optimal point for us is 99.9% or maybe 99.99%, and here's the number that says so —beyond that, we'd be paying millions to avoid thousands—". That's "more availability = more money" truly understood: not as a slogan, but as a curve of diminishing returns that says how far to go up.

An honest nuance, and it's important so as not to use this table as a naive calculator. The model assumes that all the downtime translates into lost sales at a constant rate —which oversimplifies—. In reality: part of the sales lost during an outage is recovered later (the customer comes back later); the outages aren't uniform (a 5-minute outage on Black Friday costs much more than 5 minutes on a Tuesday at 4am); and there are costs the table doesn't capture (an outage damages reputation and trust, not just the sales of that moment). So, does the table lie? No —it does something more useful than being exact: it makes the trade-off arguable in the right language—. The VP can look at the "6.3 million" and say "that's inflated, we recover half of those sales later", and that's exactly the conversation you want to have —one about money and business assumptions, which the VP masters, instead of one about nines, which they don't master—. The table doesn't pretend to give the exact lost-sales figure; it pretends to put the trade-off on the table in dollars so the business adjusts it with its knowledge and decides. An arguable number in the business's language is infinitely more useful than a perfect "99.99%" the VP can't evaluate.

Deep dive: the architect's elevator and the three business currencies

Gregor Hohpe, in The Software Architect Elevator, has the best metaphor for what this lesson does: the architect is the one who goes up and down the elevator of the organization. In the penthouse is the business, which thinks in strategy, market, money, and risk. In the basement is engineering, which thinks in services, latency, queues, and deployments. Most people live on a single floor: the executives never go down to the basement, the engineers never go up to the penthouse. The architect is rare and valuable precisely because they travel between the floors: they understand enough of the business to speak in the penthouse and enough of the engineering to speak in the basement, and their job is to carry information from one floor to another, translated. They bring the business's strategy down and turn it into attributes for engineering (lessons 2-5); they bring engineering's trade-offs up and turn them into money and risk for the business (this lesson). An architect who only knows how to speak in the basement is no use in the penthouse, and vice versa. The complete skill is the journey in both directions —and this lesson is the journey up, the most neglected one—.

To translate well upward, it helps to know that the business handles essentially three currencies, and every technical attribute is exchanged for one of them:

Money. The universal currency of the business. Almost any attribute can be translated into money: availability, into protected sales (the table you executed); scalability, into the cost of growing or the cost of not being able to grow (sales you don't capture because the system can't handle it); performance, into conversion (each second of latency in checkout is a percentage of abandoned carts, which is money); infra cost, obviously, into direct money. When you can put an attribute in dollars, do it: it's the currency the business understands effortlessly.

Risk. When something can't be put in direct money, it's put in risk —the probability and magnitude of a catastrophe—. Security rarely translates to "generates X dollars"; it translates to "avoids the risk of a leak that would cost fines, lawsuits, and reputation". Auditability (lesson 5) is sold in risk: "the day the regulator asks and we don't have the trail, it's a fine". Risk is the currency of the attributes that prevent disasters instead of generating revenue. The trick is to quantify the risk as much as possible: not "it's risky", but "a payment data leak at our scale is, looking at comparable cases, between X and Y million plus the loss of trust".

Time. The third currency, and the one that connects with technical debt. Time translates into time-to-market (launching before the competition is worth money) and into future speed (a maintainable architecture lets you build faster later). This is where the architect explains the shortcut's trade-off: "we can launch this in half the time by taking this shortcut, but it's a debt —each future feature on this base will cost 30% more until we pay it off—". The VP understands "faster now, slower later" perfectly, because it's a time trade-off, which is a business currency. Naming the debt in time (not in "ugly code") is what turns it into a conscious business decision instead of a technical surprise.

And here's the principle that ties the deep dive with the module's frontier: translating the trade-off into the business's language isn't making the decision —it's making it possible for the business to make it—. When you put "99.9% avoids 5.7 million for 2.5x the infra", you're not deciding the availability level; you're putting the trade-off in a form the VP can weigh, and the VP decides. That's the correct respect for the frontier: the architect doesn't usurp the business decision (how much it's worth spending is the business's), nor abandon it (letting the VP decide without understanding the trade-off is negligence). They translate, present, and let decide. How that decision is structured when there are several conflicting attributes —the weighted matrix, the ADR that records it— is architecture-decisions's method; but that method only works if the options are expressed in terms the decider understands, and putting them in those terms is, precisely, this lesson's job. You're the translator who makes the decision possible, not the one who makes it.

Common mistakes

Speaking technical jargon to whoever doesn't speak it (of monolingualism). What happens: the architect explains to the VP "we need eventual consistency, sharding by tenant, and multi-region replication", and the VP nods without understanding and decides by instinct —usually to cut what they don't grasp—. Why it happens: the architect lives in the technical language and doesn't register that their interlocutor doesn't speak it; besides, jargon gives a false sense of rigor. How to spot it: if your explanation to the business includes terms a VP of product wouldn't use in a sentence, you're speaking the wrong language. How to fix it: before each conversation with a non-technical stakeholder, translate each attribute into its business currency (money, risk, time) and speak only in that currency —save the jargon for the basement—.

Not saying the trade-off's cost (of omission). What happens: the architect proposes the "good" solution (99.99%, everything redundant) without showing what it costs or what cheaper alternative exists, so the business can't weigh it —they only see a big figure with no context—. Or the reverse: they accept a shortcut without naming its future cost, and the debt blows up later without anyone having decided it. Why it happens: showing the cost feels like weakening the proposal, and naming a shortcut's debt feels like spoiling the fast-launch party. How to spot it: if your proposal doesn't include "this costs X and the alternative costs Y", you didn't give the trade-off, you gave an order. How to fix it: always present the complete trade-off —what you gain, what you cost, what alternative there is— in the three currencies; the nines table is the model: not "let's put 99.99%", but "here's what each level costs and avoids, you decide".

Usurping the business decision by disguising it as technical (of overreach). What happens: the architect decides on their own that Mercado will have 99.99% availability "because it's the technically right thing", without presenting the business the trade-off in money for them to decide. When the bill arrives, the business feels overridden —and rightly so: how much to spend on availability is a business decision the architect made without permission—. Why it happens: it's faster to decide yourself than to translate and wait, and the architect confuses "I know what the best technical level is" with "I should decide the level". How to spot it: if you decided a quality level that costs significant money without the business having seen and approved the trade-off, you overreached. How to fix it: translate, present the options in money/risk/time, and let the business choose —your job is to make the decision possible and well-informed, not to make it in their place—.

Exercises

Exercise 1 — Translate the attribute into its currency. For each of these attributes, say in which of the three business currencies (money, risk, time) you'd translate it primarily, and write a sentence that explains it to a non-technical VP: (a) checkout performance (latency); (b) payment data security; (c) code maintainability.

See solution

(a) Checkout performance → money (via conversion). "Each extra second the checkout takes, a percentage of people abandon the cart. Lowering the latency from 4 to 1 second could recover, say, 5% of the purchases lost today in the wait —at our volume, that's X dollars a month—." (Performance translates into money through conversion: latency → abandoned carts → lost sales.)

(b) Payment data security → risk. "It's not that security generates sales; it's that a card data leak would cost us fines for violating PCI-DSS, probable lawsuits, and —the most expensive— the loss of customer trust, which in a payments business is almost impossible to recover. This investment is the insurance against an event that, looking at comparable cases, would cost millions." (Security is almost always sold in risk: it prevents a disaster, it doesn't generate revenue.)

(c) Code maintainability → time. "Well-structured code means we build each new feature faster. If we take shortcuts now to launch earlier, we gain a few weeks today but everything we do later on that base will cost more —it's a debt we pay with future speed—. The question is how much launching earlier is worth to you against going slower later." (Maintainability translates into time: future development speed, time-to-market.)

The lesson: each attribute has a "natural" currency it's best explained in. Choosing the right currency is half the translation; the other half is quantifying as much as possible within that currency.

Exercise 2 — Find the optimal point. Using the executed table, a colleague argues: "if 99.9% is good, 99.999% is better; let's always ask for the maximum nines". With the table's numbers, explain why they're wrong, and how you'd explain to the VP where the point is where it's worth stopping.

See solution

Why they're wrong: because they ignore that the two sides of the trade-off go in opposite directions. Each extra nine avoids less and less sales (diminishing returns) and costs more and more infra (increasing costs). From the table:

  • Going to 99.9% avoids 5,676,480 USD/year and costs 2.5x. A great deal: you save millions for multiplying the infra by 2.5.
  • Going to 99.99% avoids 567,648 USD/year more and costs 6x. It can still be worth it, depending on how much "6x the infra" is in dollars.
  • Going to 99.999% avoids only 56,765 USD/year more and costs 15x. Almost certainly not worth it: you're paying 15x the infra (probably hundreds of thousands or millions a year) to avoid 57 thousand dollars of sales. You pay millions to save thousands.

"Always the maximum" ignores that the last nine is very expensive and avoids very little. The maximum isn't the optimum.

How you'd explain it to the VP: "Each extra nine of availability protects us less sales than the previous one, but costs more. The first jump (to 99.9%) is obvious: it saves us 5.7 million a year for 2.5 times the infra. The second (to 99.99%) can still be worth it. But the third (to 99.999%) would cost us 15 times the infra to avoid barely 57 thousand dollars of sales a year —we'd pay millions to save thousands—. My recommendation is 99.9% (or 99.99% if you want the extra cushion), and here's the number that says why beyond that we'd be burning money." The optimal point is where the marginal saving of the next nine stops exceeding its marginal cost —and the table makes it visible—. (How that "which level to choose" decision is formalized when more factors come in is architecture-decisions's method; here what you did was put it in terms the VP can decide.)

Exercise 3 — Rewrite the answer that lost the meeting. An architect answered the VP of finance, who asked why the project was expensive: "because we need strong consistency in the payment transactions, idempotency in the retries, and a dual-write system with an outbox so we don't lose events". The VP cut the budget. Diagnose why that answer failed and rewrite it in the business's language.

See solution

Why it failed: the answer is in the basement's language —"strong consistency", "idempotency", "dual-write with outbox"— in front of someone who lives in the penthouse. The VP of finance has no way to evaluate whether "idempotency in the retries" is worth its cost, so they hear "expensive technical words I don't understand" and do the only thing they know to do with what they don't grasp: cut it. The architect was technically right (those things are necessary so as not to lose or duplicate payments) but communicated it in a language that guaranteed the rejection. They didn't lose for being wrong; they lost for being incomprehensible.

Rewritten in the business's language (currency: risk + money): "The cost you see is protecting something very concrete: that we never charge a customer twice or lose a payment halfway through a transaction. In a business that moves money, charging twice means refunds, disputes with the bank, furious customers who leave, and at volume, a real hit to revenue and trust. Losing a payment means we sold something and didn't get paid —money that evaporates—. The 'expensive' part of the project is, at bottom, the machinery that guarantees that every peso a customer pays is charged exactly once, not zero and not twice. I can show you, if you want, how much a month of charging errors would cost us without that machinery, to compare against what it costs to build it —and you'll see it's much cheaper to build it than to live without it—."

Why it works: it translates each technical term into its business consequence (consistency + idempotency → "never charge twice or lose a payment"), puts it in the right currencies (risk of refunds/disputes/customer churn, and money of lost payments), and offers to quantify the risk so the VP compares —leaving them the decision with the right information—. Same technical truth, opposite language, opposite result.

Summary and next step

In this lesson you learned the module's second translation direction: turning a technical trade-off into its business consequence, in the language of whoever decides. With the real estate agent who translates "reinforced foundations" into "sleeping soundly" you saw that impressing with the engineering pushes away whoever decides, while translating into the consequence they can weigh puts them in a position to decide well. You measured it by executing: the table that converts each availability level into minutes down, into lost sales, and into infra cost —"more availability = more money" made into a number—, and the margins that reveal that each extra nine avoids less and costs more, up to a point where it no longer pays for itself. You met Hohpe's elevator (the architect travels between the business's penthouse and engineering's basement) and the three business currencies (money, risk, time), and the principle that governs them: translating the trade-off isn't making the decision, it's making it possible for the business to make it —neither usurping it nor abandoning it—.

Before moving on you should be able to: translate any attribute into its business currency (money, risk, or time) and explain it without jargon; read a trade-off table to find the diminishing-returns point where it's worth stopping; always present the cost and the alternative, not just the solution; and respect the frontier —translate and present, let the business decide—.

What follows is the hardest conversation of all, and the one that separates a mature architect from one who wants to be liked: knowing how to say no. You now know how to put each attribute in money. The inevitable consequence is that you can't have everything at the maximum —the budget doesn't reach, and some attributes fight each other—. When the stakeholder asks for "I want it all: maximum availability, maximum security, maximum performance, minimum cost", the architect has to know how to answer. In lesson 7 you'll execute the demonstration that "everything at the maximum" exceeds any budget, and you'll learn that the architect's "no" isn't "it can't be done" but "this is what does fit, prioritized by business value" —the "yes, but it costs this" that turns an impossible wish into a responsible decision—.

Resources

← Previous5. The implicit attributes nobody asked forNext →7. Knowing how to say no (and the cost of yes)