Module 8: Capstone Project — Be Mercado's Architect Through a Change

3. Derive the quality attributes from the goal

Next →

Overview

This is step 2 of the deliverable, and it's the heart of the thread. In lesson 2 you reserved 8 decisions for the architect and saw that the most important ones are the quality attribute decisions —the Seller API's SLO, the security of third-party data—. But where do those attributes come from? Not from the technical catalog nor from the architect's taste: they come from the business goal. By the end of this lesson you'll produce the deliverable's second artifact —the executed mapping of the change's goals to prioritized quality attributes— and you'll name the conflict that governs the whole change. This is the step that turns a business sentence ("grow 10x") into something an architect can design with (a ranking of attributes with evidence), and it's the input all the following steps hang from.

This matters because the ranking of attributes is what gives direction to the structure, the communication, and the rollout. Without this step, when in lesson 4 you have to decide what teams to create, you'll have no basis to justify the choice; when in lesson 5 you draw the C4, you won't know what attribute the architecture you show should optimize. The mapping is the change's compass: it says where everything else points. And the result of this concrete change is revealing —scalability dominates, because "grow 10x" and "open to external sellers" push it with maximum force—, which will tell step 3 that the structure has to produce a sellers surface that scales independently. A different attribute would have produced another architecture. The goal commands, and this step is where that mandate becomes explicit and measurable.

Connection with the module: this lesson does step 2 of the thread and contributes the M5 piece to the capstone. It receives its input from lesson 2 (the framed assignment: the architect owns the attribute decisions) and delivers its output to lesson 4 (the structure): the governing attribute you derive here is what dictates what organization to design there. The frontier with the sister guide stays firm, just as in module 5: here you detect that two attributes compete (scalability vs cost); how that conflict is resolved —the decision matrix, the fitness function— is the method of architecture-decisions-and-tradeoffs, not of this lesson. Your job here ends at "these are the prioritized attributes and this is the conflict to face first", which is exactly the input the structure of the next step needs.

The UN translator who prepares the negotiation

Think of a translator at an international negotiation. At the table there's a head of state who says, in their language, things like "we want to grow economically but without depending on a single trade partner". The translator doesn't repeat word for word; they translate the sense into the other party's language, and —if they're good— they do something more: by translating all their leader's statements at once, they notice some contradict each other. "We want to grow fast" and "we don't want to take on debt" push in opposite directions; "we want to open the market" and "we want to protect the local industry" clash head-on. The good translator doesn't wait for the contradiction to explode in the middle of the negotiation: they detect it beforehand, point it out to their leader in private —"sir, these two goals you want don't fit together at maximum; which weighs more if we have to choose?"— and thus prepare a negotiation with the conflicts already identified and ordered by importance.

That translator does exactly what the architect does with business goals, and that's why the job is to translate them all together into a single table. If the architect translated "grow 10x" in one meeting and "don't triple the bill" in another, they'd never see that the two fight each other. It's when you put them together —with their weight, with the attributes each one pushes— that it becomes evident that one attribute is backed by three goals (weighs a lot) while another is backed by a single one (weighs little), and where the conflict jumps out: "grow 10x" pushes scalability up, "don't triple the bill" pushes cost down, and those two forces are going to meet head-on. This step is the translator who prepares the negotiation: they translate all of leadership's wishes into attributes, see which reinforce each other, and discover which clash —so the architect arrives to design with the conflicts already named and ordered—.

Worked example: the goal → attribute mapping of the change

