Module 5: Stakeholders and Quality Attributes

8. Project: derive Mercado's quality attributes for a launch

Next →

Overview

This is your graduation from the module. Over seven lessons you learned to translate business goals into prioritized quality attributes (2), to make them measurable with scenarios (3), to filter the ones that shape the architecture (4), to discover the implicit ones no one asks for (5), to speak the stakeholder's language by translating trade-offs to money (6), and to say no —or "yes, but it costs this"— when everything doesn't fit (7). You saw all that applied to one situation: Mercado's external-vendors strategy. Now it's your turn, from scratch, over a different situation —a launch we didn't analyze in the lessons—. The reason for changing the case is the usual one and it's tough: if I let you re-derive the external-vendors attributes, I wouldn't know whether you learned the method or memorized the answer. With a new case, the only way to solve it is to apply the method —and that is, exactly, the proof that the module worked—.

And this new case hides a lesson the lessons couldn't teach so clearly: the same company, with a different goal, produces completely different attribute priorities. In external vendors, scalability led. In this launch —installment payments— you'll see security dominate and scalability fall to zero. It's not that the method is inconsistent; it's that the method is faithful to the business, and this is another business within the same Mercado. If you finish the project with the external-vendors ranking in your head, you failed; if you finish discovering that this launch asks for something else, you learned that what transfers is the method, not the recipe.

Your deliverable is four artifacts for the new launch: (1) the executed goal→prioritized-attribute mapping, with its conflicts, in Python; (2) the ASRs filtered from a list of requirements; (3) the discovered implicit attributes; and (4) the script of the conversation with the CFO, translating the main trade-off into their language. No part requires building the system: it's pure derivation and conversation work —translate, prioritize, filter, discover, communicate—, which is exactly what separates an architect who understands their stakeholders from one who only draws boxes. Build it yourself first; reading the reference solution without having attempted it is like reading the score of a game you didn't play.

Connection with the module: this project closes the arc. Lessons 2 to 5 gave you the work on the architect's side (translate, measure, filter, discover); lessons 6 and 7 gave you the conversation (speak in their language, say no). Here you produce the four artifacts with your own hands, from beginning to end, over a new case. And with this lesson the module closes: at the end is the summary of the eight lessons and the bridge to module 6, where you'll learn to design for change —because the attributes you prioritize today aren't the ones the business will ask for tomorrow, and the architect plans for that evolution—.

The project case: Mercado launches installment payments (BNPL)

The new situation —yours to solve— is this:

Mercado wants to offer installment payments at checkout: the Buy Now, Pay Later (BNPL) model, where the buyer takes the product home today and pays in installments, and Mercado (or a financial partner) assumes the credit. Leadership sees it as the next big conversion lever. Your job as architect is to take the launch's business goals and derive the prioritized quality attributes, the requirements that really matter, what no one asked for but has to be built, and prepare the conversation with the CFO —who is nervous, because this involves lending money—.

The launch's goals, with their business weight (given to you by leadership, so you don't have to invent them):

  • launch_bnpl (weight 5) — offer installment payments at checkout. The bet.
  • instant_credit_decision (weight 4) — decide whether to approve the buyer's credit in under 2 seconds, or the conversion drops.
  • no_fraud_losses (weight 5) — not lose money to fraud or to badly-evaluated defaults. This is Mercado's real money at risk.
  • regulatory_compliance (weight 5) — comply with the country's financial regulation (lending money is heavily regulated).
  • keep_conversion_high (weight 3) — the BNPL flow must not slow down or complicate the checkout.

Notice the difference in nature from the external-vendors case: that one was a growth bet (more vendors, more catalog, more traffic → scalability). This is a financial and regulated bet (lending money, deciding credit, avoiding fraud, complying with the law → something completely different). Your method should capture that difference without you imposing it by hand —it should come out of the mapping—. Don't re-teach how a credit-scoring model or a payment gateway works —that's for other guides—; your job is to derive the attributes and prepare the conversation for this launch.

What you have to deliver

Follow the steps in order; each one leans on the previous.

Part 1 — The goal → prioritized-attribute mapping (executed)

