Cost-Benefit Analysis Method

# Cost-Benefit Analysis Method

The Cost-Benefit Analysis Method (CBAM) answers a question every architecture team eventually faces: of all the quality improvements we could buy, which ones are worth their price? ATAM shows where a design trades one quality attribute against another; CBAM builds on that groundwork and puts money and stakeholder value on the same scale, so architectural strategies can be ranked by the return they deliver.

This lecture carries a broader lesson too, about what an architect actually does. It is worth internalizing before the mechanics, because the mechanics only make sense once you accept one idea: benefit is measured relative to where each stakeholder stands today, never as an absolute score. Everything else in the method — utility curves, weightages, interpolation, value for cost — is machinery for making that relative idea precise enough to spend money on.

The road ahead runs like this: first a look at the architect's role (scientist, engineer, artist), then the economic ideas of scarcity and sensitivity, then the two definitions that anchor everything (benefit and cost as movement), then the five utility-response curve shapes, a full cloud-migration application, the cost models that fill the cost column, the CBAM steps themselves, voting mechanics, and finally interpolation — the calculation that turns anchor points into strategy utilities.

15.1 The Architect: Scientist, Engineer, and Artist

15.1.1 Science Builds Knowledge; Architects Spend It

Science is a body of knowledge, and that body grows through a specific cycle: observe the world, form a hypothesis, test it through research, publish it, and let the community challenge it until it survives the rigor. Einstein hypothesizing that energy equals mass times the square of the speed of light,

$$E=m{c}^2$$

where $E$ is energy, $m$ is mass, and $c$ is the speed of light, is the classic illustration: the claim was stated, researched, presented as a paper, circulated, disputed, and finally absorbed into the shared body of knowledge. Notice what made it science rather than opinion — the claim was exposed to attack by the whole community and survived. That public survival test is what turns a private belief into shared knowledge.

Engineers live off that body of knowledge — but they do something different with it. Science asks "what is true?" Engineering asks "what can we build with what is true?" An engineer — and an architect is engineering taken to its fullest realization — works inside a context (the surrounding situation: the organization, the market, the existing systems) and a problem (the specific goal to reach). The architect applies scientific principles, personal knowledge, creativity, art, and an understanding of the stakeholders to produce a solution.

The artistic element is not decoration; it is structural. No two architects will ever produce the same design from the same problem, exactly as no two artists paint the same canvas identically. If seven hundred people given an abstract problem produce literally identical solutions, something has gone wrong with the process, not right — genuine design work leaves the designer's fingerprint on the result, because each architect weighs the context and the stakeholders differently.

A useful way to hold all three roles together: think of architecture as a performance. The scientist writes the theory of acoustics, the engineer builds the violin, and the artist plays the piece in a way no one else quite would. The analogy breaks in one place worth noting: a violinist can replay yesterday's concert note for note, while an architect's next system faces a new context every time — which is exactly why the artistry cannot be automated away.

15.1.2 The Stakeholder Sits Above Everything

The stakeholder sits above everything. If the audience wants the work expressed in stone, then building in concrete does not serve — no matter how strong your technical case that concrete is more malleable and expressive. You may try to influence the stakeholder, educate the stakeholder, make presentations explaining your point of view, but at the end of the day the stakeholders are what matter. And when you present to a large stakeholder audience, part of your job is making each stakeholder understand the perspectives of the others, because they rarely see each other's point of view on their own. In CBAM terms this translation job becomes concrete: the security-minded stakeholder and the speed-minded stakeholder must both see why one utility number matters more than another, and the weightage voting later in this lecture is precisely where that mutual understanding gets built.

This is also why an architect cannot be merely a designer. The role demands being a strong speaker and communicator — but communication and articulation are worthless if they are not grounded in robust knowledge. A designer who says "let management explain the trade-offs" has it backwards: management hired you, and when the product is lousy, it is your neck on the block. The market makes snide remarks about the architect behind the failed product regardless of whose idea it really was.

Real-world: Steve Jobs and Mark Zuckerberg were engineers who, at the right time and place, gave customers something those customers did not know how to ask for — and the customers applauded for decades. The Apple Macintosh still ships in new avatars, and the iPhone iterates on the same architectural instinct. They decided what they felt customers wanted, and they got it right. That is the deepest form of stakeholder understanding: some stakeholders cannot articulate what they want even when you hand them a questionnaire. Great architects read the customer through deep knowledge of the environment instead. Keep this limitation in mind — it returns later as the hidden stakeholder problem, and DevOps appears as its structural fix.

15.1.3 Artistry, Copying, and the Payoff

Copying is not automatically wrong — but copy-paste must come with understanding and relevance. Where you copy from, the context may differ and the stakeholders may differ, and even the best ideas look lousy two years down the line. A pattern that served a banking system may strangle a real-time control loop; an idea that delighted users in 2015 may feel dated today. Staying innovative and up-to-date is part of the job.

There is a payoff side to all this artistry: the kick you get when a product sells. The ultimate judge of a performer is the moment the curtain rises and the audience claps. When the combination of art, engineering, science, and the right quality attributes reaches customers at a price enough of them can afford, the effort justifies itself — and that judgment, price versus delivered value, is precisely what cost-benefit analysis formalizes.

