Module 5: Stakeholders and Quality Attributes

2. From the business goal to the quality attribute

Next →

Overview

By the end of this lesson you'll know how to do, with method and with numbers, the translation that is the heart of the whole module: take a list of business goals —wishes, in the business's language— and return a list of prioritized quality attributes —the -ilities, in a defensible order—. In lesson 1 you saw the intuition: a single phrase ("open to external vendors") opens into several attributes. Here you turn it into a reproducible procedure over Mercado's six complete goals. The mechanic is simple and that's why it's powerful: each goal implies one or several attributes, with different strength; each goal has a business weight (how strategic it is); and an attribute's business backing is the sum, over all the goals, of goal weight × strength with which that goal implies it. That number —the score— orders the attributes by how much the business sustains them, not by how much the architect likes them. You'll execute the mapping and see the ranking come out: in Mercado, scalability leads (38), followed by security (30), availability (25), performance (23), and cost (19). And you don't stop there: you'll detect the conflicts —the pairs of attributes that fight, because improving one costs the other— ordered by how much they weigh together, and you'll see that the trade-off that weighs the most in Mercado is scalability against cost.

This matters because it's the difference between an architect who decides with evidence and one who decides with opinions. Without this mapping, when the moment comes to choose —do I optimize to scale or to not spend? do I put security or speed first?— the architect has nothing to defend their choice beyond "I think so". With the mapping, they can say: "scalability goes first because three strategic goals back it with a score of 38, the highest; cost goes last, not because it doesn't matter, but because only two goals sustain it; and by the way, scalability and cost fight, so that's the trade-off we have to resolve first, and here's the data that says so". That's not bureaucracy: it's having the map that makes every subsequent decision traceable to a business goal with a weight. And there's a second gift hidden in the exercise: by listing which goals back each attribute, the mapping shows you the business's real conflicts —"grow 10x" (scalability) against "not triple the bill" (cost) isn't an abstract clash of attributes, they're two concrete leadership goals that contradict each other, and someone will have to choose—.

Connection with the module: this lesson is the engine everything else hangs from. Lesson 1 gave the thesis (translate the business to attributes); here you execute it in depth. The lessons that follow refine each piece of this mapping: lesson 3 takes an attribute from the ranking and makes it measurable with a scenario (because "high scalability" is still vague); lesson 4 filters the requirements that really shape the architecture (the ASRs) from the ones that don't; lesson 5 discovers the implicit attributes this mapping doesn't capture because no one asked for them; and lessons 6 and 7 use the conflicts you detect here for the conversation —how you explain to the VP that scalability-vs-cost forces a choice, and how you say "I can't give you both at the maximum"—. The whole module is this mapping, first built (here), then tuned, then discussed. The frontier stays firm: here you detect that the attributes compete; how that conflict is resolved —the decision matrix, the ADR— is architecture-decisions's method, not this lesson's.

The waiter who puts together a whole table's order

Think about it with the waiter from lesson 1, but now with a table of six, not a single diner. Each one orders in their language: "something light", "not spicy, I'm sensitive", "as fast as possible, I'm in a hurry", "nothing expensive", "something hearty, I'm hungry", "whatever, but enough to share". Six wishes, in the table's language. The good waiter doesn't treat them as six independent orders: they translate them all at once into dish attributes (lightness, no chili, speed, price, portion) and notice two things at once. First, that some wishes push the same attribute —"light" and "not spicy" were asked for by more than one, so that attribute weighs more—. Second, that some wishes contradict each other: "as fast as possible" fights with "something hearty that takes time to cook", and "nothing expensive" fights with "something hearty of good quality". The waiter who knows their craft prioritizes —which attribute satisfies the most important diners?— and names the clashes out loud: "the hearty stew takes 40 minutes; if you're in a hurry, better the pasta". They don't invent the conflict: they discover it by translating all the wishes together and seeing where they cross.

That's exactly what the architect does with the business goals, and that's why you have to translate them all together, not one by one. If the architect translated "grow 10x" into isolation and then, in another meeting, "not triple the bill" into isolation, they'd never see that the two fight. It's by putting them in the same table —Mercado's six wishes, with their weight, with the attributes they push— that it jumps out that one attribute is backed by three goals (it weighs) while another is backed by a single one (it weighs little), and where the conflict jumps out: "grow 10x" pushes scalability up and "not triple the bill" pushes cost down, and those two forces are going to meet head-on. This lesson's mapping is the waiter who puts together the whole table's order: translates all the wishes at once, sees which reinforce each other, and discovers which clash.

Worked example: the goal → prioritized attribute mapping