Write and run the Python that maps the five BNPL goals to prioritized attributes, with the lesson 2 method (weight × strength, ranking, and conflict detection by combined weight). You assign which attribute each goal implies and with what strength —it's your judgment, make it explicit—. Deliver the real ranking, run, and name the conflict that weighs the most.

Part 2 — The filtered ASRs

Take a list of the launch's requirements (invent it reasonably, mixing structural and trivial things) and run the lesson 4 filter (the three questions: does it shape the structure? expensive to change? high-risk?). Separate the ASRs from the noise and justify the borderline cases.

Part 3 — The discovered implicit attributes

Build the domain's tacit contract (installment payments = money + credit + regulation) and compare it against what the explicit goals named (lesson 5). Deliver the gap: the attributes no one asked for but the domain demands, with the catastrophe each one prevents.

Part 4 — The script of the conversation with the CFO

Take the main conflict you detected in Part 1 and write how you'd explain it to the CFO in their language (lesson 6), and how you'd tell them "I can't give you everything at the maximum" with the prioritization that does fit (lesson 7). The CFO is nervous about the financial risk: talk to them in money and risk.

The rubric

Here's how the project is evaluated. It's not by length or elegance: it's by whether the derivation is well done and the conversation well prepared, with evidence.

CriterionDoesn't meetMeetsExcels
Executed mappingRanking cited from memory or inventedRanking run in Python with weight × strengthAlso detects the conflict that weighs the most and explains it
Filtered ASRsAll-or-nothing treated as significantSeparates ASR from noise with the three questionsAlso catches an ASR disguised as a trivial requirement
Implicit attributesOnly what the business asked forDiscovers the tacit-contract gapAlso justifies each implicit one by its concrete catastrophe
Conversation with the CFOTechnical jargon or promises everythingTranslates the trade-off to money/riskAlso says "no at the maximum" with the prioritization that does fit

The criterion that weighs the most, and the one that separates an architect from a box-drawer, is the executed mapping: if you deliver everything else but the ranking came out of your head and not from running the code, you didn't derive —you asserted with invented figures, which is worse, because it fakes rigor—.

The reference solution

Attempt the whole project before continuing. What follows is one correct solution, not the only one —especially in the weight and strength assignments, which are arguable judgments—.

Part 1 — The executed mapping

# Project: a NEW Mercado capability -- installment payments (Buy Now, Pay Later).
# Same company, different goal: the prioritized attributes come out VERY different.
# We reuse the lesson 2 method (goal->attribute mapping + conflicts).

# The BNPL launch's goals, with their business weight (1..5).
business_goals = {
    "launch_bnpl":             5,   # offer installment payments at checkout
    "instant_credit_decision": 4,   # approve/reject the credit in < 2 s
    "no_fraud_losses":         5,   # not lose money to fraud / defaults
    "regulatory_compliance":   5,   # comply with the country's financial regulation
    "keep_conversion_high":    3,   # the flow must not slow the conversion
}

# Which quality attribute(s) each goal implies, and with what strength (1..3).
implies = {
    "launch_bnpl":             {"security": 3, "availability": 3, "performance": 2},
    "instant_credit_decision": {"performance": 3, "availability": 2},
    "no_fraud_losses":         {"security": 3},
    "regulatory_compliance":   {"security": 3},
    "keep_conversion_high":    {"performance": 2, "availability": 1},
}

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

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("BNPL -- 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]]
    backers_str = ", ".join(backers) if backers else "(no goal asks for it)"
    print(f"{i:>2}  {attr:<13}{score[attr]:>6}   {backers_str}")

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

print()
print("Conflicts between attributes, 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 the MOST: {top[0]} vs {top[1]}.")
print("In BNPL the architect doesn't fight scalability vs cost (like in external")
print("vendors): it fights anti-fraud SECURITY vs credit-decision SPEED.")
print("Same company, different goal, opposite priorities: the method, not the recipe.")

What to expect. Running it:

BNPL -- quality attributes prioritized by their business backing:
 #  attribute      score   backed by (goals)
 1  security         45   launch_bnpl, no_fraud_losses, regulatory_compliance
 2  performance      28   launch_bnpl, instant_credit_decision, keep_conversion_high
 3  availability     26   launch_bnpl, instant_credit_decision, keep_conversion_high
 4  scalability       0   (no goal asks for it)
 5  cost              0   (no goal asks for it)

Conflicts between attributes, by combined weight:
  security (45) vs performance (28)  ->  combined weight 73
  availability (26) vs performance (28)  ->  combined weight 54
  availability (26) vs cost (0)  ->  combined weight 26
  scalability (0) vs cost (0)  ->  combined weight 0

The conflict that weighs the MOST: security vs performance.
In BNPL the architect doesn't fight scalability vs cost (like in external
vendors): it fights anti-fraud SECURITY vs credit-decision SPEED.
Same company, different goal, opposite priorities: the method, not the recipe.