In one line: science supplies the knowledge, art shapes the solution, and the stakeholder judges the result. The next question is economic — how do we decide which improvements deserve scarce resources? That takes us to what economics actually studies.

15.2 Economics for Architects: Allocating Scarce Resources

15.2.1 Scarce Resources with Alternative Uses

Economics is the study of the optimal allocation of scarce resources — resources that have alternative uses. Every word in that definition carries weight:

• Scarce — you have a limited kitty, like a month's salary: this much and no more. Scarcity is what makes choosing necessary; with infinite money there would be no architecture discipline, only wish-lists.
• Alternative uses — if a resource has no alternate usage, no allocation decision exists; you never need to apply your mind. The moment alternatives appear, you must choose. Money that could fund either a security audit or a performance upgrade is exactly the kind of resource economics is built for.
• Optimal — not just any allocation, the best one you can defend. "We spent it somewhere" is allocation; "we spent it where it returned the most value" is optimal allocation.

Notice the structure this creates for the rest of the lecture: scarcity supplies the constraint, alternative uses supply the option set, and optimality is the ranking job — which is precisely the job CBAM mechanizes.

15.2.2 Constraints, Lobbies, and Invisible Stakeholders

As an architect you are torn between choices. There are lobbies and influences, and sometimes constraints are imposed outright — at the time the order is placed you may simply be told what will be done. Henry Ford's famous line to his customers captures the extreme case: they could have the car in any color they liked, so long as it was black. Ford was a great engineer and that constraint counted in its era — the black car became a status symbol for a whole generation — but it remains the purest example of a decision space with the discretion squeezed out of it. The lesson cuts both ways: constraints destroy choice, yet a well-chosen constraint can even become a brand asset in its time.

Against such constraints stand stakeholders pulling in every direction at once. One wants a sleek interior, another a robust coat of paint, another a streamlined finish, another solid road grip, another acceleration, another something that cruises comfortably. Map each of those wishes to a quality attribute — aesthetics, reliability, performance, drivability, comfort — and you can see the architect's real position: a set of quality-attribute demands, one limited budget, and the obligation to make the mix defensible. The architect's task is not just to balance these demands but to play them actively: impose your thinking on the stakeholders, market to them, educate them.

Real-world: ISRO taught the world what cost-benefit analysis means — it shocked the world into belief that mission-grade results could be delivered at a fraction of conventional budgets. That is optimal allocation of scarce resources performed at national scale, with a stakeholder population (the public) that could not be surveyed individually yet ended up enormously proud of the result. It is the standing proof that disciplined benefit-per-rupee thinking beats big budgets.

Some stakeholders are invisible even to careful process. You know at the back of your mind that certain people will be affected but cannot bring them forth; they do not articulate their needs even when you put up a questionnaire. Handling them is a judgment call grounded in environment knowledge, not in requirements documents. Operations teams are the classic example — they appear in force only after deployment, which is why Section 15.14 returns to them.

One definition, three loaded words, and a field of competing voices — that is the economist's picture of architecture. Next we connect business goals to strategies and see why the benefits those strategies produce must be judged by stakeholders, not by scores.

15.3 Business Goals, Strategies, and Quality-Attribute Benefits

The causal chain is worth writing out: you have business goals, and that is why you have an architecture. From the architecture you work out a strategy, and the strategy is supposed to deliver performance, security, modifiability, usability, testability, scalability, availability — the whole family of quality attributes. Each attribute arrives packaged with a bundle of benefits. The textbook's picture of this interplay is a simple flow: business goals → architectural strategies → costs on one side, quality-attribute benefits on the other. Knowing the cost and benefit of each decision is what lets you choose rationally among competing alternatives.

15.3.1 A 10-on-10 Is Not Always Worth 10

Here is the first counter-intuitive fact, and it separates economic reasoning from examination scoring. In an exam, 10 out of 10 is 10 out of 10 everywhere. In stakeholder value, one 10-on-10 can be worth 8, another 10-on-10 worth 6, another worth 2.

How? Because stakeholders evaluate, not rubrics. Deliver a perfect 10 on an attribute the customer could not care less about, and that 10 is worth nothing. Meanwhile some attribute that took you almost no effort earns a 10 and the customer reacts with "fantastic, brilliant work — can you give a bit more?" Reading that asymmetry correctly, and investing where perceived value lives, is what gets an architect maximum benefit per unit of effort.

This is exactly why CBAM never works with raw scores: it converts every score into a utility — the value of that response level to these stakeholders — before doing any arithmetic. Two attributes can both score full marks while contributing wildly different benefit.

15.3.2 Strategies Come in Bouquets, Not Bullets

A second counter-intuitive fact: architectural strategies are not tactics. A tactic is like a radiotherapy beam that pinpoints one cancer cell and kills exactly that cell. An architectural strategy always comes as a bouquet of benefits — and often a bouquet of shortfalls too. Adopting a particular architecture might compromise security or suffer on performance somewhere else, and you may still rationally adopt it because the benefits far outweigh the losses.

Picture a bedsheet: pull one corner and the other three corners adjust to allow the pull; pull hard enough and the sheet tears. Every gain extracts adjustments elsewhere. (People who wear astrological stones for luck in one dimension of life rarely check what the other dimensions pay for it — the same sheet logic applies, whether or not the stone works.) When you evaluate a cloud move later in this lecture, watch how the same strategy lifts availability while quietly changing security, maintainability, and cost — the sheet pulling on every corner simultaneously.

