Module 5: Stakeholders and Quality Attributes

7. Knowing how to say no (and the cost of yes)

Overview

By the end of this lesson you'll know how to give the craft's hardest answer —and the one that most distinguishes a mature architect from one who wants to be liked—: saying no, or its more honest version, "yes, but it costs this". All the machinery of the previous lessons leads here. You translated the goals to attributes (2), made them measurable (3), filtered the ones that matter (4), discovered the implicit ones (5), and learned to put each in money (6). The inevitable consequence of all that is an uncomfortable truth the stakeholder doesn't want to hear: you can't have everything at the maximum. The budget doesn't reach, and besides some attributes fight each other —maximizing security slows performance; maximizing availability shoots up the cost—. When the VP says "I want it all: maximum availability, maximum security, maximum performance, and make it cheap", they're asking for something that doesn't exist, and the architect who says "sure, we'll try" is lying —an expensive lie that comes due in six months—. You'll execute the demonstration that "everything at level 5" exceeds any reasonable budget (it costs 125 points when there are 60), and how a realistic prioritization —using the lesson 2 ranking— does fit. The architect's "no" isn't "it can't be done"; it's "this is what does fit, prioritized by business value, and this is what each extra level costs".

This matters because a well-given "no" is an act of service, and "yes" to everything is a betrayal disguised as kindness. The architect who promises all the attributes at the maximum so as not to disappoint the stakeholder isn't helping them: they're condemning them to discover, when it's already too late, that the system can't be maximally secure and maximally fast and maximally cheap at once —and by then the budget was spent chasing an impossibility instead of investing it where it mattered—. Saying "yes" to everything feels collaborative in the meeting and is devastating in the execution. Saying "I can't give you everything at the maximum, but I can give you this, which is what your business really needs, and here's the cost of each thing we add" feels uncomfortable in the meeting and is a gift in the execution: it gives the stakeholder a real decision —with real trade-offs— instead of a fantasy. The architect manages a quality budget that is finite, just as finance manages a money one; and their job, like a good financial advisor's, isn't to say "yes" to every expense but to help spend the budget where it yields the most. The "no" is the tool that makes that service possible.

Connection with the module: this lesson is the culmination of the whole arc. It uses the lesson 2 ranking (to know what to prioritize when everything doesn't fit), the lesson 3 scenarios (the concrete levels that get cut or kept), the lesson 2 conflict detection (the attributes that besides being expensive fight each other), and the lesson 6 money translation (to state the cost of each level in the business's language). It's where everything comes together in the final conversation: not "what attributes do we need?" but "given that everything doesn't fit, what do we prioritize and what do you defer, and at what cost?". The frontier stays, and here it's more delicate than ever: this lesson teaches you to communicate that you have to choose and to present the budget trade-off; the rigorous method for making the choice —how to weight, how to decide between 99.9% and 99.99%, how to document it in an ADR— is the architecture-decisions guide. Here you say "you have to choose, and this is what each option costs"; there is the method of how you choose.

The remodeling budget that doesn't stretch to everything

Think about it with the couple remodeling their house, now with the money envelope on the table. They arrive with the complete list of their dreams: chef's kitchen with everything imported, heated pool, solar panels, a home theater, luxury finishes in every bathroom, a landscaped garden, and a home-automation system that controls everything from the phone. The architect sums the costs and does what no obliging salesperson would do: they tell them the truth. "All this costs three times your budget. It doesn't fit. And there's more: some of these things fight each other —the heated pool and the solar panels compete for the same well-oriented roof space; you can't have both at the maximum—." The couple falls silent, uncomfortable. Then the good architect does the second half of their job, the one that justifies their fee: "But I didn't come to tell you it can't be done. I came to help you decide. Tell me what matters most to you —the kitchen, because you cook every day, or the home theater, which you'd use now and then?—. With your budget, there's enough for the chef's kitchen, two luxury bathrooms (not four), the solar panels, and a simple garden. The pool and the home theater we leave prepared for a phase two, when you can. Here's exactly what's in, what's deferred, and how much it would cost to add each thing we left out."