We're going to execute the translation on the six goals of Mercado's change. The data structure has three parts, all fixed for reproducibility: the business weight of each goal (1 = nice-to-have, 5 = strategic), which attributes each goal implies and with what strength (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. We rank, and detect which conflict weighs most. It's the same engine as module 5, applied now as step 2 of the capstone.

# Capstone: Mercado's business change -- open to external sellers via API
# and grow 10x. We reuse the engine of lesson 2 of module 5 (goal->attribute mapping,
# prioritized + conflict detection). It's the SAME method, on the flagship change.

# The goals of the change, with their business weight (1=nice-to-have .. 5=strategic).
business_goals = {
    "open_to_external_sellers": 5,   # open the marketplace to third-party sellers via API
    "grow_10x":                 5,   # handle 10x the catalog and the traffic
    "survive_black_friday":     4,   # withstand the spike without going down
    "protect_payment_data":     5,   # harden the payment data
    "keep_infra_costs_flat":    3,   # don't triple the infrastructure bill
    "instant_checkout":         3,   # the checkout can't get slow
}

# 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)}")

tensions = [
    ("scalability",  "cost"),
    ("security",     "performance"),
    ("availability", "performance"),
    ("availability", "cost"),
]

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:
    print(f"  {a} ({score[a]}) vs {b} ({score[b]})  ->  combined weight {score[a] + score[b]}")

print()
top = ranked_tensions[0]
print(f"The conflict that weighs MOST: {top[0]} vs {top[1]}.")
print("That's the trade-off that governs the change: grow 10x (scalability) against")
print("not tripling the bill (cost). The HOW to resolve it is architecture-decisions.")

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 MOST: scalability vs cost.
That's the trade-off that governs the change: grow 10x (scalability) against
not tripling the bill (cost). The HOW to resolve it is architecture-decisions.

Read the ranking first, because it's the change's compass. Scalability leads with 38, and the right-hand column says why: three goals back it, and two of them are the most strategic (weight 5) —opening to external sellers and growing 10x—. It's not that the architect likes to scale; it's that this change, by its nature, pushes scalability more than any other attribute. The number is traceable: 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. When in lesson 4 someone asks "why did we design a team dedicated to scaling the sellers surface?", the answer isn't an opinion: it's this sum. That's the job of step 2: giving the structure a defensible direction.

Notice security, second with 30. It appears high even though only two goals back it, because both are weight 5 and strength 3 (open to third parties = handling untrusted external actors; protect payment data). This is a key datum for the change: opening to external sellers isn't only a scale problem, it's a security problem —people from outside enter the system—, and the mapping captures it without the architect imposing it. When in lesson 5 the ADR justifies putting a gateway with third-party auth in front of the Seller API, this 30 is its backing. And availability (25), performance (23), and cost (19) close the ranking, each traceable to its goals. Watch out for cost in last place: as module 5 taught you, last doesn't mean it doesn't matter. The CFO put "don't triple the bill" at weight 3, explicitly. Cost is last because fewer goals push it and with less strength than scalability, not because it can be ignored —it means "when cost fights against scalability, scalability has more business backing", which is different information from "forget about cost"—.

And that's where the second half of the output comes in, where the mapping stops describing and starts warning. The system detected four pairs of competing attributes and ordered them by combined weight. The one that weighs most is scalability (38) vs cost (19), with combined weight 57. Translated to the business: the flagship goal "grow 10x" (which pushes scalability) and the CFO's explicit goal "don't triple the bill" (which pushes cost) contradict each other head-on, and since between the two they sum the most weight, that's the trade-off that governs the whole change —the one the architect has to face first—. It's not a theoretical clash between two abstract -ilities: they're two concrete leadership sentences that can't both be fulfilled at maximum. This is the conflict that will reappear in lesson 5 (the ADR names it as the accepted price), in lesson 6 (the evolution defers the expensive 10x until the volume justifies it) and in lesson 8 (the script with the VP is built around it). Step 2 doesn't only prioritize attributes: it identifies the hard conversation the architect will have to have with the VP, and leaves it named and quantified from now.

Deep dive: why this step anchors the whole thread

It's worth pausing on three things that make this step the axis of the capstone, because a beginner architect treats it as a formality and misses its value.

First, the ranking takes away from the architect a decision that isn't theirs to make. Without this method, when the time comes to choose between scaling and saving, the architect would carry a business decision disguised as a technical one —and when it went wrong, they'd carry 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 VP disagrees, the right conversation isn't "the architect got it wrong" but "let's review the weights" —and that's healthy, because it puts the strategic decision where it should be—. In the capstone this is doubly important: the ranking is what the architect will be able to show the VP in lesson 8 so the conversation is about business weights, not technical preferences.

Second, the ranking is the input of the structure, not an end in itself. This is the point that distinguishes the capstone from doing module 5's project in isolation. There, the ranking was the deliverable. Here, the ranking feeds step 3: that scalability is the governing attribute is what tells the inverse Conway maneuver what architecture to produce —a sellers surface that scales independently, with its own owning team—. If you had derived security as governing (as in module 5's installment payments project), lesson 4 would design another organization. That's why the ranking isn't stored in a drawer: it's the first link that ties down the next one. An architect who derives scalability and then designs an organization that doesn't produce it broke the thread at its most important joint.