15.3.3 Put Decisions on Record

One practical discipline follows directly: record the reasoning. When you make a choice because stakeholders said an attribute mattered, put it on record and remind people of it. Later there will be denials — "we never said this was important to us" — and the written, voted record is your defense when you have to stand by decisions made years earlier. This documentation step is where much of CBAM's real effort goes. The voting records from Section 15.12 are not bureaucracy; they are the audit trail that keeps year-old trade-offs defensible.

Benefits arrive in bouquets and their worth depends on who receives them. Before we can price those bouquets, we need one more economic idea: how much input is enough — sensitivity.

15.4 Sensitivity: How Much Input Is Enough

15.4.1 The Optimal Stopping Point

Sensitivity names the relationship between input and output: how much additional input produces how much additional benefit, and where the optimal stopping point lies. How much sugar do you mix until tea is optimally sweet? Past that point more sugar is wasted — the tea gets sweeter, but you stop getting benefit worth the cost.

The same curve appears in sweets: the first roshogulla is wonderful, the second is welcome, the third you can manage, and by the fifth you are saying thanks-but-no-more. Each unit of input yields less added satisfaction than the one before.

Visualize it: put input (spoons of sugar, number of roshogullas, rupees invested) on the horizontal axis and the satisfaction or benefit you feel on the vertical axis. The curve rises steeply at first, then bends flat — economists call this shape diminishing marginal returns, meaning each extra unit adds less than the one before. The optimal stopping point sits near the bend: past it, the curve still climbs a little, but no longer fast enough to justify the price of the next unit. Keep this picture; it returns as Curve A of the utility-response family in Section 15.7, and the whole point of drawing utility curves is to find each stakeholder's personal bend.

15.4.2 Budgets, Envelopes, and Batting Orders

Budgeting makes the trade-off concrete. Your monthly salary is fixed. You mentally sort it into envelopes — milk, outings, holidays, parents, children's education. Then a want appears ("a new car"), and you start stealing from envelope after envelope; when that fails you try to grow the budget itself, and when the boss says wait for next year, you rebalance within what you have. Every step of that household drama has an architectural twin: new feature requests steal from the maintenance envelope, requests to grow the budget meet management resistance, and finally the architect re-balances inside what exists.

Capital budgeting in companies runs the same way: build a ranked list of items — a batting order — fund from the top, and expect the ranking to be argued over. In a family version, the first draft ranks a microwave above a music system, the whole family revolts because everyone wanted the music system, and priorities get reshuffled transparently. Transparency in the priority list is the point: people accept outcomes far better when they can see and contest the ordering. CBAM's voting rounds are exactly this made formal — a public batting order for scenarios that stakeholders may contest before money moves.

Real-world: large conglomerate leaders make calls like this with incomplete information and no chance to defend them publicly later. Whether a particular famous low-cost car project helped or hurt its parent company overall is genuinely unknowable from outside — but the company's shareholders have done well, which tells you the portfolio-level allocation was defensible even where individual moves look questionable. Judge allocation at the portfolio level, not move by move.

Sensitivity tells us benefit responds unevenly to input. The next idea sharpens it into two definitions on which every CBAM calculation rests: benefit and cost are both measured as movement from where you stand today.

15.5 Benefit and Cost Are Measured from the Current State

15.5.1 Benefit Is Movement

Tell a poor man "I will make you rich" and the promise means something enormous. Tell a very rich industrialist the same words and you must figure out what it could even mean — you would have to start from where he already stands. Offer someone a car as a gift when they already own a car, and the benefit is roughly zero: "what is so great about giving me a car? I already had one."

The same gift, the same object, three different benefits — because benefit lives in the gap between today's state and the proposed state, not inside the object. In symbols, the textbook writes each per-scenario benefit as

$$b_{ij}=U_{\text{expected}}-U_{\text{current}}$$

where $U_{\text{expected}}$ is the utility of the response level your strategy achieves on scenario $j$, and $U_{\text{current}}$ is the utility of today's response level for that same scenario. If a strategy fails to move a scenario at all, its benefit there is zero no matter how good the absolute response is.

15.5.2 Cost Is Also Movement

Cost obeys the same relativity. You do not price "the cloud" or "the new architecture" in the abstract; you price the transition — migration effort, dual-running expenses, training, decommissioning — from today's arrangement to the target one. Section 15.8 works this out line by line for an on-premises-to-cloud move.

Internalize these two and the rest of the method follows easily, because every quantity CBAM computes is a difference against today's state, never a raw score. Cost-benefit analysis is often referred to in practice as value for money: after a thorough economic analysis, you can say whether the movement you propose is worth what it costs.

15.6 From ATAM to CBAM: Scenarios, Utilities, and Strategies

15.6.1 What Carries Over from ATAM

With scenarios in hand, the economic layer begins: examine each scenario, note the current response, look at the possible responses achievable with your proposed solution, and find the utility of the difference between them. You assign utilities to responses, which lets you draw a utility curve — utility plotted against various response levels.

