Module 5: Stakeholders and Quality Attributes

1. Module introduction: from the business's wish to the quality attribute

Overview

By the end of this lesson you'll understand where architecture decisions really come from —and the answer will surprise you by how untechnical it is—. They don't come from the architect's taste or from the latest technology trend. They come from the business: from people who want things and say them in their language. A VP of product says "we want to grow 10x this year". A finance director says "we can't triple the infrastructure bill". A founder says "we can't go down on Black Friday, it's the day that makes the year". That's the raw material all architecture is made of, and it comes in a language that isn't architecture's: they're wishes, goals, fears —not technical requirements—. The architect's job, before drawing a single box, is the translation: turning those business goals into quality attributes, the ones called the -ilities in English (scalability, availability, security, performance, cost). "Grow 10x" translates to scalability. "Not go down on Black Friday" translates to availability. "The payment data can't leak" translates to security. That translation is this module's raw material, and it's the skill that separates an architect from a technician who waits to be told what to build.

This matters because it's where the architect's craft touches the business, and where the most competent people fail without noticing. There are two ways to ruin this translation. The first is not doing it: taking the stakeholder's wish literally —"they asked me for a cache, I put in a cache"— and building the solution the other imagined instead of the problem they really had; you end up solving what wasn't the issue, with technical elegance, and no one understands why the business is still unsatisfied. The second is doing the translation but only in one direction: you derive the attributes, design, and when the VP asks "why so expensive?" you answer "because we need 99.99% availability with multi-region replication", and you lose them —because the VP doesn't speak in nines, they speak in dollars, and you just answered them in a language they don't understand—. This module's skill goes in both directions: translate the business to attributes (to be able to design) and translate the trade-offs back to the business (to be able to agree). Without the first you have nothing to design with; without the second you have no permission to build what you designed.

Connection with the module: this lesson is the map, not the territory. Here you don't translate anything in depth yet; you understand why the six lessons that follow go in the order they go. First the translation itself: lesson 2 takes Mercado's set of goals and executes the mapping to prioritized attributes, with their conflicts. Then the problem that an attribute, just translated, is still vague: lesson 3 makes it measurable with the six-part quality attribute scenario. Then, how to separate what matters from what doesn't: lesson 4 filters the architecturally-significant requirements —the signal— from the noise. Next, what no one said but everyone expects: lesson 5 discovers the implicit attributes. And the last two are the conversation: lesson 6 teaches how to speak the stakeholder's language (translate the trade-off to money) and lesson 7 how to say no —or "yes, but it costs this"—. Lesson 8, the project, puts you to deriving the attributes of a new launch with your own hands.

The house architect who translates "a house to grow old in"

Think about it with a craft that resembles ours more than we think: the house architect. An older couple arrives and tells them: "we want a house to grow old in, to spend the last thirty years of our life." That's a goal, a wish, said in the language of life —not in the language of blueprints—. A bad architect takes it literally and asks "how many bedrooms, what color the walls?", as if it were any house. A good architect hears something completely different. They hear a list of concrete requirements the couple didn't say but that their goal demands: no stairs (or a bedroom on the ground floor), because in twenty years the knees won't climb; wide doors, in case someday there's a wheelchair; the main bathroom on the ground floor and with grab bars; non-slip floors; good lighting for eyes that see less; maybe an extra room on the ground floor in case they need someone to care for them. None of that did the couple ask for. All of that the architect derived from the goal "grow old here".

Notice what the good architect did, because it's exactly our craft. They didn't take the solution the client might have imagined; they took the problem the client had. If the couple had said "we want a beautiful marble staircase" and the architect had just put it in, they'd have built the wrong solution for the real problem —a beautiful house that at eighty becomes a trap—. The architect translated the wish ("grow old here") into attributes of the house (accessibility, safety, long-term comfort) and from there into concrete requirements (no stairs, wide doors, bathroom downstairs). And that translation is the hard and valuable part: anyone draws a house; the architect knows which house to draw because they understood what whoever will live in it really needs.