Notice the two halves, because they're the two halves of this lesson. The first is the honest no: "everything doesn't fit, and some things fight". An obliging architect skips it —they say "yes, we'll figure it out" and start building, and halfway through the work the money runs out with the house half-done—. The second is the "this is what does fit": not a bare "no" that leaves the couple without a house, but a prioritization that turns the limited budget into the best possible house for this couple (the one that cooks, so the kitchen wins). The bad one says "yes" to everything and delivers a half-done disaster. The terrible one says a bare "no" and doesn't help. The good one says "no to everything at the maximum, but yes to this —what serves you most—, and here's the cost of each thing you want to add". The software architect does exactly this with the quality budget: they can't maximize all the attributes, so they tell the truth about the limit and propose the prioritization that gives the most business value with what there is —making explicit what's deferred and what it would cost to add it—.

Worked example: "everything at the maximum" against the budget

We'll execute the demonstration. Each attribute can be taken to a level from 1 (minimum) to 5 (excellence), and taking it to a higher level costs —the cost grows quadratically, because climbing the last rung of quality is much more expensive than the first (taking availability from 99.9% to 99.99% costs more than from 99% to 99.9%, as you saw in lesson 6)—. The architecture budget is finite: 60 effort points this year. We compare two scenarios: the stakeholder's request (all the attributes at level 5) against the architect's prioritized proposal (levels according to the lesson 2 ranking).

# "I want it ALL at the maximum": the impossible request. Each attribute has a cost
# that grows fast with the demanded level, and the architecture budget isn't
# infinite. We show that promising everything at 5 is impossible, and how a
# realistic prioritization (the lesson 2 one) does fit.

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

# Cost (in "effort points") of taking an attribute to level n (1..5).
# Grows quadratically: climbing the last rung costs much more than the first.
def cost_of_level(n):
    return n * n            # level 1->1, 2->4, 3->9, 4->16, 5->25

BUDGET = 60                 # effort points available this year (fixed data)

# Stakeholder's request: EVERYTHING at the maximum.
everything_max = {a: 5 for a in attributes}
cost_max = sum(cost_of_level(l) for l in everything_max.values())

# Architect's proposal: levels according to the priority measured in lesson 2.
prioritized = {
    "scalability":     5,   # the #1: gets excellence
    "security":        4,   # very high
    "availability":    3,   # good
    "performance":     2,   # sufficient
    "cost_efficiency": 1,   # the minimum for now
}
cost_prioritized = sum(cost_of_level(l) for l in prioritized.values())

print(f"Architecture budget this year: {BUDGET} effort points")
print()
print("Stakeholder's request -- EVERYTHING at level 5:")
print(f"  cost = 5 attributes x {cost_of_level(5)} = {cost_max} points  ->",
      "IMPOSSIBLE" if cost_max > BUDGET else "fits")
print(f"  exceeds the budget by {cost_max - BUDGET} points ({cost_max / BUDGET:.2f}x).")
print()
print("Architect's prioritized proposal:")
for a in attributes:
    print(f"  {a:<16} level {prioritized[a]}  -> {cost_of_level(prioritized[a]):>2} points")
print(f"  total cost = {cost_prioritized} points  ->",
      "fits" if cost_prioritized <= BUDGET else "does NOT fit",
      f"(margin: {BUDGET - cost_prioritized})")
print()
print(f"The architect's 'no' isn't 'it can't be done'. It's: 'everything at 5 costs {cost_max};")
print(f"we have {BUDGET}. This is what DOES fit, prioritized by business value.'")

What to expect. Running it:

Architecture budget this year: 60 effort points

Stakeholder's request -- EVERYTHING at level 5:
  cost = 5 attributes x 25 = 125 points  -> IMPOSSIBLE
  exceeds the budget by 65 points (2.08x).

Architect's prioritized proposal:
  scalability      level 5  -> 25 points
  security         level 4  -> 16 points
  availability     level 3  ->  9 points
  performance      level 2  ->  4 points
  cost_efficiency  level 1  ->  1 points
  total cost = 55 points  -> fits (margin: 5)

The architect's 'no' isn't 'it can't be done'. It's: 'everything at 5 costs 125;
we have 60. This is what DOES fit, prioritized by business value.'