Concretely, for each scenario you will elicit four response anchors from stakeholders — worst case, current, desired, and best case — and then attach utility numbers to those levels (Section 15.12 shows the dialogue that produces them). The utility curve is the bridge between words like "fast enough" and numbers you can multiply by money.

When to reach for which: run ATAM to understand a design's risk landscape; run CBAM afterwards when you must decide what to fund first.

15.6.2 One Strategy, Many Attributes

One strategy never maps to one quality attribute. Any architecture produces a bouquet of benefits across attributes simultaneously (and possibly shortfalls, as Section 15.3 warned). So when you evaluate an architectural strategy, you evaluate its impact on every scenario it touches, and you aggregate. This is why the method needs machinery — weights, utilities, interpolation — rather than a single comparison: each touched scenario contributes its own utility gain, and only the weighted sum tells you whether the strategy pays.

The next section builds the central visual vocabulary: the five shapes a utility-response curve can take.

15.7 Utility-Response Curves: Five Shapes of Value

Read each curve below as an investment instruction. The shape tells you where the next unit of budget buys the most utility — and where it buys nothing at all.

15.7.1 Curve A — Diminishing Returns

The classic law of diminishing marginal returns from economics: each additional unit of input gives less utility than the previous one. First roshogulla best, fifth barely wanted. In response-time terms: cutting a response from 5 seconds to 4 seconds feels fantastic; cutting from 4 to 3 gives noticeably less joy; each further second saved matters less than the last. Most normal things in life follow this curve.

Visually: the curve rises steeply from the origin, then bends and flattens toward the top-right — a stretched L lying on its back. The landmark is the bend: left of it, investment pays handsomely; right of it, you are paying real money for invisible gains. On this curve, stop near the bend.

15.7.2 Curve D — Straight Line

If every unit of improvement delivers the same benefit — going from 5 s to 4 s feels exactly as good as 4 s to 3 s — the utility-response relationship is a straight line. Value accrues linearly, so incremental investment decisions are easy: every step costs the same and buys the same. There is no special stopping point on the curve itself; the decision collapses to whether the constant price per step is worth the constant utility per step.

15.7.3 Curve B — Increasing Returns

The opposite bend: each improvement excites more than the last. From 5 s to 4 s is good; 4 to 3 gets you excited; 3 to 2 impresses; 2 to 1 second produces "wow — what is this?" Visually the curve hugs the floor, then sweeps upward — the mirror image of Curve A.

Real-world: the first experience of Google search felt exactly like this — the speed at which it returned results had users stunned; each increment of speed pushed delight up at a steeper pace. Products riding curve B reward pushing performance aggressively, because marginal gains are worth more, not less. Under-investing on a curve-B attribute is the expensive mistake here: the cheap early steps are precisely the ones stakeholders value least.

15.7.4 Curve C — S-Curve and the Sweet Spot

Curve C is flat, then steep, then flat again. Buying a computer or mobile phone shows the shape directly: between prices 5,000 and 10,000, extra money buys few features and little visible difference. Jumping from the 20,000 range into 30,000–40,000 brings a huge, immediately felt increase in performance. Moving from 50,000 to a lakh flattens out again — better, but you may not perceive the utility. Many buyers settle on a sweet spot around 40,000: up to there, quality-per-price climbs nicely; beyond, it sputters out.

Visually: an elongated S lying across the axes — a dead zone, then a steep climb, then another dead zone. The landmarks are the two knees where the slope changes; the sweet spot sits just past the upper knee, where the last steep segment ends.

The curve is person-dependent. Someone born into the 50,000 range perceives real benefit in every extra 10,000, and a technologist can distinguish the 70,000 machine from the 80,000 one — while buyers climbing from the bottom see little difference between 50,000 and 80,000. Same product line, different utility curves, different correct purchase points. That person-dependence is exactly why utilities are elicited per stakeholder group rather than assumed.

15.7.5 Curve E — Steps and Thresholds

Most things in the technology era follow step curves. You keep adding security features and utility does not move — no additional perceived value — until you invest in a genuinely different technology level, say stepping up to RSA encryption keys, and suddenly utility jumps. Then a stretch of small improvements again registers as "doesn't matter," followed by another threshold and another jump.

Visually: a staircase — flat slabs connected by vertical jumps at thresholds. The landmarks are the risers; everything along a tread is dead spending.

Availability behaves the same way. Stakeholders may see little difference between one hour and six hours of downtime, but telling them downtime drops to five minutes produces a big advantage in their eyes. Utility gets understood in slabs: up to this downtime level, this many utility points; past it, that many.

15.7.6 The Stopping Rule on a Step Curve

When to pick which rule: identify the curve first by asking stakeholders what each extra increment of response is worth; the answer's pattern places you on A, B, C, D, or E, and the table above does the rest.

15.8 Worked Application: Moving from On-Premises to Cloud

Consider the decision to move a system from on-premises infrastructure to the cloud. You carry a bouquet of expected utilities in mind: perhaps availability improves from up to 10 hours of downtime down to 1 hour. You assign utilities to the various downtime levels, and then you check whether intermediate options exist. Often they do not: you may have exactly two purchasable points, 10-hour downtime and 1-hour downtime, and nothing in between — in which case those are the only two points on the response axis, and the missing points do not exist for decision purposes. This is Curve E from Section 15.7 in the wild: a step-shaped improvement with no slope to buy along the way.