Third, the ranking captures the explicit and that's why it has a blind spot. This method ranks the attributes the goals name. But there are attributes no goal names that the system must meet anyway —data integrity, auditability, privacy—. In this ranking they don't appear, because their score would be zero. That doesn't mean they don't matter: it means the mapping of explicit goals isn't complete by itself, and it has to be complemented with the discovery of the implicit attributes (lesson 5 of module 5). In the capstone, those implicit ones reappear in the ADR (which mentions the security of third parties as a domain attribute) and in the evolution plan (which includes seller_risk_scoring, an integrity attribute no goal asked for by name). The architect who treats this ranking as the complete list of what the system needs delivers exactly what the business asked for and none of the attributes it took for granted —and those are precisely the ones that explode—.

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 by the architect, made explicit. Someone could debate whether grow_10x implies scalability with strength 3 or 2, and that debate would change the ranking. But that's precisely the value of the method: it makes the judgment explicit and debatable. Instead of an architect who decides by eye and no one knows why, there's a table where every assumption is in plain sight and the business can correct it. The number doesn't claim to be exact; it claims to make the conversation possible. A debatable and traceable ranking is infinitely better than a hunch no one can examine.

Common mistakes

Deriving the attributes the architect wants, not the ones the goal pushes (of technical bias). What happens: the architect is passionate about scalability, so they put it first "because this change is going to grow" without verifying that the goals back it more than the other attributes. Sometimes they're right (here scalability does lead), but for the wrong reason, and in the next change they'll put scalability first too, when maybe it doesn't apply. Why it happens: it's natural to prioritize what one masters. How to spot it: if your ranking would be the same for any change of any company, it's not anchored in these goals. How to fix it: let the ranking come out of the mapping with the business's weights, not out of your instinct; in module 5's project, the same company with another goal (installment payments) gave security dominating and scalability at zero —proof that the method is faithful to the goal, not to the architect—.

Translating the goals one by one and losing the conflicts (of isolation). What happens: the architect translates each goal in its own meeting and never puts them in the same table, so they never see that "grow 10x" and "don't triple the bill" contradict each other. The scalability-vs-cost conflict explodes late, in implementation, when it's already expensive and when the VP is surprised that "you couldn't have everything". Why it happens: the goals arrive at different moments, from different people. How to spot it: if you don't have a single view with all the goals and all the attributes together, you couldn't have detected the conflicts. How to fix it: translate all the goals at once (like the translator who prepares the whole negotiation) and run the conflict detection —the clashes are only visible when everything is together, and detecting them now is what prepares the conversation with the VP of lesson 8—.

Treating the ranking as the final deliverable instead of the input of the structure (of a loose link). What happens: the architect derives an impeccable ranking, stores it, and then designs the structure of step 3 without looking at it again —designing the teams "as they see fit" instead of to produce the governing attribute—. Why it happens: in the module projects the ranking was the end, so the reflex is to treat it as a goal, not as a means. How to spot it: if the organization you design in lesson 4 isn't justified with the attribute that led here, you broke the thread. How to fix it: remember that in the capstone the ranking feeds; before designing the structure, say aloud "the governing attribute is scalability, so the organization has to produce a surface that scales" —and let that sentence govern step 3—.

Exercises

Exercise 1 — Recalculate with a new weight. Mercado's CFO, worried about the 10x spend, raises the weight of keep_infra_costs_flat from 3 to 5. Without running all the code, calculate the new score of cost and explain how its position in the ranking changes and how much the governing conflict now weighs.

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. The ranking would be roughly: scalability 38, security 30, cost 25 and availability 25 (tie), performance 23.

How much the governing conflict now weighs. The scalability-vs-cost conflict, which was already the one that weighed most (57), now weighs 38 + 25 = 63 —even more urgent—. And here's what matters for the capstone: that increase changes the conversation with the VP (lesson 8). With cost at weight 5, the architect can no longer treat "don't triple the bill" as a secondary concern; the expensive 10x weighs almost as much as the 10x itself, and that will push the evolution plan (lesson 7) to defer the expensive infrastructure even more aggressively until the real volume justifies it. The lesson: when the business changes a weight, the whole thread rearranges downward —another ranking, another emphasis on the evolution, another conversation—. The method is the same; the content is faithful to the current business.

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. How can a single goal push two attributes that fight each other? What does that reveal about the conversation awaiting the architect with the VP?