We'll execute the complete translation over Mercado's six goals. The data structure has three parts, all fixed so the result is reproducible: each goal's business weight (from 1, a nice-to-have, to 5, something strategic), which attributes each goal implies and with what strength (from 1 to 3), and the list of known conflicts between attributes. Each attribute's score is the sum of weight × strength over all the goals that push it. Then we rank, and finally we detect which conflicts weigh the most.

# From business goals to quality attributes, prioritized -- and with their conflicts.
# Fixed and reproducible data.

# Mercado's goals with their business weight (1=nice-to-have .. 5=strategic).
business_goals = {
    "open_to_external_sellers": 5,
    "grow_10x":                 5,
    "survive_black_friday":     4,
    "protect_payment_data":     5,
    "keep_infra_costs_flat":    3,
    "instant_checkout":         3,
}

# Which quality attribute(s) each goal implies, and with what strength (1..3).
implies = {
    "open_to_external_sellers": {"scalability": 3, "security": 3, "availability": 2},
    "grow_10x":                 {"scalability": 3, "performance": 2, "cost": 2},
    "survive_black_friday":     {"availability": 3, "scalability": 2, "performance": 1},
    "protect_payment_data":     {"security": 3},
    "keep_infra_costs_flat":    {"cost": 3},
    "instant_checkout":         {"performance": 3, "availability": 1},
}

attributes = ["scalability", "availability", "security", "performance", "cost"]

# Score of each attribute = sum of (goal weight * strength with which it implies it).
score = {a: 0 for a in attributes}
for goal, weight in business_goals.items():
    for attr, strength in implies[goal].items():
        score[attr] += weight * strength

ranking = sorted(attributes, key=lambda a: score[a], reverse=True)

print("Quality attributes prioritized by their business backing:")
print(f"{'#':>2}  {'attribute':<13}{'score':>6}   backed by (goals)")
for i, attr in enumerate(ranking, 1):
    backers = [g for g in business_goals if attr in implies[g]]
    print(f"{i:>2}  {attr:<13}{score[attr]:>6}   {', '.join(backers)}")

# Pairs of attributes that typically COMPETE: improving one tends to cost the other.
tensions = [
    ("scalability",  "cost"),         # scaling costs infra
    ("security",     "performance"),  # encrypting/validating/auditing adds latency
    ("availability", "performance"),  # replicating/consensus can add latency
    ("availability", "cost"),         # more redundancy = more $
]

print()
print("Conflicts between attributes (improving one costs the other), by combined weight:")
ranked_tensions = sorted(tensions, key=lambda p: score[p[0]] + score[p[1]], reverse=True)
for a, b in ranked_tensions:
    combined = score[a] + score[b]
    print(f"  {a} ({score[a]}) vs {b} ({score[b]})  ->  combined weight {combined}")

print()
top = ranked_tensions[0]
print(f"The conflict that weighs the MOST: {top[0]} vs {top[1]}.")
print("That's the trade-off the architect must face first. The method of")
print("HOW to resolve it is in architecture-decisions; here we only detect it.")

What to expect. Running it:

Quality attributes prioritized by their business backing:
 #  attribute      score   backed by (goals)
 1  scalability      38   open_to_external_sellers, grow_10x, survive_black_friday
 2  security         30   open_to_external_sellers, protect_payment_data
 3  availability     25   open_to_external_sellers, survive_black_friday, instant_checkout
 4  performance      23   grow_10x, survive_black_friday, instant_checkout
 5  cost             19   grow_10x, keep_infra_costs_flat

Conflicts between attributes (improving one costs the other), by combined weight:
  scalability (38) vs cost (19)  ->  combined weight 57
  security (30) vs performance (23)  ->  combined weight 53
  availability (25) vs performance (23)  ->  combined weight 48
  availability (25) vs cost (19)  ->  combined weight 44

The conflict that weighs the MOST: scalability vs cost.
That's the trade-off the architect must face first. The method of
HOW to resolve it is in architecture-decisions; here we only detect it.

Read the ranking first, because it's the translation made into a number. Scalability leads with 38, and the right-hand column tells you why: three goals back it, and two of them are the most strategic (weight 5) —opening to external vendors and growing 10x—. It's not that the architect likes to scale; it's that the business, with its own priorities, pushes scalability more than any other attribute. Notice the number didn't come out of nowhere: open_to_external_sellers (weight 5) implies it with strength 3 → 15; grow_10x (weight 5) with strength 3 → 15; survive_black_friday (weight 4) with strength 2 → 8; total 38. Every point of the score is traceable to a goal with a weight. That traceability is the gift: when someone asks "why is scalability first?", the answer isn't an opinion, it's this sum.