Utility points themselves are fixed by stakeholders, not by the architecture team; you vote the values out of them. The team's job is measurement bookkeeping, never inventing the numbers that express value.

Now evaluate the shift attribute by attribute: what is the change in security? In availability? In performance? In maintainability? In testability? Each attribute contributes a utility gain, and each gain gets weighted, because organizations weight attributes differently:

• One company prizes security above all.
• Another weights performance most heavily.
• A third — say a firm shipping two new developments every week — loads weight onto maintainability.
• A startup that joined with five terminals but plans for five million users in five years puts its weight on scalability.

Everybody has different priorities, and the weighting vector is how CBAM respects that.

15.8.1 Weighted Total Benefit

Take every attribute's utility-point gain, multiply by the weightage assigned to that attribute, and add them up. That sum is the total benefit of the cloud option versus staying on-premises. Formally, for strategy $i$ and quality attributes indexed by $j$:

$$T{B}_i=\sum _j{w}_j\times B_{ij}$$

where $B_{ij}$ is the benefit (utility gain) strategy $i$ delivers on attribute $j$, measured against the current state, and $w_j$ is the stakeholder-assigned weightage for attribute $j$. The sum runs over all quality attributes the strategy touches. Concretely, if strategy 1 is staying on-premises, strategy 2 is AWS, and strategy 3 is Azure, then $B_{2,1}$ might be the availability gain of AWS, $B_{2,2}$ its performance gain, $B_{2,3}$ its security gain, $B_{2,4}$ testability, $B_{2,5}$ maintainability, $B_{2,6}$ scalability — each multiplied by the corresponding weightage $w_1$ through $w_6$ and summed. (Keep the $B$ list and the $w$ list in the same attribute order, or the sum silently mixes attributes.)

A one-line notation note: the standard reference writes the same idea as $B_i={\sum }_j(b_{ij}\times W_j)$ with lowercase $b$; here we keep the lecture's $T{B}_i$ and $B_{ij}$ — the structure (gain times weight, summed) is identical.

15.8.2 The Cost Side

The cost of the move is the difference between maintaining the on-premises infrastructure and paying for the cloud. On-premises cost includes electricity, space, equipment, the cost of obsolescence (you periodically trade equipment in), and manpower — all of it adds up. The cloud side needs an unusually honest evaluation, because providers promise you the moon and all the skies; the question is whether you have budgeted for the moon and the skies. "It's available, so let's go to the cloud" is exactly the reasoning CBAM exists to stop.

Real-world: experienced practitioners generally find the cloud comes out ahead on this arithmetic — but the mall effect is real. A cloud catalog offers so much that you feel like having everything, like walking into a department store with an empty cart and discovering at checkout that the cart is fuller than you can carry home. CBAM's value in the cloud era is precisely that it forces you to decide what you actually want before you shop.

Benefit computed, cost enumerated — the natural next question is how to combine them into one ranking number. That is the value-for-cost ratio of the next section.

15.9 The Total Benefit Formula, Negative Benefits, and Value for Cost

Restating the central computation with explicit indices. Let strategies be numbered $i=1,2,3$ (say: 1 = on-premises/in-house, 2 = AWS, 3 = Azure) and quality attributes numbered $j$ (availability, performance, security, testability, maintainability, scalability). For each strategy:

$$T{B}_i=\sum _j{w}_j{B}_{ij},{\text{ValueForCost}}_i=\frac{T{B}_i}{C_i}$$

where $C_i$ is the cost of strategy $i$ ($C_1$ in-house, $C_2$ AWS, $C_3$ Azure), measured as the cost difference from the current arrangement. The standard reference states this exactly this way: the value for cost (VFC) of an architectural strategy is the ratio of its total benefit $B_i$ to its implementing cost $C_i$, and you rank-order strategies by that score. The lecture's phrasing "benefit vis-a-vis cost" is the same statement in words.

Sanity checks on the ratio: its units are utility points per rupee, so a bigger number means more value per unit of money; if benefit is zero the score is zero no matter how cheap the strategy; and as cost shrinks toward zero with benefit held positive, the score grows without bound — free benefit is infinitely worth having. Each check behaves as the intuition demands.

When comparing candidate strategies against the current state, remember both sides move as differences: since you take the benefit difference against the current situation, you also take the cost difference against it. If the current arrangement is not itself a choice anymore, the comparison set shrinks to the genuine alternatives (AWS or Azure), each measured relative to today.

15.9.1 Negative Benefits

$B_{ij}$ can be negative. A strategy can take away utility you already have. Stakeholders very often refuse to accept a negative on any attribute — but sometimes they accept it deliberately. Example: shifting from an in-house developed application to a packaged product. The package offers no maintainability — you cannot modify it — so that attribute's benefit entry is negative. You accept the loss because the benefits on the other attributes far outweigh the sacrifice, and you learn to live in a world where you do not make changes. The weighted sum handles this naturally: a negative entry simply subtracts its weight-times-gain contribution, and the strategy still wins if the remaining terms dominate.

Benefit divided by cost gives the ranking — provided the cost column itself is honest. Next: where those cost numbers come from.

15.10 Cost Models