Look at the stakeholder's request first: everything at level 5 costs 125 points, and there are 60 —it exceeds it by more than double—. That number, 125 against 60, is the whole lesson in one comparison. "I want it all at the maximum" isn't an ambitious request achievable with effort; it's an arithmetic impossibility. And notice why it's so expensive: since the cost grows quadratically, taking each attribute to level 5 costs 25 points —the most expensive rung of all—, and five attributes at 25 are 125. The quadrature is the culprit: level 5 doesn't cost "a bit more" than 4, it costs 25 against 16, and that difference is multiplied by each attribute. The architect who promises "everything at 5" is promising to spend 125 where there are 60, and that promise breaks on its own —the only question is whether it breaks in the meeting (if the architect is honest) or halfway through the execution with the budget exhausted and the system mediocre at everything (if they're not)—.

Now the prioritized proposal, which is the "no" turned into service. Instead of splitting the budget evenly (which would give mediocrity at everything) or promising everything at the maximum (impossible), the architect allocates the budget according to the lesson 2 ranking: scalability, which led, gets excellence (level 5, 25 points); security, second, goes very high (level 4, 16 points); availability, good (level 3, 9); performance, sufficient (level 2, 4); and cost_efficiency, the minimum for now (level 1, 1 point). Total: 55 points, which fits in the 60, with 5 of margin. Notice what this means: the architect didn't say "no" to any attribute —they're all present, none at zero—; they said "no to the maximum on all", and distributed the excellence where the business values it most. The house wasn't left without a kitchen nor without bathrooms; it has a chef's kitchen (the #1 attribute at the maximum) and decent bathrooms (the rest at their fair level). That's prioritizing: not eliminating, but dosing the excellence according to business value.

Stop at the last line of the output, because it's the definition of the well-given "no": "everything at 5 costs 125; we have 60. This is what does fit, prioritized by business value." Compare the three ways of answering "I want it all":

The obliging "yes": "sure, we'll try" —it lies, and delivers a system mediocre at everything when the budget runs out—.
The bare "no": "you can't have everything" —it's right, but doesn't help; it leaves the stakeholder frustrated and with no plan—.
The architect's "no": "not everything at the maximum, but yes this —what your business needs most—, and here's what each extra level you want to add costs" —it tells the truth and proposes the best use of the budget and leaves the final decision in the business's hands—.

The third is the only one that's useful, and it's the hardest to say because it requires making the stakeholder uncomfortable in the meeting (breaking their illusion of "everything at the maximum") in exchange for truly serving them in the execution. The architect's "no" is honest about the limit, constructive about the alternative, and respectful of the frontier —it presents the trade-off, it doesn't usurp the decision—.

An honest nuance about the model. The "effort points", the budget of 60, and the quadratic cost are an abstraction —there's no literal "quality points" currency that finance approves—. In reality, the budget is a mix of money, team time, and tolerable complexity, and the "cost" of a quality level isn't exactly n². So, does the model deceive? No —it captures two truths that are robust and that the architect must internalize—. First: the quality budget is finite, like any budget, and "everything at the maximum" always exceeds it. Second: excellence has diminishing returns and increasing cost —the last rung of any attribute is disproportionately expensive (you saw it literally with the nines in lesson 6)—, so taking everything to the maximum is the worst way to spend the budget. The model doesn't pretend to give you the exact cost in dollars; it pretends to make it undeniable that you have to prioritize, and to give you the way to do it (allocate the excellence according to business value). The exact arithmetic is arguable; the conclusion —you have to choose, and choose by business value— isn't.

Deep dive: the "yes, but it costs this", the named debt, and the conflicts no budget fixes

The "no" has a richer and more-used-in-practice version: the "yes, but it costs this". Rarely does the architect say a flat "no"; almost always they say "yes, that attribute can be added or that level raised —and this is what it costs, in budget, in time, or in some other attribute that will have to go down—". The difference from the obliging "yes" is that the "yes, but it costs this" names the price. When the VP asks to raise availability from level 3 to level 5, the architect doesn't say "no" nor say a bare "yes": they say "yes, raising availability from 3 to 5 costs 16 points more (from 9 to 25), and since the budget is full, we'd have to lower something —for example, security from 4 to 3— or expand the budget; which do you prefer?". That turns the request into a conscious decision with its cost in view, instead of a silent concession paid for later. The "yes, but it costs this" is the "no" in its most useful form: it doesn't block, it informs the price and returns the decision.

A particular case of the "yes, but it costs this" is naming the fast-shortcut's debt. Sometimes the business needs something now —launch before the competition, prove something to an investor—, and the right answer is a "yes" to the shortcut, but a "yes" with the debt named. Not "we'll do it fast" (which hides the cost), but "we'll do it fast by taking this shortcut, and that's a debt: it lets us launch in half the time, but each feature we build later on this base will cost more until we pay it off, and paying it will take us a few weeks down the line". The shortcut can be the right decision —sometimes launching today is worth more than the cleanup—, but only if the business chooses it knowing it's debt. The sin isn't taking the shortcut; it's taking it without naming it, so it blows up later as a surprise "the engineers didn't anticipate". The architect who says "this fast thing has a debt we'll pay off, and here's what it is" turns a dangerous shortcut into an informed business decision. It's the same cost honesty, applied to time instead of money.

And there's a reason "everything at the maximum" is impossible that goes beyond the budget, and it's the one that ties this module with the frontier: some attributes fight, so not even with an infinite budget could you have them all at the maximum. You saw it in lesson 2: security competes with performance (encrypting, validating, and auditing adds latency), availability competes with cost (redundancy costs), scalability competes with cost. These conflicts aren't a money problem —they're intrinsic trade-offs—: raising security to the maximum lowers performance by design, not for lack of funds. So even if the VP said "here, unlimited budget, give me everything at 5", the architect would have to answer "I can't —not because the money doesn't reach, but because maximum-security and maximum-performance are physically incompatible; you have to tell me which weighs more—". This takes the conversation to its purest form: not "how much do we spend?" but "what do you choose when two things you want can't coexist?".

And here, exactly here, is the module's frontier at its most important point. This lesson teaches you to see that you have to choose, to communicate it ("everything doesn't fit; these two also fight"), and to present the options with their cost. But how the choice is made —how the conflicting attributes are weighted, how it's decided that security weighs more than performance in this case, how that decision is structured so it's defensible and recorded in an ADR so it survives— is a rigorous method that's the heart of the architecture-decisions-and-tradeoffs guide. This module takes you to the door of that decision: you derived the attributes from the stakeholder, prioritized them, detected the conflicts, put them in money, and communicated that you have to choose. The decision itself —the act of choosing between the options with a method— is the other guide's work. It's the perfect handoff: here you finish with "you have to choose between security and performance, here's what each one costs and is worth"; there begins "here's how that choice is made rigorously and documented". The "no" of this lesson doesn't resolve the conflict; it names it, quantifies it, and hands it over ready for the decision method to resolve.

Common mistakes

Promising all the attributes at the maximum (of obligingness). What happens: the architect, to not disappoint the stakeholder or to avoid confrontation, says "yes, we'll seek maximum availability, maximum security, maximum performance, and low cost". It's impossible, and the project demonstrates it halfway through: the budget runs out chasing excellence at everything and the system ends up mediocre at everything. Why it happens: saying "yes" feels collaborative and avoids the uncomfortable moment of the meeting; besides, the architect may not have done the arithmetic that shows the impossibility. How to spot it: if your proposal doesn't say which attribute is not at the maximum, you promised the impossible. How to fix it: do the budget arithmetic (like this lesson's), show that "everything at 5" doesn't fit, and propose the prioritization —the "no to the maximum on all, yes to this"—.

Saying "no" without offering the alternative (of sterile negativity). What happens: the architect, proud of their rigor, answers "you can't have everything" and stops there —they think their job was to point out the impossibility—. The stakeholder is left frustrated, with no plan, and with the impression that the architect is an obstacle. Why it happens: honesty about the limit is confused with the complete service; saying "no" is the easy half. How to spot it: if your "no" isn't followed by "but yes this, prioritized this way, at this cost", you gave half the work. How to fix it: the architect's "no" always comes with the prioritized alternative —you're the advisor who helps spend the budget well, not the gatekeeper who only says what can't be done—.

Accepting the shortcut without naming the debt (of silence). What happens: the business asks for something fast, the architect accepts the shortcut without explaining it's debt, and months later the team's speed collapses on that fragile base —and the business blames "the engineers who didn't anticipate"—. Why it happens: naming the debt feels like spoiling the fast-launch enthusiasm, or the architect assumes "it's obvious we have to clean it up later". How to spot it: if you took a shortcut and the business doesn't explicitly know it incurred a debt with a future cost, you hid it. How to fix it: say "yes, and this is debt —it gives us speed today, costs us speed later, and paying it will take this—"; the shortcut with the named debt is a legitimate business decision; the silent shortcut is an expensive surprise.

Exercises

Exercise 1 — Reallocate the budget. With the same budget of 60 points and the quadratic cost (n²), the business changes its mind: now security is the most important (they're going to handle medical data), and scalability can go down. Propose a new allocation of levels to the five attributes that fits in 60 points, with security at level 5, and verify the total.

See solution

A reasonable allocation with security at the maximum and scalability cut:

attribute	level	cost (`n²`)
security	5	25
availability	4	16
performance	3	9
scalability	2	4
cost_efficiency	2	4
total		58

Total = 25 + 16 + 9 + 4 + 4 = 58 points, which fits in 60 (margin of 2).

Notice what changed from the original proposal: the excellence (level 5, 25 points) moved from scalability to security, because the business's ranking changed. Scalability, which before had the 5, is now at 2 —still present, but no longer getting the excellence—. The total budget is almost the same (58 against 55), but distributed according to the new priorities. It's the lesson 2 lesson applied to the budget: when the business changes what it values, the excellence is reallocated, not the budget magically expanded. And observe that it's still impossible to put two attributes at 5 (twice 25 = 50, and with the other three at the minimum —three times 1 = 3— would be 53, which would fit; but barely, and would leave three attributes at level 1, probably insufficient for several). The budget still forces only one or two attributes to reach excellence.

Exercise 2 — The "yes, but it costs this". The VP looks at the original prioritized proposal (scalability 5, security 4, availability 3, performance 2, cost_efficiency 1, total 55) and says: "I love it, but I need availability to be excellent, raise it to level 5". With the numbers, explain what that change costs and give the architect's answer in the form of "yes, but it costs this".

See solution

What the change costs. Raising availability from level 3 to level 5 changes its cost from 3² = 9 to 5² = 25: an increase of 16 points. The budget was already at 55 (with 5 of margin over 60). Adding 16 would take it to 55 − 9 + 25 = 71 points, which exceeds 60 by 11. It doesn't fit without cutting something else or expanding the budget.

The architect's answer ("yes, but it costs this"): "Yes, availability can be raised to excellence. It costs 16 points more, and the budget is already full, so we have three paths, and the decision is yours:

Cut another attribute. We could lower security from 4 to 3 (frees 7 points) and performance from 2 to 1 (frees 3), which almost reaches —but lowering security while handling payments worries me; I'll show you the risk before you decide—. Or lower scalability from 5 to 4 (frees 9 points), which leaves us with less margin for the 10x growth you also asked for.
Expand the budget by about 11 points (in money and time, this means X), if excellent availability is worth that extra cost for the business.
Reconsider the level. Do we really need level 5 (99.99%+) or does level 4 give us the availability the business needs at a much lower cost? Remember the nines table: the last rung costs a lot and avoids little additional sales.

I'm not going to tell you 'it can't be done'; I'm telling you what it costs and what the options are. Which do you prefer?"

Why it's the right answer: it's not a "no" (it would block without helping) nor an obliging "yes" (it would break the budget in silence); it's a "yes, and this is the price, you choose". It names the exact cost (16 points), lays out the paths with their consequences in the business's language, and returns the decision —including the lesson 6 reminder that maybe level 5 isn't worth its cost—. That's managing the quality budget as a service.

Exercise 3 — Name the debt. The business needs to launch the external-vendors pilot in six weeks for an important trade fair, and the full plan (with robust multi-tenancy, security at level 4, observability) takes twelve. The architect proposes a shortcut: launch with basic isolation and without full observability, to make the fair. Is it right to take the shortcut? Write how you'd communicate it to the business so it's an informed decision and not a future surprise.

See solution

Is it right to take the shortcut? It can be —reaching the fair with a functional pilot can be worth more to the business than a perfect system six weeks late—. The rightness of the shortcut isn't the point; the point is that the business chooses it knowing it's debt, not that the architect takes it in silence. A shortcut chosen with knowledge is a valid business decision; a hidden shortcut is a time bomb.

How I'd communicate it (the "yes, with the debt named"): "We can reach the fair in six weeks, yes. To do it we'd take a conscious shortcut, and I want you to decide it knowing exactly what it implies, because it's a debt we'll have to pay:

What we cut to get there: we'd launch the pilot with basic isolation between vendors (enough for a controlled demo with a few trusted vendors, not to open to the public) and without the full alerting system.

What debt we incur: this is fine for a trade-fair pilot with selected vendors, but we can't open it to the general public in this state —the basic isolation is a risk that one vendor sees another's data if it scales, and without alerts we wouldn't find out in time about a problem—. To go from pilot to open production we need the other six weeks of work: the robust multi-tenancy and the observability. It's a concrete debt with a concrete payment plan.

The decision I ask of you: launch the pilot in six weeks for the fair, with the explicit commitment to complete the remaining six weeks before opening it to the public. If you agree with that, it's a responsible shortcut. If instead the intention is to open it to the public right after the fair without paying the debt, then the shortcut is dangerous and we should talk about another plan.

That way, in three months, when we say 'we need six more weeks before opening to the public', it won't be a surprise or a 'the engineers were late': it will be the debt we decided together to incur today."

Why it works: it says "yes" to the shortcut (it doesn't block the business), but names the debt in business terms (risk of leak between vendors, blindness to failures), bounds where the shortcut is acceptable (controlled pilot, not public), and sets the explicit payment plan. It turns a shortcut that could blow up into a conscious and shared business decision. The sin would have been launching the shortcut silently and letting the debt appear later as an unforeseen failure.

Summary and next step

In this lesson you learned the craft's hardest answer: knowing how to say no, or its honest form, "yes, but it costs this". With the remodeling whose budget doesn't stretch to everything you saw the two halves of the work —the honest no ("everything doesn't fit, and some things fight") and the "this is what does fit" (the prioritization that gives the most value with what there is)—, and why the obliging "yes" and the bare "no" both fail. You measured it by executing: "everything at level 5" costs 125 points against a budget of 60 —impossible by more than double— because the cost of quality grows quadratically, while the prioritized proposal (excellence for the #1 attribute, decreasing levels for the rest) fits in 55. You understood the "yes, but it costs this" that names the price of each change, the shortcut's debt that has to be named so it's a decision and not a surprise, and the deeper reason "everything at the maximum" is impossible: some attributes fight, so not even with an infinite budget do they coexist at the maximum. And you saw where this module ends and the decisions guide begins: here you name and quantify that you have to choose; there is the method of how to choose.

Before moving on you should be able to: demonstrate with the budget arithmetic that "everything at the maximum" doesn't fit; propose a prioritization that fits by allocating the excellence according to business value; answer a "raise this attribute" request with a "yes, but it costs this" that names the price and the options; and name a shortcut's debt to turn it into an informed decision.

With this lesson you close the arc of the six topic lessons. In lesson 8 —the project— you'll put it all together over a new Mercado launch: installment payments (Buy Now, Pay Later). You'll derive the prioritized attributes from the launch's goals (and you'll see something revealing: security dominates and scalability falls to zero, priorities opposite to those of the external-vendors case —the method, not the recipe—), filter the ASRs, discover the implicit ones, and write the script of the conversation with the CFO in their language. It's the proof that you learned to be the two-way translator, over a case you didn't see in the lessons.

Resources

Mark Richards & Neal Ford — Fundamentals of Software Architecture — its principle that an architect should support few architecture characteristics and "never seek the best architecture, seek the least-worst one" is the formalization of this lesson's "you can't have everything at the maximum".
Google SRE Book — Embracing Risk — the chapter that argues why 100% availability (the "maximum") is the wrong target, and how to choose the right level by weighing cost against value; the operational version of the quality budget and the point where it's worth stopping.
Martin Fowler — TechnicalDebt — the canonical essay on technical debt: what it is, when it's a legitimate shortcut and when a recklessness, and why it has to be made visible to decide it consciously. The basis of this lesson's "name the shortcut's debt".
Gregor Hohpe — The Software Architect Elevator — its treatment of decisions and trade-offs, and of how the architect communicates what each option costs to the business, underpins the "yes, but it costs this" —the architect as the one who makes the price of each decision visible—.

← Previous6. Speaking the stakeholder's language Next →8. Project: derive Mercado's quality attributes for a launch