Read the ranking and notice how revealing it is compared to the lessons' case. Security dominates with 45 —well above everything—, because three of the five goals push it with maximum strength: launching BNPL (handling financial and credit data), not losing money to fraud, and complying with the financial regulation. Lending money is, at bottom, a security and trust problem before anything else, and the mapping captures it without you imposing it —it comes out of the goals—. Performance (28) and availability (26) come next, almost tied, pushed by the instant credit decision and by not slowing the conversion. And most strikingly: scalability and cost end up at zero —no goal of this launch pushes them—. In the external-vendors case, scalability led with 38; here it doesn't appear. Not because Mercado stopped caring about scaling, but because this specific launch isn't about volume growth: it's about lending money securely and fast. The method is faithful to the goal, and the goal changed, so the ranking changed completely.

That contrast is the project's central lesson: the same method, over the same company, with a different goal, produces an opposite ranking. An architect who arrived at this launch assuming "in Mercado what matters is scaling" (the previous case's conclusion) would have prioritized exactly what this launch does not need, and neglected the security that dominates everything. The method exists precisely to prevent that: it forces you to derive the attributes from this launch's goals, not to drag over the previous one's conclusions. What transfers between cases is the method (map, prioritize, detect conflicts); the answers are different each time because the business is different each time.

And the conflict that weighs the most confirms it: security (45) against performance (28), with combined weight 73. Translated to the business: the BNPL architect has to reconcile the anti-fraud security (thoroughly reviewing each credit request so as not to lend to a scammer or someone who won't pay) with the speed of the decision (approve in under 2 seconds, or the buyer abandons). Those two pull head-on: security wants more review (slower), conversion wants less wait (faster). It's a different trade-off from the previous case (where it was scalability vs cost), and it came straight from the goals. That's the conflict to resolve first —and its rigorous resolution (how much review, with what scoring method, accepting what fraud-risk level in exchange for what speed) is architecture-decisions's method; your job here was to detect and quantify it—.

Part 2 — The filtered ASRs

A reasonable list of the launch's requirements, run through the three-question filter:

requirementshapes?costly?risk?signalclassification
Keep the trail of every credit decision (for the regulator)1113/3ASR
Isolate and protect the buyer's financial data1113/3ASR
Decide the credit in under 2 seconds1102/3ASR
Integrate the credit-scoring model1113/3ASR
Show the installment plan with a calendar icon0000/3noise
The button text: "Pay later" vs "Pay in installments"0000/3noise
Be able to reverse/cancel a credit already granted1113/3ASR

Five ASR and two noise. The ASRs are where the architect puts their energy: keeping the trail of decisions (regulatory auditability —shapes how and where everything is stored, very expensive to retrofit, risk of a fine—), isolating financial data, the sub-2-second decision (2/3: it shapes the structure of the credit flow and is expensive to change, even if it's not catastrophic —the lesson 4 borderline case—), integrating the scoring, and being able to reverse a credit (it touches transactional integrity and compliance). The noise —the calendar icon, the button text— the product team decides; the architect doesn't get in.

The disguised ASR (to excel): "be able to reverse/cancel a credit already granted" sounds like a product feature ("a cancel button"), but it's deeply structural: reversing a granted credit implies undoing a financial transaction that already moved money, was already reported to the credit bureau, maybe already generated installments —it's a transactional-consistency, operation-compensation, and compliance problem, not a button—. It's the project's "little Excel-export button": it arrives dressed as trivial and it's knocking down a wall.

Part 3 — The discovered implicit attributes

The tacit contract of "installment payments" (money + credit + regulation), compared against what the goals named:

The explicit goals named: security, performance, availability (from the ranking). The domain also demands attributes no goal asked for:

  • auditability — every credit decision and every money movement must be traceable for years. Catastrophe it prevents: that the regulator investigates a discriminatory lending practice or a money-laundering case and there's no trail —a fine and a sanction—. (Note: the goals include regulatory_compliance, which implies it, but auditability as a technical capability no one asked for by name.)
  • data_integrity — a granted credit can't be lost, duplicated, or left in an inconsistent state (approved but not recorded, or charged twice). Catastrophe it prevents: charging two installments at once, or "losing" a credit and never charging it —direct money loss and furious customers—.
  • fairness / non-discrimination (model fairness) — the scoring model can't illegally discriminate by protected characteristics. Catastrophe it prevents: a credit-discrimination lawsuit, an enormous legal and reputational risk, specific to lending money with a model.
  • recoverability — if the system fails mid-credit-decision or mid-charge, it must recover without leaving money in limbo. Catastrophe it prevents: "half-granted" credits after an outage, impossible to reconcile.
  • privacy — the buyer's financial data protected per the personal-data law. Catastrophe it prevents: a financial data leak, with the fines and the loss of trust that implies in a credit product.

Five implicit attributes, none asked for, all heavy. Notice the model fairness: it's an implicit one specific to this domain (lending with an algorithm) that didn't exist in the external-vendors case —each domain has its own tacit contract—. An architect who only delivered the three explicit ones (security, performance, availability) would leave out the regulatory auditability, the transactional integrity of the money, and the model fairness —three legal bombs waiting—.

Part 4 — The script of the conversation with the CFO

The CFO is nervous because this involves lending Mercado's money. The main conflict is security (anti-fraud) vs performance (decision in 2 seconds). I explain it in their language —money and risk—, and I tell them "no at the maximum for both":

"The technical heart of BNPL is a tension that will matter directly to you, because it's about your money. On one side, to not lose money, we have to properly review who we lend to —detect fraud, evaluate whether the person will pay—. The more thoroughly we review, the less money we lose to defaults and scams. On the other side, if the review takes too long, the buyer abandons the checkout and we lose the sale —and conversion is precisely why we're launching this—. More security protects your money but slows the sale; more speed captures the sale but lets more risk through. We can't have both at the maximum: an instant and perfect review at the same time doesn't exist.

What I propose isn't choosing one and sacrificing the other, but a point where both coexist: a first automatic evaluation in under 2 seconds that approves the vast majority of low-risk customers instantly (we protect the conversion), and a deeper review —of seconds or minutes— only for the cases the model flags as doubtful (we protect your money where the real risk is). That way we don't slow the 95% of good buyers because of the 5% suspicious ones.

And I want to be honest about what we're not maximizing. This launch prioritizes the security and the speed of the credit, which is where your money and the conversion are. We're not optimizing to scale to a giant volume nor to minimize the infrastructure cost —those aren't the priorities of this product, and putting effort into them now would be spending where it doesn't yield—. If BNPL takes off and the volume shoots up, we re-prioritize and talk about scaling then. For now, every unit of effort goes to not losing money and not losing the sale. I can show you, for each level of anti-fraud review, how much default risk it covers and how much conversion it costs, so you decide where we draw the line."

Why it works: it translates the security-vs-performance conflict into the two things the CFO understands (risk of losing lent money, and lost sales from friction), proposes a concrete middle point instead of an impossible maximum, explicitly names what's not prioritized (scalability and cost, the ranking's zeros) so there are no surprises, and offers the numbers so they decide where the line goes —the two-way direction of translation, the "no at the maximum" of lesson 7, and the respect for the frontier (the architect presents, the business decides)—.

Exercises

These exercises transfer the method to other Mercado decisions, so you confirm you learned to derive attributes and not to repeat a case.

Exercise 1 — Change a goal and observe the ranking. Leadership adds a sixth goal to BNPL: "prepare to process 50x the credit volume in two years, because we want BNPL to be massive" (weight 5, implies scalability with strength 3 and cost with strength 2). Without running all the code, compute the new score of scalability and explain how the ranking and the main conflict change.

See solution

New scalability score. Before it was 0 (no goal pushed it). The new goal implies it with strength 3 and has weight 5: 5 × 3 = 15. New scalability score = 15. The new cost score = 5 × 2 = 10 (before 0).

How the ranking changes. Scalability jumps from 0 (last) to 15, surpassing the previous scalability and cost but staying still below availability (26), performance (28), and security (45). The ranking would be approximately: security 45, performance 28, availability 26, scalability 15, cost 10. Scalability stopped being irrelevant and became a medium-weight attribute.

How the main conflict changes. The security-vs-performance conflict (73) is still the one that weighs the most —that new goal doesn't touch it—. But the scalability vs cost conflict appears with force (now 15 + 10 = 25, before 0): "we want to be massive" (scalability) against a cost the CFO watches (cost). It doesn't dethrone the main one, but it's now a real trade-off that before didn't even exist.

The lesson: adding a goal reintroduced an attribute that was at zero. This shows why the ranking is recomputed every time the business changes its goals —and why the same launch, with one more goal, is no longer the same architecture problem—. The method doesn't give a fixed answer; it gives an answer faithful to the current goals.

Exercise 2 — The disguised ASR, again. The BNPL team gets this requirement: "let the user change their installment plan from 3 to 6 months after having bought". The product manager presents it as "a minor adjustment on the my-account screen". Would you run the ASR test on it? Argue what it hides and classify it.

See solution

Yes, I'd run the test on it —and it's not a minor adjustment—. "Change the installment plan after buying" touches money, already-granted credit, and compliance; it's exactly the kind of requirement that arrives disguised as trivial. The three questions:

  • Does it shape the structure? Yes. Changing a plan from 3 to 6 months means recomputing the installments, readjusting the charge schedule, possibly recomputing interest, updating what's reported to the credit bureau, and maintaining consistency between the original credit and the modified one. It's not changing a number on a screen; it's modifying an active credit contract, which requires a whole machinery of transactional modification.
  • Expensive to change later? Yes. If the system was designed assuming an installment plan is immutable once granted, adding the mutability later is a deep refactor of the financial core.
  • High-risk? Yes. An error recomputing installments or interest is charging a customer wrong —a financial, legal, and trust problem—, and badly modifying what's reported to the bureau can damage a person's credit history.

Classification: ASR (3/3), and a heavy one. It's the disguised ASR in the flesh: presented as "a minor adjustment on the my-account screen", it hides one of the most delicate capabilities of a credit system (modifying active contracts with money involved). Dispatching it as product noise would be the expensive mistake of lesson 4. The rule holds again: every requirement that touches money, credit, or compliance deserves the test, however trivial its presentation sounds.

Exercise 3 — The CFO again, another answer. Suppose that, after your proposal, the CFO says: "I'm not convinced about approving automatically in 2 seconds; the fraud risk scares me. I want all the requests to go through deep review, no exception, even if they take a while". With the method, argue why "deep review for all" is lesson 7's "everything at the maximum" applied to security, and how you'd answer with a "yes, but it costs this".

See solution

Why it's "everything at the maximum". "Deep review for all requests, no exception" is maximizing anti-fraud security without considering its cost in the other priority attribute: the conversion (performance/speed). It's exactly the impossible request of lesson 7, only instead of "all attributes at 5" it's "one attribute at 5 ignoring what it fights". And it fights precisely with the product's reason for existing: if every request takes minutes in review, the vast majority of buyers —the good ones, who are the huge majority— abandon the checkout, and BNPL doesn't meet its conversion goal. Maximizing security destroys the launch's business value.

The "yes, but it costs this" answer: "I understand the fear, and you're right that fraud is a real risk to your money. Yes, we can thoroughly review all the requests —but let me tell you what it costs, because it's a lot—. If all of them go through deep review, the decision no longer takes 2 seconds but minutes, and per the industry data, each extra second of checkout friction drops the conversion. Concretely: we'd probably lose [X%] of the BNPL sales —good, low-risk people, who get tired of waiting and buy without installments or don't buy—. We'd be indirectly rejecting the 95% of good customers out of fear of the 5% suspicious ones.

The alternative that protects your money without killing the conversion is the tiered review: the model approves instantly the customers it evaluates as clearly low-risk (the majority), and sends to deep review only the ones it flags as doubtful. That way, the anti-fraud effort falls where the real risk is, and we don't punish the good buyers. I can show you, with data, how much fraud each threshold level catches and how much conversion it costs —and you'll see that reviewing-everything catches a little more fraud in exchange for losing a lot of good sales—. The decision of where to put the threshold is yours; I just want you to make it seeing both columns, not only the fear-of-fraud one."

Why it works: it names that "review everything" is maximizing an attribute ignoring its conflict (lesson 7), translates the cost to what the CFO understands (lost conversion = lost sales), offers the alternative (tiered review) that gives better business value, and returns the decision with the numbers —without usurping it and without caving to the fear reaction—. It's the "yes, but it costs this" in its most useful form: it doesn't block the CFO's wish, it puts a price on it and offers them a better path.

Module summary and where you go next

With this project you close module 5, where architecture touches the business. You started with the thesis —architecture decisions come from the business goals, and the architect's first job is to translate those wishes into quality attributes— and the house architect who turns "grow old here" into concrete requirements (lesson 1). You executed the complete translation, mapping Mercado's goals to prioritized attributes (scalability 38, security 30…) and detecting their conflicts (lesson 2). You made the vague measurable with the six-part quality attribute scenario, and the hard rule —no measure, no requirement— (lesson 3). You separated the signal from the noise with the architecturally-significant requirements, the filter that says where to get in and where to let go (lesson 4). You discovered the implicit attributes no one asks for and everyone expects —the tacit contract of the domain— (lesson 5). You learned to speak the stakeholder's language, translating the nines into dollars —"more availability = more money"— (lesson 6). And you learned to say no —or "yes, but it costs this"—, managing a finite quality budget (lesson 7). Here, in the project, you did it all yourself over a new launch —installment payments—, and confirmed the module's deepest lesson: the same method, over the same company, with a different goal, produces opposite priorities (security dominates, scalability falls to zero). The method transfers; the answers don't.

The capability you take away: facing any business goal, you can derive the quality attributes it implies and prioritize them with evidence, make them measurable, filter the ones that shape the architecture, discover the ones no one asked for, and lead the conversation with the stakeholder who approves them —translating the trade-offs into their language and knowing how to say no—. You stopped treating the business's wishes as instructions to execute literally, and started treating them as the raw material the architect translates, in both directions, so the right architecture gets to exist.

Where you go next, within this guide:

  • Module 6 — Designing for change. You now know how to derive the attributes the business needs today. But the business's goals change —Mercado itself went from external vendors to installment payments, with opposite priorities—, and an architecture tied to today's attributes becomes a cage tomorrow. Module 6 teaches the mental stance of the architect who plans for change, not for permanence: keeping options open, sacrificial architecture, and avoiding both over-engineering and under-engineering. The attributes you prioritized here are a snapshot; module 6 is learning to design knowing the snapshot will change.

And toward the rest of the ecosystem: every time this module detected that two attributes compete (scalability vs cost, security vs performance) without resolving the conflict, it leaned on the guide that does teach how to decide: architecture-decisions-and-tradeoffs —the matrix, the ADR, the fitness function—. Now you have what that guide takes for granted: where the attributes come from, how they're prioritized from the stakeholder, and how the trade-off is discussed with whoever approves it. This module is the entry door to every architecture decision: deriving the attributes well from the business is the input on which it depends that the decision —however rigorous— solves the right problem.

Resources

← Previous7. Knowing how to say no (and the cost of yes)Next →Module introduction: designing for change