15.10.1 Model-Based Estimates

Several families of cost models exist for architectural strategies:

1. Function point analysis — sizing a system by counting functional units (discrete pieces of user-visible functionality such as "add order", "query status") and converting the count to effort and cost through calibrated productivity rates.
2. Pattern-based cost models — costing attached to adopting a particular architectural pattern; adopting publish-subscribe or layered structure carries a known integration and maintenance price.
3. Complexity-rating models for object-oriented development — cost derived from complexity metrics of the OO design (counts of classes, interactions, coupling), on the principle that complexity is what you pay to build and to maintain.
4. The COCOMO model — plug in project variables (size, capability, schedule pressure) and get a cost estimate grounded in corporate experience of past projects; it is the classic equation-driven estimator of software engineering.
5. Expert judgment — senior architects who have done similar projects give an off-the-cuff figure: "this sort of approach should cost about so much."
6. Vendor quotations — particularly with cloud providers, submit your specifications and receive a quotation; the vendor's pricing engine does the modeling for you.
7. Relative ratios — when absolute figures are unknowable, work in ratios: five years ago a similar project cost about 10 lakhs; under this strategy it would have been half of that, under another double — and today's costs sit in the same ratios. The decision needs ratios, not rupees.

That last entry deserves emphasis because it rescues many analyses: value-for-cost ranking survives any common scaling of all costs. If every $C_i$ is wrong by the same factor, every ratio is wrong by the inverse factor and the ordering is untouched — which is why coarse relative estimates are often enough to choose.

15.10.2 Experience, Quotations, and Ratios

Building rigorous cost models takes significant effort, and that expertise usually lives with project managers, who estimate for a living. Architects work closely with project managers and can elicit their help for the cost column. For a quick estimate, the experience-based methods (last three above) are the most prevalent. Rough estimates are acceptable at decision time — the goal is choosing among strategies, and if estimates later prove badly wrong, you adjust course accordingly.

Costs sourced, steps defined — next comes the method itself, laid out as an ordered procedure.

15.11 The CBAM Steps

15.11.1 The Six Steps in Order

The method proceeds as an ordered procedure:

1. Collate and prioritize scenarios. Gather the scenario pool from stakeholders, vote, and retain the top one-third. (You need a healthy pool for this to mean anything — three or four scenarios is not worth the machinery.)
2. Anchor each scenario. For each retained scenario, determine the best case, the worst case, and the current case, with quantitative numbers placed on each. Best means it cannot get better than this; worst means stakeholders refuse to even discuss anything below it.
3. Re-prioritize. After understanding the value picture, prioritize the scenarios again and discard a further batch.
4. Assign utilities. Find the utility of the current level and the desired (design-target) level of each surviving scenario.
5. Map strategies to scenarios. For each architectural strategy, determine which scenarios it impacts and to what quality-attribute response levels. The scenario states what you want; how it gets achieved is decided by the architectural choice. Deciding "move to AWS" obliges you to work out how AWS moves every scenario it touches.
6. Interpolate. When a strategy's actual achieved level falls between your anchored points (best/current/worst), interpolate to find its utility — the subject of Section 15.13.

A notation note on scope: the standard reference continues past interpolation with three closing steps — calculate each strategy's total benefit, choose strategies by value for cost subject to budget and schedule, and confirm the results against intuition before iterating. The lecture's six-step core is the front half of that same pipeline; Sections 15.8 and 15.9 already supply the arithmetic of its back half.

The funnel narrows at known rates: keep roughly the top one-third in step 1, discard about half again in step 3, so stakeholder time concentrates on the scenarios most likely to justify their funding.

15.11.2 Scenarios Say What; Strategies Say How

A scenario is a statement of what the stakeholder wants, never of how it gets achieved. The how is decided by the architectural choice, and that choice must be traced across every scenario it touches: deciding "move to AWS" obliges you to work out how AWS moves each affected scenario, and to what response level. This mapping step is where strategies acquire their numbers — response levels per scenario, then utilities per attribute — which is why the method dedicates separate steps to mapping and to interpolation instead of merging them.

15.12 Working with Stakeholders: Scenarios and Voting

15.12.1 The Six-Part Scenario Format and First Votes

Scenarios use the six-part scheme studied at the start of the course: stimulus, source of stimulus, artifact, environment, response, and response measure. The six parts force ambiguity into the open — "make it fast" becomes "a user request (stimulus) arriving from a browser (source) at the search service (artifact) during peak load (environment) must be answered (response) within 0.5 seconds (response measure)". The voting machinery around them works like this.

Every stakeholder who presents a scenario at least prioritizes their own — typically marking it high, medium, or low, recorded alongside the scenario. Then all stakeholders convene, receive the complete list (nicely drawn up by someone from the architectural team who can present each scenario in full six-part form), and rank every scenario. Each participant's ranking counts as a vote, and votes aggregate by summation: add up the ranks each scenario received, and the scenarios with the lowest aggregate rank win.