See solution

A single goal pushes conflicting attributes because a business goal is usually, at bottom, a wish to have it all. "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 VP doesn't see it as a contradiction: they see it as a single reasonable aspiration ("grow efficiently"). It's the architect, when translating, who discovers that within that single sentence live two attributes pulling in opposite directions.

What it reveals about the conversation with the VP. That the hard conversation isn't between the architect and the business, but inside the business's own goal. The architect isn't going to tell the VP "your goal is wrong"; they're going to tell them "your goal to grow 10x contains, without it showing, a trade-off: scaling and saving at once can't be done at maximum, so I need you to tell me which weighs more when they clash". That question —uncomfortable because it forces the VP to choose something they thought they could have complete— is exactly the job of lesson 8 (the script with the VP). The mapping makes it possible: when a goal implies two attributes that are on the conflict list, the architect has a trade-off to negotiate within a single goal, and arrives at the conversation with the number (combined weight 57) in hand instead of with an intuition. Detecting this in step 2 is what prevents the conflict from exploding without warning in implementation.

Exercise 3 — Predict how the ranking dictates the structure. The governing attribute of this change turned out to be scalability (38). In lesson 4 you're going to design the organization. Without doing the Conway calculations yet, predict: what kind of organizational decision should a governing attribute of "scalability" produce for the sellers surface? And contrast: what different decision would it produce if the governing one had been "security"?

See solution

If the governing one is scalability, the organization must produce a surface that scales independently. The attribute "scale the sellers surface to 10x" points to a clear organizational decision: give the sellers surface a single owning team that can change and deploy autonomously, without coordinating with the other four squads for every adjustment —because a component that many teams share can't scale fast, since every change demands coordination—. This is exactly the inverse Conway maneuver you'll see in lesson 4: to obtain a surface that scales independently, a stream-aligned team is created that owns it end to end. The attribute dictates the shape of the organization.

If the governing one had been security, the organizational decision would be different. A governing attribute of "security" (protect sensitive data, isolate third parties) would point less to a team-that-scales and more to a cross-cutting security capability: perhaps an enabling or platform team that provides the security controls, the auth, the auditing, as services the others consume; or boundaries designed around data isolation (who can touch what) rather than around the value flow. The structure would be optimized to minimize the risk surface and centralize the controls, not to maximize a surface's speed of change.

The lesson: the ranking of step 2 isn't a decoration that's stored —it's what determines the shape of the organization of step 3—. The same change, with a different governing attribute, would produce a different architecture and organization. That's why the thread is causal and the order matters: deriving the governing attribute well is what makes the structure you design later solve the right problem. An architect who skipped this step and structured teams "by intuition" would be designing the organization without knowing what attribute it has to produce —reorganizing blind—.

Summary and next step

In this lesson you did step 2 of the deliverable: deriving the quality attributes from the goal. With the UN translator who prepares the negotiation by detecting the conflicts before they explode, you understood why you have to translate all the goals together —only that way do you see which attributes reinforce each other and which clash—. You measured it by executing: the weight × strength mapping of the six goals of the change produced the ranking (scalability 38, security 30, availability 25, performance 23, cost 19), with each point traceable to a concrete goal, and the conflict detection revealed scalability-vs-cost (57) as the trade-off that governs the change —the contradiction between "grow 10x" and "don't triple the bill"—. You understood that the ranking comes from the business and not from the architect, that this step anchors the thread because the governing attribute dictates the structure of the next step, and that the mapping captures the explicit but leaves a blind spot (the implicit) that will reappear later.

Before moving on you should be able to: take a change's goals with their 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; name the conflict that governs the change and how much it weighs; and explain how the governing attribute dictates the shape of the organization to come.

What follows is step 3, where the governing attribute becomes structure. You already know scalability is what this change must produce; lesson 4 teaches you to design the organization that will produce it. You're going to apply the inverse Conway maneuver to the sellers surface: create a stream-aligned team that owns it end to end and turn the platform into a service, and you're going to measure —executed— how much the system's coordination friction drops by doing it, without touching the code first. The ranking you derived here is the justification for that restructuring: the organization is designed to produce the attribute the goal prioritized.

Resources

← Previous2. Frame the role and the assignmentNext →4. Apply the inverse Conway maneuver