Now notice the contrast the module teaches. Security is second (30) even though only two goals back it —but the two with weight 5 and strength 3, so it sums high—. Cost is last (19), and here there's a crucial nuance a hurried reader misinterprets: last doesn't mean it doesn't matter. The CFO was explicit with "not triple the bill", and that goal is on the list with weight 3. Cost is last because only two goals push it and with medium weights, while scalability has three goals and two at maximum weight. The ranking doesn't say "ignore the cost"; it says "when the cost fights with the scalability, the scalability has more business backing" —which is extremely valuable information for the conversation to come—. The architect who reads this doesn't discard the cost; they know they'll have to negotiate it against the scalability, and they know which side the weight is on.

And there comes the second half of the output, the conflicts one, which is where the mapping stops describing and starts warning. The system detected four pairs of attributes that fight and ordered them by their combined weight. The one that weighs the most is scalability (38) against cost (19), with a combined weight of 57. Translated: the flagship goal "grow 10x" (which pushes scalability) and the CFO's explicit goal "not triple the bill" (which pushes cost) contradict each other head-on, and since between the two they sum the highest business weight, that's the trade-off the architect has to resolve first —before any other—. It's not a theoretical clash between two abstract -ilities: they're two concrete leadership phrases that can't both be met at the maximum. The second conflict (security 30 vs performance 23, weight 53) is the classic "shield the payment data" against "instant checkout": encrypting, validating, and auditing adds latency. The two conflicts that weigh the most came directly from real business goals, and the architect now has them named, quantified, and ordered —before drawing anything—.

An honest nuance, because the model simplifies. The weights (1-5) and the strengths (1-3) aren't truths of the universe: they're a judgment of the architect, made explicit. Someone could argue whether grow_10x implies scalability with strength 3 or with strength 2, and that argument would change the ranking. But that's precisely the value of the method: it makes the judgment explicit and arguable. Instead of an architect who decides by eye and no one knows why, you have a table where every assumption is in view and the business can correct it —"no, for us the cost weighs 5, not 3, because we're about to raise capital and the burn matters a lot"—. The number doesn't pretend to be exact; it pretends to make the conversation possible. An arguable and traceable ranking is infinitely better than a hunch no one can examine. The mapping doesn't replace the architect's judgment: it takes it out of their head and puts it on the table, which is where the business can weigh in.

Deep dive: why the ranking comes from the business, and what it does with the tie

It's worth stopping at three things this mapping reveals that a beginner architect usually overlooks.

First, the ranking is the business's, not the architect's —and that's liberating—. An architect without this method carries an impossible responsibility: deciding, on their own judgment, whether Mercado should prioritize scaling or saving. It's a business decision disguised as a technical decision, and when it goes wrong, the architect carries the blame. The mapping returns that decision to where it belongs: the weights are set by the business (how strategic is each goal?), and the architect only contributes the translation (what attribute each goal implies). When the ranking says "scalability first, cost last", it's not that the architect decided it: it's that the business's priorities, made explicit, produce it. If the business doesn't agree with the ranking, the right conversation isn't "the architect was wrong" but "let's review the weights" —and that's healthy, because it puts the strategic decision where it should be—.

Second, the close tie is information, not noise. Look at performance (23) and availability (25): they're almost tied. A naive architect would see the ranking and treat 3rd and 4th place as a firm hierarchy —"availability before performance, always"—. But a two-point difference isn't a firm hierarchy: it's a warning that those two attributes are of comparable importance for Mercado, and that the decision between them will depend on the context of each concrete case, not on the global ranking. The ranking isn't a decree that resolves everything at once; it's a map of relative weights that tells you where there are big differences (scalability 38 against cost 19: a real gap) and where there are ties you'll have to break case by case (availability 25 against performance 23: practically equal). Reading a tie as if it were a hierarchy is abusing the number.

Third, the mapping captures the explicit, and that's why it has a blind spot you have to know. This method ranks the attributes the goals name. But there are attributes no goal names and that the system must nevertheless meet —data integrity, auditability, privacy—. In this ranking they don't appear, because no goal on the list pushes them, and their score would be zero. That doesn't mean they don't matter; it means the mapping of explicit goals isn't sufficient on its own, and it has to be complemented with the discovery of the implicit attributes (lesson 5). The architect who treats this ranking as the complete list of what the system needs will deliver exactly the attributes the business asked for and none of the ones it took for granted —and those are exactly the ones that blow up—. The mapping is necessary but not complete: it's the explicit half of the work, and lesson 5 is the other half.