It's the same as the waiter who knows their craft. A diner says "I want something light and not spicy". That's not a dish, it's a wish. The good waiter translates it: rules out the heavy stews, rules out what has chili, and recommends —say— a grilled fish with vegetables. They translated "light and not spicy" (the diner's language) into a dish on the menu (the kitchen's language). If instead they'd asked "would you like the teriyaki salmon or the tacos al pastor?", they'd have failed: giving options without understanding that "not spicy" already ruled out the pastor and "light" already ruled out the heavy. The software architect does this same work, every day: someone from the business says "something light and not spicy" —"we want to grow without going down and without overspending"— and the architect translates it into a concrete dish: these attributes, at this level, with these trade-offs. This lesson, and the whole module, is learning to be that house architect and that waiter: the one who hears a wish and knows what to build.

The case: Mercado and its 18-month strategy

Let's come down from the house to software. Throughout this guide we accompany Mercado, the ecosystem's marketplace. In the previous modules we saw it as a system and as an organization of five squads. Now we see it from above: from the business that asks it for things. Mercado's leadership just closed its strategy for the next 18 months, and handed it to the architect as a list of goals —in the business's language, not ours—:

Open Mercado to external vendors via API. The flagship bet: letting third parties sell on the platform, integrating through a public API. From being a store, Mercado becomes a real marketplace.
Grow 10x in users and transactions in 18 months.
Not go down during Black Friday, the day that concentrates a good part of the year's revenue.
Shield the payment data: it must never leak, no matter what.
Not triple the infrastructure bill while growing —the CFO was explicit—.
A checkout that feels instant, because every second of wait costs conversion.

None of those phrases is an architecture requirement. All are legitimate business wishes, and all are in a language that doesn't tell the architect what to build —it tells them what the business wants to achieve—. Mercado's architect's job, and that of this whole module, is to take that list of wishes and turn it into a list of prioritized quality attributes you can actually design with. Before measuring anything in depth, let's see the translation in its purest form: how a single one of those phrases opens into several attributes. Look closely, because this little piece of code condenses the whole module.

# Teaser: a single business goal isn't ONE requirement -- it opens into several
# quality attributes, each with a different demanded level.

goal = "Open Mercado to external vendors via API"

# What that single phrase DEMANDS, without anyone having said it yet:
derived = [
    ("scalability",  "the catalog and the vendors grow 10-100x"),
    ("security",     "each vendor sees ONLY its data (multi-tenant isolation)"),
    ("availability", "if Mercado goes down, thousands of vendors' stores go down"),
    ("usability",    "the API must be so clear a third party integrates it without help"),
]

print("Business goal (what the VP said):")
print(f'  "{goal}"')
print()
print("Quality attributes that single goal DEMANDS (what the architect hears):")
for attr, why in derived:
    print(f"  - {attr:<13} because {why}")
print()
print(f"One (1) business phrase  ->  {len(derived)} quality attributes to prioritize.")

What to expect. Running it:

Business goal (what the VP said):
  "Open Mercado to external vendors via API"

Quality attributes that single goal DEMANDS (what the architect hears):
  - scalability   because the catalog and the vendors grow 10-100x
  - security      because each vendor sees ONLY its data (multi-tenant isolation)
  - availability  because if Mercado goes down, thousands of vendors' stores go down
  - usability     because the API must be so clear a third party integrates it without help

One (1) business phrase  ->  4 quality attributes to prioritize.

Stop at the last line, because it's the whole thesis in one phrase. A single business goal opens into four quality attributes —and none of the four did the VP ask for—. The VP said "open to external vendors"; they didn't say "scalability", they didn't say "multi-tenant isolation", they didn't say "availability". All that the architect derived from the phrase, just as the house architect derived "no stairs" from "grow old here". And notice it's not a one-to-one translation, like swapping a word for its synonym: it's an expansion. A business goal hides several attributes because achieving it demands several things at once —to open to external vendors the system has to scale, has to isolate each one's data, has to be up because thousands of stores depend on it, and has to offer an API a stranger can use—. That expansion from one to several is the architect's first job, and it's invisible to whoever doesn't do it: the one who takes "open to external vendors" as a single technical requirement will crash into the three attributes they didn't see coming.

Now notice something this teaser already hints at and that will be the module's thread: the four attributes aren't equally important, and some will clash with each other. The isolation (security) so one vendor doesn't see another's data can fight with the speed (performance) of the API; scaling to 100x (scalability) fights with not tripling the bill (cost). Translating the goal to attributes is just the first step; the second is to prioritize them (which goes first?) and the third is to detect where they clash (what trade-off will I have to negotiate?). That's exactly what lesson 2 executes over the six complete goals. For now, keep the intuition: every business wish hides several attributes, and the craft starts by bringing them to light.

The map of the six lessons

The six lessons that follow go in this order for a reason: each one assembles the piece the next one needs.

Lesson	What it gives you	Why it goes here
2	The executed translation of goals into prioritized attributes	It's the heart of the module: you can't do anything without turning the wishes into attributes with an order
3	The quality attribute scenario that makes the vague measurable	An attribute just translated is still a wish until it has a measure to test it against
4	The ASR filter: the signal against the noise	Not every requirement shapes the architecture; you have to know which ones to spend the energy on
5	The implicit attributes no one asked for	The tacit contract of the domain; what blows up if you only deliver what was asked
6	How to speak the stakeholder's language (the trade-off in money)	Translating back to the business is half the craft; without it there's no agreement
7	How to say no —or "yes, but it costs this"—	Promising everything at the maximum is impossible; the architect manages a quality budget

The arc is clear: first you learn to translate and prioritize (2), then to make each attribute measurable (3), then to filter what really matters (4) and to discover what no one said (5), and at the end the two conversation skills —speaking the stakeholder's language (6) and saying no with a cost (7)—. Lesson 8, the project, puts it all together over a new Mercado launch —installment payments— so you confirm you learned the method and didn't memorize the external-vendors case.

What this module does NOT touch

It's worth marking the frontier from now, because there's a neighboring topic that seems to belong here and belongs to the sister guide.

The deep concept of a quality attribute and how you DECIDE between them is architecture-decisions-and-tradeoffs's. There, in its module 2, you study what each attribute is inside —what exactly horizontal vs. vertical scalability means, what an availability SLA is, how security is modeled— and, above all, the method for deciding when two attributes compete: the decision matrix, how to weight, how to document the choice in an ADR, how to set a fitness function that watches it. This module stops one step before: here you learn to derive the attributes from the stakeholder and to detect that they compete, but when the moment comes to resolve the conflict —choose 99.9% instead of 99.99%, choose security over speed— that's the other guide's method, and you'll link to it, not re-teach it. The line is sharp: where the attributes come from and the conversation with whoever asks for them (here); how you decide between them (there).

The technical patterns and styles to achieve an attribute are out. When we say "for availability you need redundancy" or "for scalability you need to partition", we won't teach how redundancy or partitioning is implemented —that's architectural-styles-and-boundaries's and the patterns guides'—. Here we work the layer above: what attribute the business needs and at what priority. The technical how is the toolbox other ecosystem guides already cover.

The management of the people who ask for things is out. We'll talk a lot about conversations with the VP, the CFO, the founder. But how you politically handle a difficult stakeholder, how you negotiate a date, how you deal with an executive who changes their mind —that's leadership and organizational politics, and module 4 touched the technical part of that—. Here we concentrate on the translation: how you explain a trade-off in their language, how you say no with a cost. The rest of the human relationship is another craft.

Common mistakes

Taking the solution the stakeholder asks for instead of the problem (of literalness). What happens: the VP says "we need a cache" or "we have to migrate to microservices", and the architect builds it as-is, without asking what business problem is behind it. Months later the cache solved nothing, because the real problem was another. Why it happens: it's easier to execute a concrete instruction than to decipher the wish that originated it; and saying "yes, I'll do it" feels more collaborative than saying "wait, what problem are we solving?". How to spot it: if you're implementing a technical solution and can't name the business goal that justifies it, you're taking the solution, not the problem. How to fix it: for each request shaped like a solution, ask "what do we want to achieve with that?" until you reach the business goal, and from there derive the attributes —maybe the cache was the right answer, maybe not, but now you know—. It's the house architect who doesn't put in the marble staircase without asking who's going to live there.

Staying at the wish without translating it to attributes (of vagueness). What happens: the architect receives "we want to grow 10x", nods, and starts designing without having turned that into scalability, availability, and cost with a level and a priority. They design by eye, and when someone asks "why this decision?", they have nothing to defend it, because they never made explicit which attribute they were optimizing. Why it happens: the translation feels like a bureaucratic step delaying the "real" work of designing. How to spot it: if your design can't be traced to a list of prioritized attributes, you're designing on a wish, not on requirements. How to fix it: don't draw anything until you've translated the goals to prioritized attributes (lesson 2); that's the requirement everything else hangs from.

Translating in only one direction (of monolingualism). What happens: the architect does translate the business to attributes, designs well, but when it's time to explain it to the stakeholder they do it in technical jargon —"we need eventual consistency and multi-region replication"— and lose them. The VP approves grudgingly without understanding, or rejects out of fear of what they don't grasp. Why it happens: the architect lives in the technical language and forgets that the permission to build comes from someone who doesn't speak it. How to spot it: if your explanations to the business are full of terms a VP of product wouldn't use, you're translating in only one direction. How to fix it: lesson 6 —translate the trade-off back to the business's language (money, risk, time)—; "more availability" says nothing to them, "four million a year in lost sales" does.

Exercises

Exercise 1 — Translate the wish. A founder tells you: "I want Mercado to never lose an order, even if half the internet goes down". Without writing code, what quality attributes does that single phrase hide? Name at least three and explain why each one is derived from that goal.

See solution

The phrase "never lose an order, even if half the internet goes down" is a business wish that hides several attributes:

Availability — "even if half the internet goes down" is an explicit request that the system keep working under infrastructure failures. The system has to be up when the things it depends on aren't.
Reliability / data integrity — "never lose an order" isn't just being up: it's that an order, once accepted, isn't lost or duplicated even if there's a failure halfway. That's data integrity and durability, an attribute different from being available (a system can be up and still lose data in a failure).
Recoverability — "even if it goes down" implies that after a failure the system has to recover without losing what it had already accepted. It's the ability to return to a consistent state after a disaster.

Notice the module's pattern: a business phrase ("never lose an order") expanded into three technical attributes the founder didn't name. And note that data integrity and recoverability are attributes no one asked for by name but that the goal demands —a preview of the implicit attributes of lesson 5—. The architect who only hears "availability" and sets up redundancy, but doesn't protect against the loss of an order halfway through a transaction, delivered half of what the founder wanted.

Exercise 2 — The cache that wasn't. A product manager arrives and says: "the data team needs us to add a Redis cache to the reports". You ask why, and they answer "because the reports take a long time and the CFO complains". Would you take the solution (put in Redis) or the problem? What would you ask, and what attribute(s) are really behind it?

See solution

You'd take the problem, not the solution. "Add a Redis cache" is a technical solution someone already chose; the real problem, said by the PM themselves, is "the reports take a long time and the CFO complains". The attribute behind it is performance (report latency), perhaps with a hint of usability (the CFO's experience waiting).