Before voting on priorities, refine the anchors through dialogue with the people who know the domain. A typical exchange establishes: "it currently responds in 1.5 seconds"; "worse than 20 seconds can't really happen anymore — that used to happen earlier, we're better now"; "the best we can imagine is 0.1 seconds, because such-and-such site has achieved it"; "we would be very happy with 0.5 seconds." Those four numbers — worst 20 s, best 0.1 s, desired 0.5 s, current 1.5 s — become the scenario's response anchors. Notice what the dialogue does that no questionnaire can: it lets veterans veto stale worst cases ("that used to happen earlier") and import external evidence for the best case ("such-and-such site has achieved it").

For prioritization voting you can give each stakeholder 100 votes to distribute across scenarios. Some will put all their eggs in one basket and stack all 100 votes on a single favorite scenario; expect it. That is not a malfunction — it is honest information about how much that stakeholder cares, which is exactly what the weights are supposed to encode.

15.12.2 Re-Vote Cycles

After the first ranking, show everyone the outcome. Scenarios that got voted down earn an advocacy round: their proposers explain why they consider the scenario important and argue it should be voted up. Then re-vote. There is no harm in a re-vote, and one or two cycles are normal.

The mechanism mirrors preferential elections in some institutions: after the first-choice winner is selected, a re-vote decides the second post, because voters whose first candidate won redistribute support — knowing candidate one is safe, they shift votes elsewhere. Scenario voters behave identically: once everyone sees that scenario one already has a huge lead, they distribute votes to other scenarios they also care about. A reverse risk exists too — in the shuffling, a previously top-priority scenario can lose support altogether. Run two or three cycles until the pattern stabilizes; stabilized votes are your trustworthy priority signal.

The cost side of this theater is real but bounded: each cycle is a facilitated session of minutes per scenario, and stabilization typically arrives in two or three cycles — cheap insurance against funding the wrong priorities for years.

15.13 Interpolation: Utilities Between Known Points

15.13.1 Where the Formula Comes From

Two known points $(x_1,y_1)$ and $(x_2,y_2)$ fix exactly one straight line. Any point $(x,y)$ on that line must satisfy the two-point form — rise over run is the same between any pair of points on a straight line:

$$\frac{y-y_1}{x-x_1}=\frac{y_2-y_1}{x_2-x_1}$$

Solving for $y$ takes two moves. Multiply both sides by $(x-x_1)$, then add $y_1$ to both sides:

$$\begin{array}{rlr}y-y_1& =\frac{y_2-y_1}{x_2-x_1}(x-x_1)& \text{(multiply both sides by }x-x_1\text{)}\\ y& =y_1+\frac{x-x_1}{x_2-x_1}(y_2-y_1)& \text{(add }{y}_1\text{ to both sides)}\end{array}$$

Here $x$ is the quality-attribute response level whose utility $y$ you want, $(x_1,y_1)$ and $(x_2,y_2)$ are the two anchored points bracketing it. Read the formula as a sentence: start from the utility at the first anchor, and add the fraction of the utility gap that your point has traveled along the response gap. That fraction $\frac{x-x_1}{x_2-x_1}$ is 0 at the first anchor and 1 at the second — so the answer is pinned to both known values at the boundaries, which is the limiting-case check that the formula behaves correctly.

15.13.2 Worked Example 1 — Availability Under a Cloud SLA

Setup: worst-case availability is assigned utility 0, best-case utility 100 (you cannot go below 0 or above 100). Current availability is 5 days of downtime per period, carrying a utility of 40. The target is maximum 1 day of downtime, which corresponds to utility 100. The chosen strategy is moving to AWS, which assures maximum 2 days of downtime. What utility does 2 days deserve?

Graphical/segment method: the stretch from 5 days (utility 40) to 1 day (utility 100) spans $5-1=4$ intervals of one day each, and $100-40=60$ utility points. Utility per interval:

$$\frac{100-40}{5-1}=\frac{60}{4}=15\text{ utility points per day of improvement}$$

Two days of downtime sits one interval away from the 1-day anchor, so its utility is $100-15=85$. (Equivalently, counting up from the current case: $40+3\times 15=85$.)

Formula method: substituting $(x_1,y_1)=(5,40)$ and $(x_2,y_2)=(1,100)$:

$$y=40+\frac{60}{-4}(x-5)=40-15(x-5)=40-15x+75$$

At $x=2$: $y=40-30+75=85$.

Both routes give 85. Note the slope is negative here — downtime shrinking along the axis while utility rises — which is exactly why blindly plugging into formulas invites sign errors. The segment method doubles as a sign check: fewer days of downtime than the best-case anchor would push utility above 100, telling you instantly that you have left the valid region.

15.13.3 Worked Example 2 — Response Time at One Second

Setup from the dialogue-anchored scenario: 12 seconds carries utility 5; 1.5 seconds (current) carries utility 50; 0.5 seconds (desired) carries utility 80; 0.1 seconds (best conceivable) carries utility 85 — note the best case is not awarded 100 here, because stakeholders chose non-uniform bands: "up to this level, this utility; past it, that utility." Plotting these points draws a curve that is nearly flat across the long responses and rises steeply between 1.5 s and 0.5 s — a sinusoidal-style bend where most of the value concentrates in one region.

Question: what utility corresponds to 1 second?

Graphical method: read the plotted curve at $x=1$ — it lands at about 65.

Analytical method: use the two-point form of the line through $(x_1,y_1)=(1.5,50)$ and $(x_2,y_2)=(0.5,80)$:

$$\frac{y-y_1}{x-x_1}=\frac{y_2-y_1}{x_2-x_1}$$

The slope is $\frac{80-50}{0.5-1.5}=\frac{30}{-1}=-30$, so:

$$y-50=-30(x-1.5)$$

At $x=1$: $y-50=-30\times (-0.5)=15$, hence $y=50+15=65$.

Both methods agree at 65 — in this case luckily so. The recommended practice is to combine them: sketch the geometry to get an intuition of the answer, then compute, and check the calculation lands approximately where the graph says. If they diverge, one of them is wrong; find out which before trusting either.

With interpolation in hand, every link of the chain is complete: anchored scenarios, voted utilities, mapped strategies, interpolated utilities, weighted benefits, and the value-for-cost ranking. One organizational risk remains — stakeholders you never knew were stakeholders.

15.14 Hidden Stakeholders and DevOps

15.14.1 The Production-Time Surprise

A recurring failure mode: the team believes it knows who speaks for operations, deploys the product, and suddenly a whole new population of stakeholders appears from nowhere declaring the product nonsense that does not serve the requirement. Discovering stakeholders at production time is arguably the biggest lapse an architect and team can commit — and companies have plenty of people nobody believed could speak authoritatively until proven otherwise.

Recall the invisible stakeholders of Section 15.2: people you sense will be affected but cannot name in advance. The production-time surprise is that prediction coming due. The utilities were voted, the weights summed, the strategy ranked — all among an incomplete electorate — and the omitted voices arrive only when they can do the most damage: after the money is spent.

15.14.2 DevOps as Stakeholder Insurance

Today's standard answer is DevOps: operations people working hand in hand with developers throughout the building of the product, so the people closest to the actual operating scene are involved right through development rather than first met at deployment. Treat DevOps as CBAM's stakeholder-discovery insurance: the voting and utility processes only protect you if every authoritative voice is in the room when the votes happen.

Exam Guidance Summary

• Overview beats selective study. Examinations cannot test everything; do not expect one question to cover the syllabus, and do not gamble that only what you selectively studied will appear. Build a good overview so you can at least understand every question and fit your knowledge into an answer with imagination and engineering sense.
• Expect deliberately confusing questions. Papers are now designed to confuse AI tools, not students: questions lack clear-cut answers, data is incomplete, and what looks like a plug-and-play numerical is missing required information. You are forced to think, state assumptions, and proceed. If the whole class makes the same assumption, evaluators apply the law of averages — so think independently. In CBAM terms: when a numerical omits a weightage or an anchor, say out loud what you are assuming, then compute with it.
• Presentation matters. Package your answer the way you would package yourself for an interview at a major IT services firm: showing up in loungewear to pitch yourself as an architect might amuse one listener, but on average it does not pay off. Presentable, well-organized answers score.
• Evaluators are senior practitioners, with decades of industry experience, who read for maturity of discussion and creativity rather than tick-marked points. Repetitive, standard, generated-looking answers read as average however polished. Going off-assignment earns nothing.
• Negative $B_{ij}$ entries can appear. Practice tables here stay positive; exam tables may not. Let negatives subtract inside the weighted sum instead of zeroing them out.
• Interpolation: understand the concept, not just the formula; figures may be provided directly, and the response-curve computation may not be asked at all. Prefer solving graphically and analytically and cross-checking.
• Emphasis signal: this topic area was flagged as very important, with extra time devoted to it and a philosophical grounding — treat CBAM as high-value exam material.

Key Industry Applications

• Cloud migration decisions (AWS vs Azure vs on-premises): the flagship worked application — utility gains per attribute, stakeholder weightages, total benefit versus total cost including obsolescence and manpower. Every large organization weighing a move runs some version of this arithmetic; CBAM makes the version defensible.
• ISRO missions: globally recognized demonstration of delivering outsized results under tight resource constraints — cost-benefit discipline at national scale, executed with a stakeholder population that could never be surveyed individually.
• Google search speed: an instance of increasing-returns (curve B) utility perception, where each speed gain delighted users more than the last — and a caution that curve-B attributes reward aggressive investment.
• Consumer electronics pricing (mobile/computer tiers): S-curve utility with a sweet spot purchase point around the mid-tier; different buyer segments perceive different curves on the same product line.
• RSA encryption keys and availability tiers: step-function (curve E) value — invest at technology thresholds, not in dead zones between them; downtime measured in minutes reads as a different slab from downtime measured in hours.
• Apple Macintosh / iPhone product lines: architect-driven anticipation of unarticulated customer wants, sustained across decades of iterations — stakeholder understanding deeper than any questionnaire.
• Henry Ford's single-color Model T: the canonical constraint-bound decision space, and a reminder that constraints can even become brand assets in their era.
• Function point analysis, COCOMO, complexity-based OO cost models, vendor quotations, and ratio-based estimating: the practical toolbox for filling CBAM's cost column, typically sourced through project managers.
• DevOps: organizational practice ensuring operations stakeholders participate throughout development, closing CBAM's hidden-stakeholder gap before votes are cast rather than after products ship.

Together these cases show one pattern: wherever scarce budgets meet competing quality demands — national missions, search engines, phone tiers, cloud contracts — the winner is whoever measures benefit relative to where each stakeholder actually stands.