And a note on the frontier, since this is the best place to mark it. The mapping detects that scalability and cost compete. It doesn't tell you how to resolve it —how much of each, what architecture achieves the balance, how to document the choice—. That's a decision with its own rigorous method: options, weighted decision matrix, an ADR that records the why, maybe a fitness function that watches the balance is kept. All that is the architecture-decisions-and-tradeoffs guide. Here your work ends at "here are the prioritized attributes and here are the conflicts to resolve, in order of weight". Delivering that —a clear map of what competes with what and how much each side weighs— is exactly the input the decision method needs to start. You do the diagnosis; the other guide does the surgery.

Common mistakes

Prioritizing by the architect's technical taste instead of by the business's weight (of bias). What happens: the architect is passionate about scalability, so they put it first "because it's the right thing", without checking whether the business backs it more than the other attributes. In a startup that doesn't have traction yet, prioritizing scalability over cost can be an expensive mistake —you scale for a traffic that doesn't come while burning the capital that does matter—. Why it happens: it's natural to prioritize what one masters or enjoys. How to spot it: if your ranking would fit any company equally well, it's not anchored in this business. How to fix it: the weights are set by the business, not the architect; run the mapping with the company's real weights and let the ranking come out of there, even if it contradicts your instinct.

Reading "last place" as "doesn't matter" (of a misread ranking). What happens: cost is last in the ranking, and the architect concludes "cost doesn't matter, let's spend whatever it takes to scale", ignoring that the CFO put that goal with weight 3 explicitly. Six months later, the bill tripled and the CFO is furious —cost mattered, it just weighed less than scalability when the two clash—. Why it happens: a ranking invites treating the last places as disposable. How to spot it: if you're completely ignoring an attribute that appears in the ranking (even at the bottom), you misinterpreted it. How to fix it: the ranking says who wins when two attributes clash, not which attributes you can ignore; cost last means "when it fights against scalability, scalability wins", not "forget the cost".