What you'd ask before touching Redis:

How long do they take today and how long should they take? ("It takes a long time" isn't measurable; you need a number —this is lesson 3's response measure—. Maybe the CFO complains about 40 seconds and with 5 would be happy.)
How often are those reports requested, and does the data change? (If the report is requested once a day, a Redis cache may be over-engineering; maybe pre-computing the report overnight is enough. If it's requested a thousand times a minute over data that barely changes, a cache does make sense.)
Is the problem the query, the database, or the data volume? (A cache hides the symptom; if the query is badly written, maybe optimizing it solves it without adding a new piece of infrastructure to operate.)

Redis could be the right answer —or not—. The module's point isn't "never do what they ask"; it's to translate the request (solution) to its goal (report performance) and from there choose the best solution with evidence, which might be Redis, might be a better query, might be pre-computation. Taking the literal solution would have had you operating a new Redis forever without knowing whether it solved the problem.

Exercise 3 — Translation in both directions. You're Mercado's architect. You translated "not go down on Black Friday" to very high-level availability, and designed a solution with multi-region redundancy that costs quite a bit. The VP of finance asks you in a meeting: "why do we need to spend so much on this?". Give two versions of your answer: one in technical jargon (the bad one) and one in the business's language (the good one). Why does the second work and the first doesn't?

See solution

Bad version (technical jargon): "We need 99.99% availability, which requires active-active redundancy in two regions with automatic failover and synchronous replication of the order state, because a single point of failure in the primary region leaves us unable to serve traffic during the peak." — All true, and all useless for this interlocutor: the VP of finance doesn't know what active-active is or why 99.99% matters, so they hear "expensive things I don't understand" and their instinct is to cut.

Good version (business's language): "Black Friday bills us, say, a million dollars an hour. With the current infrastructure, if the main region goes down —and in a traffic peak is when it goes down most— we lose sales until it recovers, which can be hours: that's hundreds of thousands of dollars that go and don't come back, plus the customers who leave for the competition. The investment I propose is an insurance: it costs X a year and makes it so that, if one part goes down, the other keeps selling without the customer noticing. It's cheaper than a single hour down on Black Friday." — The VP of finance understands perfectly: they compared a cost (the investment) against a quantified risk (the lost sales), in dollars, and can decide.

Why the second works: because it translated the technical attribute (availability 99.99%) into the business consequence (lost sales per hour down, in dollars) —which is the language the VP of finance thinks and decides in—. The first version translates the business to attributes (good) but stops there; the second closes the circle and returns the translation to the stakeholder's language. It's the module's two-way direction: translate the wish to attributes to design, and translate the trade-off to money to agree. Lesson 6 turns this into a method, with the nines-to-dollars table executed.

Summary and next step

In this lesson you met the thesis that holds up the module: architecture decisions don't come from the architect, they come from the business —from people who want things and say them in their language—, and the architect's first job is to translate those goals into quality attributes (the -ilities). With the house architect you saw that "a house to grow old in" translates into concrete requirements the client never asked for (no stairs, wide doors, bathroom downstairs), and that the craft is in taking the client's problem, not the solution they imagined. You met Mercado's 18-month strategy —external vendors and five supporting goals—, the module's raw material. And with the executed teaser you saw the translation in its purest form: a single business phrase ("open to external vendors") opens into four quality attributes, none of which the VP asked for.

Before moving on you should be able to: explain why a business goal is a wish and not an architecture requirement; take a business phrase and expand it into the quality attributes it hides; distinguish "taking the solution" from "taking the problem"; and understand why the translation goes in both directions —from the business to the attributes to design, and from the trade-offs back to the business to agree—.

What follows is doing the complete translation with method. In lesson 2 you'll take Mercado's six goals with their business weight, and execute the mapping to prioritized attributes: derive what attribute each goal implies and with what strength, sum to get a ranking (you'll see scalability on top and cost at the bottom, with numbers), and detect which attributes compete with each other (the scalability-vs-cost conflict will turn out to weigh the most). It's the step from "I sense this wish hides several attributes" to "I know exactly which ones, in what order, and where they'll clash" —the base of everything the architect decides afterward—.

Resources

Len Bass, Paul Clements, Rick Kazman — Software Architecture in Practice — the canonical text on quality attributes and how they're derived from business goals (the business goals and the quality attribute requirements). The chapter on understanding quality attributes is the academic source of this whole module.
Gregor Hohpe — The Software Architect Elevator — the book about the architect who "goes up and down the elevator" between the business's language (the penthouse) and engineering's (the basement). The exact metaphor of this lesson's double translation; indispensable for the conversation with the stakeholder (lesson 6).
Mark Richards & Neal Ford — Fundamentals of Software Architecture — the chapter on identifying quality attributes ("architecture characteristics") from the requirements and the domain; the best modern bridge between what the business asks for and what the architect designs.
ISO/IEC 25010 — software product quality model — the international standard that catalogs the quality attributes (the -ilities): functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, portability. The common vocabulary you translate the business goals into.

← Previous8. Project: get 5 squads to adopt a standard Next →2. From the business goal to the quality attribute