Translating the goals one by one and losing the conflicts (of isolation). What happens: the architect translates each goal in its own meeting, in its own document, and never puts them in the same table —so they never see that "grow 10x" and "not triple the bill" contradict each other—. The conflict blows up late, in implementation, when it's already expensive. Why it happens: the goals arrive at different moments, from different people, and it's convenient to treat them separately. How to spot it: if you don't have a single view with all the goals and all the attributes together, you can't have detected the conflicts. How to fix it: translate all the goals at once, in a single table (like the waiter who puts together the whole table's order), and run the conflict detection —the clashes are only visible when everything is together—.

Exercises

Exercise 1 — Recompute with new weights. Mercado's CFO tells you: "we're about to raise an investment round, so the money burn matters much more than we thought; raise the weight of keep_infra_costs_flat from 3 to 5". Without running the full code, compute the new score of cost and explain how its position in the ranking changes. What would you tell the architect who still has scalability as an absolute priority?

See solution

New cost score. Cost is backed by two goals: grow_10x (weight 5, strength 2 → 10) and keep_infra_costs_flat (now weight 5, strength 3 → 15). New score = 10 + 15 = 25. Before it was 19 (with keep_infra_costs_flat at weight 3: 5×2 + 3×3 = 10 + 9 = 19).

How the ranking changes. Cost rises from 19 to 25, tying with availability (25) and surpassing performance (23). It goes from last place to the middle of the table —a notable jump—. The ranking would now be, approximately: scalability 38, security 30, cost 25 and availability 25 (tie), performance 23.

What you'd tell the architect. That the ranking isn't a fixed truth: it's a reflection of the business's priorities, and the priorities changed. With the investment round coming, cost is no longer the disposable attribute at the bottom of the table —now it weighs as much as availability—. The scalability-vs-cost conflict, which was already the one that weighed the most (57), now weighs even more (38 + 25 = 63) and is even more urgent to resolve. The lesson: when the business changes, you shift the weights and re-run the mapping; an architect who clings to "scalability always first" without updating the weights is deciding with an old map.

Exercise 2 — The goal that pushes two conflicting attributes. Notice grow_10x: it implies scalability (strength 3), performance (2), and cost (2). But scalability and cost compete (scaling costs infra). How can a single goal push two attributes that fight each other? What does that tell you about the nature of business goals?

See solution

A single goal can push two conflicting attributes because a business goal is usually, at bottom, a wish to have it all —and that wish, when translated, reveals its own internal contradiction—. "Grow 10x" literally means "I want to handle ten times more traffic (scalability) without it costing me ten times more (cost) and without it getting slow (performance)". The business doesn't see it as a contradiction: it sees it as a single reasonable aspiration ("grow efficiently"). It's the architect, when translating, who discovers that inside that single phrase live two attributes pulling in opposite directions.

What it tells you about business goals: that they almost always contain a hidden trade-off the stakeholder doesn't see, because the stakeholder thinks about the desired result (grow cheap and fast), not about the technical tensions of achieving it. Part of the architect's craft is bringing that trade-off to light: "when you say 'grow 10x', you're asking to scale and save at the same time, and those two things fight; which weighs more if I have to choose?". That question —uncomfortable for the stakeholder because it forces them to choose something they thought they could have in full— is exactly the work of lessons 6 and 7. The mapping makes it visible: when a goal implies two attributes that are on the conflicts list, you have a trade-off to negotiate within a single goal, not between two.

Exercise 3 — Design the mapping for another company. A telemedicine startup has three goals: "comply with health regulation (HIPAA)" (weight 5), "a video call must never drop in the middle of a consultation" (weight 5), and "launch fast to beat the competition" (weight 4). Assign each goal the attributes it implies and with what strength (use scalability, availability, security, performance and add the ones you need). Without running code, predict which attribute would lead the ranking and why the result would be very different from Mercado's.

See solution

A reasonable assignment (the judgment is arguable, that's the point):

  • comply_with_hipaa (weight 5) → security (strength 3), auditability (strength 3), privacy (strength 3). Health regulation is, above all, protection and traceability of sensitive data.
  • no_dropped_calls (weight 5) → availability (strength 3), reliability (strength 3), performance (strength 2). "Never drop" is availability and reliability of the real-time connection.
  • launch_fast (weight 4) → time_to_market / simplicity (strength 3). Launching fast pushes toward simplicity and against over-engineering —and usually competes with security and availability, which take time—.

What would lead the ranking. Very probably security (backed by HIPAA with weight 5 and strength 3 = 15, plus whatever privacy/auditability contribute), fighting for first place with availability (backed by "no dropped calls" with weight 5 and strength 3 = 15). Scalability, which in Mercado led with 38, barely appears here —none of the three goals pushes it strongly—.

Why it's so different from Mercado. Because the ranking comes from the business, and this is a completely different business. Mercado is a marketplace in explosive growth: its goals push scalability. Telemedicine is a regulated real-time health service: its goals push security, availability, and compliance. Same method, different companies, opposite rankings. That's exactly what proves the method works: it doesn't impose a universal order of attributes ("security always first", "scaling always matters"), but derives the order from each business's real priorities. An architect who arrived at telemedicine with Mercado's ranking in their head would prioritize what doesn't matter. The mapping forces them to start from this company's goals. (This exercise anticipates the project: in it you'll see how the same Mercado, with a different goal —installment payments—, produces a ranking where security dominates and scalability falls to zero.)

Summary and next step

In this lesson you learned to execute the translation that is the heart of the module: from business goals to prioritized quality attributes. With the waiter who puts together the whole table's order you saw why you have to translate all the goals together —only then do you see which attributes reinforce each other and which clash—. And you measured it by executing: the mapping that sums weight × strength over Mercado's six goals and produces the ranking (scalability 38, security 30, availability 25, performance 23, cost 19), with each point traceable to a concrete goal; and the conflict detection by combined weight, which revealed scalability-vs-cost (57) as the trade-off that weighs the most —the contradiction between "grow 10x" and "not triple the bill"—. You understood that the ranking comes from the business and not from the architect, that "last place" doesn't mean "doesn't matter" but "loses when it clashes", that a close tie is a warning and not a hierarchy, and that the mapping captures the explicit but has a blind spot (the implicit attributes) that has to be complemented.

Before moving on you should be able to: take a list of goals with weights and derive a ranking of attributes with weight × strength; explain why an attribute weighs what it weighs by citing the goals that back it; recompute the ranking when the business changes the weights; and detect which attributes compete and which conflict weighs the most —without trying to resolve it here—.

What follows is a problem the ranking leaves open: "high scalability" is still a wish, not a requirement. A prioritized attribute tells you what to optimize, but not how much nor how you'll know if you achieved it. "High availability" can't be designed or tested until someone says "99.95% of orders completed in under 5 seconds during the Black Friday peak". In lesson 3 you'll learn the six-part quality attribute scenario —source, stimulus, artifact, environment, response, response measure— that takes a vague attribute and makes it concrete and measurable. You'll execute a validation that separates the scenarios ready to design from the ones that are still disguised wishes —and the hard rule that governs everything: if it has no measure, it's not a requirement.

Resources

← Previous1. Module introduction: from the business's wish to the quality attributeNext →3. The quality attribute scenario: making the vague measurable