Cost-Benefit Analysis, Management, and Governance

This session finishes the cost-benefit analysis method, works it end to end on a NASA case, and closes with the management and governance duties an architect shares with a project manager.

The session runs in three movements. First, a practical warm-up on comprehensive-exam strategy — how to prepare, what evaluators reward, and how to budget time. Second, the economic core: utility curves, weighted benefits, and value-for-cost ratios, all worked through a live client-developer negotiation and then a full NASA satellite-data case study. Third, the people side: planning, organizing, implementing, measuring, and the governance loop that keeps a project improving after the architects move on.

16.1 Preparing for the Comprehensive Exam

Before the technical material, the professor spent the session's opening stretch on exam strategy. The advice is practical, and it comes from decades of grading: how to divide study time, what an open-book exam really rewards, and how to turn available time into per-question budgets.

16.1.1 Cover the Whole Syllabus

A student asked where to spend preparation time for the end-term comprehensive exam: the entire syllabus, or mainly the second term? The answer is blunt — prepare the entire syllabus. The second half of the course sits on the first half. Architecture evaluation methods assume you already carry the vocabulary of quality attributes, tactics, and viewpoints from earlier topics. If you did a reasonable job on the first half before the midterm, it will still be there. If your memory is short-term, go through the first half again.

The reasoning behind the answer is worth making explicit. Evaluation methods such as ATAM and cost-benefit analysis do not introduce quality attribute scenarios from nothing — they consume them. A utility curve drawn in this lecture only makes sense if you already know what a quality attribute response (the measurable outcome a scenario produces) is. Weak first-half knowledge taxes every second-half question.

16.1.2 The Truth About Open-Book Exams

The exam allows printed reference material, so many students assume they can look things up on the day. The correction matters more than any formula: open books are useless unless you have gone through them in advance. You should know where each answer lives before you walk in. The book then helps you give the answer properly; it never substitutes for study. Never plan to start learning during the exam — there is no time.

Because the exam runs offline, only printed material is allowed. Soft copies stay home, since a laptop could reach the internet. If printing everything is unaffordable, tick-mark the pages you judge important and print those. History adds perspective: students once carried trunk loads of books into exams, until restrictions had to be imposed. In three hours you cannot search trunk loads anyway. A book you never opened helps nobody. This is not a search engine that jumps to the right page; even a good index page rarely saves you.

On notebooks: the rules come from the examination department, not from teaching staff. In past years, bound handwritten notebooks were allowed — hard bound or spiral bound, not stapled — and they had to be in your own handwriting, or it becomes a cheating case. Always check the current rule book yourself.

16.1.3 What Evaluators Reward

Read the question paper very, very carefully. Do not answer the wrong question. However much you studied, answering the wrong question gets no sympathy. These are professional exams inside a work-integrated program — not a talent search show picking five winners out of five hundred. The system exists to gear you toward education.

Do not obsess over marks. Average marks are good marks. Evaluators bring about thirty years of industry experience and around fifteen years of teaching each, so they recognize a got-up answer from a real one. A got-up answer earns average marks — which are good. Graders also work with tick lists: as they read, they check whether the answer approached this point or that point, and award marks per tick. So when a question sounds abstract, connect it back to the syllabus while reading it.

Marks fade fast anyway. Degrees and mark sheets stop mattering within months; family members may never look at them. The real payoff is a flashback five years later, when something from this course helps you at work — that is when the course has served its purpose.

16.1.4 Time Budgets and Answer Style

Adopt the 80-20 rule early in life. Divide the minutes available by the marks on offer, and never spend one minute more on a question than its marks justify. Written as a rule:

$$\text{Time budget for a question}=\frac{\text{Minutes available}}{\text{Total marks}}\times \text{Marks carried by the question}$$

For a 30-mark paper in three hours (180 minutes), that works out to six minutes per mark, or one hour per 10 marks. Followed honestly, you never surrender a paper. For a 6-mark question, allot its share of time — six-tenths of an hour, which strict division puts at thirty-six minutes; the professor rounded this to "about forty-five minutes" in class. The exact rounding does not matter; the discipline of capping the spend does. Read the question ten times if needed, then write what fits the budget. Most people score about the same on any question; being average everywhere ends up topping the class. If a topic demands an essay on a cow and you have ten minutes, write ten minutes of cow — and know in advance which aspect of the cow you will cover.

The phone-shop analogy deserves one line of unpacking, because it reappears whenever effort must match value: a cheap product is bought on trust, an expensive product is audited line by line. Answers behave the same way — a two-mark answer is skimmed for the key points, a ten-mark answer is read against the full tick list.

16.2 The Decision Context: Value for Cost

16.2.1 Benefits Divided by Incremental Cost

Start from the decision-making frame reviewed at the top of the session. An architecture change produces benefits — improvements in quality attribute levels that you accumulate after the architecture is implemented. Those benefits cost money. The economic core of the method is a ratio, described in words as: add up all the benefits you get once the architecture is implemented, then divide by the incremental cost of achieving them.

$$\text{Benefit for Cost}=\frac{\text{Total Benefit}}{\text{Incremental Cost}}$$

Here Total Benefit is measured in utility units (dimensionless scores, usually percentages), and Incremental Cost is money — the price of implementing the candidate solution. You compute this ratio for every candidate solution, and whichever gives the best benefit-for-cost at a price you can afford wins.

The everyday analogy is fuel efficiency. A car's kilometers per liter tells you how much distance (benefit) each liter (cost) buys; two cars are compared by that ratio, not by distance alone or liters alone. Incremental is the word doing real work here: you already own the current system, so its cost is sunk. Only the extra money that moves you from today's system to the candidate system counts in the denominator. A candidate that improves nothing has a benefit of zero, so its ratio is zero no matter how cheap it is.

16.2.2 Quality Attribute Responses Must Be Measurable

Everything rests on the quality attribute response — the scenario presentation where a source of stimulus fires a stimulus at an artifact in an environment, producing a response that can be measured. Measurement is not optional decoration. Conventionally people said quality attributes can only be felt, not measured. In today's professional world you have no choice: payments are involved, service level agreements (SLAs) are signed, and work must follow agreed metrics. So each scenario carries four reference points: the worst case, the best case, the current case, and the desired case.

Recall the six parts of a quality attribute scenario from earlier lectures: a source generates a stimulus, aimed at an artifact, under some environment, producing a response, which carries a response measure. The response measure is the part economics consumes. "The system should be fast" feeds no formula; "the reconciliation job finishes within ten seconds" does.

Real-world: SLAs turn soft qualities into contract terms. A response level written into an SLA is a payment obligation, which is why modern teams insist on measurable scenarios. When a cloud provider signs a 99.9 percent availability clause, that number converts straight into credits owed to customers whenever uptime dips below it — quality stopped being a feeling the day someone could invoice against it.

16.2.3 Four Points on Every Utility Curve

Each quality attribute gets a utility curve: utility (satisfaction, in percent) plotted against the attribute's response value. Mark the current level $A$ — where you are today — and the desired level $B$ — what the requirements ask for. A candidate architecture achieves some level $A^{\prime }$, usually somewhere between $A$ and $B$, though occasionally beyond $B$. To read off the benefit, draw a vertical line up from $A^{\prime }$ to the curve and note the utility there; the gain for that scenario is the gap between the utility at $A^{\prime }$ and the utility at $A$. Summing across all scenarios gives the cumulative benefit, stated as: take the y-axis utility value at what the architecture achieves, subtract the y-axis value at the current point, and add these up over every scenario.

$$\text{Total Benefit}=\sum _{j=1}^m(U(A_j^{\prime })-U(A_j))$$

where $U$ is the utility percentage between 0 and 100 read from the curve, $A_j$ is the current response level for scenario $j$, $A_j^{\prime }$ is the level achieved by the candidate architecture, and $m$ is the number of scenarios. Divide this total by the solution's cost, compare solutions, and pick the best benefit-for-cost you can afford.

Picture the graph before trusting the formula. The horizontal axis carries the response value — say, response time in seconds, running from slow on the left to fast on the right. The vertical axis carries utility from 0 to 100 percent. The curve rises from left to right, but not evenly: it may climb steeply over one narrow band of response values and sit flat elsewhere. Two vertical lines anchor the arithmetic — one at the current level $A$, one at the achieved level $A^{\prime }$ — and the benefit is simply the vertical gap between where those two lines meet the curve. If the curve is flat between them, the gap is small: you paid money for satisfaction the client never asked for.

16.2.4 Bad Data, Assumptions, and Proof of Concept

Real life is crueler than any question paper. You interview stakeholders, collect requirements, and some people have told you damn lies that you dutifully wrote down. You must decipher truth from fiction, connect data with other data, and turn information into a decision — logically. Sometimes you must revalidate claims by running a proof of concept. When a vendor promises a performance level, say: we want to see it in practice. Earlier generations visited companies where candidate solutions already ran, just to watch them work. Treat exam trickery as rehearsal for that reality.

16.3 A Live Negotiation: Where Utility Curves Come From

16.3.1 The Setup: Reconcile Accounts in Ten Seconds

The curves feel abstract until a real negotiation draws them. One exchange in this session does exactly that, and it starts with a simple request:

Notice what just happened in that answer. A vague wish ("make it fast") became an architecture-grade scenario in one sentence: the artifact is the reconciliation job, the stimulus is ten days of transaction data arriving, the response is the completed match-off, and the response measure is ten seconds. Every economic calculation downstream hangs on that last number.

Now play it out. The developer promises five seconds, then negotiates. First twist: the developer says twelve seconds is achievable, but the client already runs the job in ten seconds. Nobody pays money to make a working system slower — that offer dies instantly. So reset the numbers realistically: the current system takes twenty seconds, and the developer promises twelve seconds for a price of ten lakh rupees.

16.3.2 Only the Client Owns the Curve

Before signing anything, the client asks internally: how happy would we be at twelve seconds? The answer redraws the whole picture. Fifteen seconds is good enough for us, says the business side. At twenty seconds our utility is eighty. Bringing twenty down to eighteen is of no use — the same eighty. But reach fifteen and people notice the difference, because competitors normally deliver within fifteen seconds, and anything beyond fifteen barely helps. That is a step curve: flat, then a jump, then flat again.

Read the shape off that description. From twenty seconds down to fifteen, the curve crawls along a low plateau — effort spent there buys no satisfaction. Between fifteen and about thirteen seconds the curve jumps vertically — the entire value of the deal lives inside that narrow band. Below thirteen it flattens again at the top. A vertical jump inside a curve means one thing economically: only crossing the threshold matters, and landing anywhere past it is equivalent.

The lesson generalizes: the curve comes from the client's assessment of how utility relates to response values. It has nothing to do with the developer. The developer supplies quotations; the client supplies the curve.

16.3.3 Rings on Your Fingers: Trade-offs

The client ran a proof of concept on the promised solution and found cracks: a little security problem, and maintainability complaints — the in-house team said this developer's programs are difficult to maintain. Then testability collided with speed: to give you online testability, I cannot give you twelve seconds. Every quality benefit costs another quality, like the stones you wear on your fingers — you get something, you give up something else. Your day has so many hours: too much time in the office means less time with family, and no time left to prepare for exams. Life distributes; architectures distribute too.

When to pick which: pick speed-first when the step threshold is unmet and the business loses money every second past it; pick testability-first once the threshold is comfortably met and the system must live for years.

16.3.4 Prices Are Not Proportional

Suppose the client counters: you offered twelve seconds for ten lakh rupees — what will sixteen seconds cost? The developer concedes only to eight lakh rupees. No proportionate discount, because the coding, the team, and the testing remain the full works. Maybe one planned tool gets dropped, saving a bit of money that gets passed on. Price tracks effort, not the response number.

This is why the cost axis and the utility axis never move together. Utility may fall by half when the target relaxes from twelve to sixteen seconds; cost falls by a fifth. If you assumed proportionality, you would mis-rank every bid. The ratio — not either number alone — is the decision object.

16.3.5 Quotations Across Platforms and Weightages

Vendors quote alternative builds: using Google APIs with AI, the price is twenty lakh rupees; using Amazon Lambda, with a team already well equipped, eight lakh rupees. Availability is comparable today across AWS, Google big data, and Azure, so it may not decide anything. Security features differ per offer. Testability and accessibility get assessed too. And internal fit matters: if my own team does most of its work in AWS, the maintainability utility of the AWS option rises.

The client then weighs everything: hold an internal meeting, rank the attributes one through ten, multiply each benefit difference by its weightage, add up, and divide by the quotation. Bigger procurements pull quotes from TCS, CTS, PeopleSoft, or SAP service providers.

Weightages decide winners, and the client sets them. Think of hiring: you may be the smartest candidate alive — smarter than Shahrukh Khan — but if smartness carries a five percent weightage, you do not get selected. Another job gives ninety-five percent weightage to smartness and hires someone who does not know the ABC of Java. Same candidates, different weightages, opposite outcomes.

16.4 Weighing and Normalizing: The Benefit Matrix

16.4.1 Naming the Pieces

Write the idea as a matrix. Let $i$ index offers — $i=1$ for the AWS-based solution, $i=2$ for the first developer's solution, $i=3$ for a solution from a Bangalore firm — and let $j$ index quality attributes or scenarios. Define $U_{ij}^{\text{current}}$ as the utility today for attribute $j$, and $U_{ij}^{\text{expected}}$ as the utility offer $i$ promises for that attribute. In words: $B_{ij}$ is always what is current against what we expect from this particular solution.

$$B_{ij}=U_{ij}^{\text{expected}}-U_{ij}^{\text{current}}$$

Both utilities are dimensionless percentages between 0 and 100, so $B_{ij}$ is too. The subscript order matters: the first index selects the offer (a row of the matrix), the second selects the attribute (a column). One offer contributes one row; scanning across a row shows everything that offer improves — or damages.

Why subtract per cell instead of comparing raw expected values? Because offers must be judged against the world as it exists today, not against each other in a vacuum. If attribute $j$ already sits at ninety percent utility, an offer reaching ninety-five earns only five points there; the same offer reaching fifty on a neglected attribute earns forty. Subtraction from current bakes that fairness into every cell.

16.4.2 The Current Baseline Is Free

What you already have costs nothing — the current state is the zero-cost baseline. Money buys only deltas. That is why every comparison relates back to current: you are pricing improvement, not existence.

The point sounds small and decides cases. A vendor demo may look dazzling next to another vendor's demo, yet both may sit below what you already own on the attributes you care about. Against the free baseline, both rows go negative and neither deserves money. Demos are compared against demos; economics is compared against today.

16.4.3 Negative Utility Happens

Sometimes you lose on an attribute: the delta goes negative. Buyers still accept such offers when the positive utilities are high and matter more. One owner put it memorably: security? Damn it, I am not bothered. For him, money spent on security buys useless utility — a negative entry he happily accepts elsewhere. The full ratio, with $w_j$ the weightage of attribute $j$ from stakeholder ranking and $C_i$ the quoted cost of offer $i$, reads: multiply each weighted benefit, add them up, divide by the quotation.

$${\text{Value for Cost}}_i=\frac{{\sum }_{j=1}^n{w}_j{B}_{ij}}{C_i}$$

Here $n$ is the number of attributes being scored, each weight $w_j$ comes from the client's ranking exercise (in this lecture's convention the weights sum to one hundred points), and $C_i>0$ is the price tag. So the numerator is a weighted sum of signed utility deltas — positive where the offer helps, negative where it hurts — and the denominator converts those points into points-per-rupee so offers with different prices become comparable.

This is the same benefit-for-cost ratio from Section 16.2, now with explicit weights and a per-offer index. In the textbook treatment (Kazman and colleagues, Software Architecture in Practice), the same construction appears as $B_i={\sum }_j(b_{ij}\times w_j)$ followed by ${\mathrm{VFC}}_i=B_i/C_i$; the lecture's single fraction is that pair of lines merged into one.

16.5 Case Study: NASA's Earth Observation System

16.5.1 The System and Its Goal

The Earth Observation System is a constellation of NASA satellites that gathers data for the US Global Change Research Program and other scientific communities. The mission: process raw data into higher forms. The goal: provide a common way to store data, plus a public mechanism to introduce new data formats. Underneath sits a gigantic database of raw data with plenty of processing waiting for it — a perfect stage for cost-benefit analysis.

The scale explains why economics mattered here at all. The ground system takes in hundreds of gigabytes of raw environmental data per day, computes hundreds of standard data products, and archives the results across eight distributed data centers. The project manager held a limited annual budget while the stakeholder community proposed far more improvements than could be funded — only a small fraction of the wish list would ever receive funding. Choosing that fraction by gut feel was not acceptable for a system of this visibility, so the team ran the full cost-benefit method on the Data Access Working Group portion of the system.

16.5.2 Collate Scenarios, Then Prioritize

First, collate scenarios from the stakeholder community and put them into a priority order. Two samples show the flavor. Priority one: reduce data distribution failures that result in hung distribution requests requiring manual intervention. The last listed: the system should process a 50 GB user request in one day and a 1 TB user request in one week. These raw scenarios then get refined into measurable form.

Notice the raw scenarios are not yet ready for arithmetic. "Hung distribution requests" names a pain without saying how often it happens or how bad is tolerable. Refinement supplies those numbers.

16.5.3 Refinement: Worst, Current, Desired, Best

For each scenario, draw the graph and quantify four points. The worst case is the floor below which we will not even consider the result. The current case is today's level. Desired is what we wish to have. Best is what becomes possible with an infinite budget. Take the last scenario — the 50 GB request in one day, 1 TB in one week — refined as: worst case, the goal is met for at least fifty percent of scenarios; currently we meet it for sixty percent; we wish to achieve eighty percent; the best possible is above ninety percent. One hundred percent is not going to happen — if we can achieve it for ninety percent of scenarios, we are happy.

16.5.4 Voting Without Bullies

Priorities come from discussion plus voting. Consensus is ideal when reachable. Its weakness: heavyweight participants tend to prevail over everybody, so the room looks democratic but is not — everyone around the table becomes a yes-man. The fix is blind voting interspersed with discussion. Votes go in multiples of fives, over two or three rounds, producing a weightage for each scenario. The weights add up to one hundred — you distribute one hundred points across the scenarios.

In the published NASA run, the ten refined scenarios received these votes: ten, fifteen, fifteen, ten, fifteen, ten, five, five, ten, and five for scenarios one through ten respectively — and indeed $10+15+15+10+15+10+5+5+10+5=100$. Multiples of five were a deliberate resolution choice: finer precision felt false in a room full of judgment rather than measurement.

The pro rata rescue deserves its own line of algebra. If collected votes total $V\ne 100$, multiply every vote by $100/V$. A scenario holding forty votes out of a two-hundred-vote pool becomes $40\times 100/200=20$ points — its share of importance is unchanged, but the weights now sum to one hundred and slot straight into the benefit formula.

16.5.5 Assigning Utilities Together

Next, the stakeholders sit down and decide what each utility graph looks like. Teach them the curve shapes first, walk through response examples, then ask: draw the utility for each of these — cost comes later. Numbers are mandatory before drawing: tell the room we cannot work without numbers, so put some number on the worst case. Patterns repeat: the best case earns one hundred percent utility almost everywhere, but occasionally only ninety — like film heroes, even the best leaves you wishing something better had happened. The worst case usually scores zero, but sometimes fifty — scenarios where nobody will spend much effort anyway. Management agrees targets of eighty here, ninety-five there, one hundred where possible. Just because something is desired does not mean an order gets placed — cost may make it unaffordable, and solutions exist in between current and desired at various prices.

In the NASA tables these judgments become concrete rows. Scenario ten, for instance, carries utilities of fifty at worst, fifty at current, eighty desired, and ninety at best — the flat start reflects that nobody treasures a half-met bulk-request goal. Other scenarios score zero at worst, and most reach one hundred at best, with desired values spread between eighty and one hundred.

That exchange corrects a natural misconception. It seems plausible that "best case" means "best value for money," because every other business conversation mixes worth with price. The method refuses the mix: the best case anchors the top of the utility scale at one hundred before any price is spoken, precisely so that later cost comparisons cannot bend the scale. Affordability re-enters only at the ranking step, where costs divide benefits.

16.5.6 The Roshugolla Curve

Diminishing returns deserve an edible mascot. The theoretical maximum a stomach can take is probably twenty roshugollas. But after five, the curve flattens: five roshugollas give one hundred percent utility, and so does twenty. Two pieces deliver maybe eighty percent satisfaction, three pieces reach one hundred, and everything beyond wastes money — the tail even dips. Now flip it into procurement logic: if any quantity above three costs the same, but the package forces you to take twenty, and the package is worth it overall — buy the twenty and dump the extras if necessary. Bundles override per-unit rationality.

Drawn out, the curve starts steep — piece one is bliss, piece two still adds real satisfaction — then hits its ceiling around piece three to five, stays flat through piece twenty, and finally sags as regret sets in. The exact digit at two pieces matters far less than the shape: steep rise, early ceiling, long flat tail. That shape is exactly what a performance utility curve looks like once a response threshold is comfortably met — extra spending past the knee buys nothing measurable.

The bundle twist is the part students miss. Classical optimization says buy three pieces and stop. Real procurement says the vendor sells boxes of twenty at one price, and if the box as a whole beats the alternatives, you take the box and discard the surplus. Architectural strategies arrive as such bundles, which is precisely why Section 16.6 insists strategies are packages, not single items.

16.5.7 Curve Shapes and Fitting

The shapes worth teaching stakeholders: step graphs, diminishing returns, increasing returns, sinusoidal curves. Give examples, let them pick. If no curve is given, fit one: between known points such as ten, eighty, ninety-five, and one hundred, draw a smooth line — engineers know how to fit a curve through scattered points.

Each shape encodes a different economic story. A step graph says value jumps only at a threshold — think of the fifteen-second reconciliation wall from the negotiation. Diminishing returns say early gains dominate — the roshugolla. Increasing returns say value explodes only past critical mass — a marketplace becomes useful when enough sellers join. A sinusoidal curve says too much of the response starts hurting — over-provisioned security that blocks legitimate users. Letting stakeholders choose from named shapes keeps the meeting moving; asking them to invent mathematics does not.

Real-world: this exact pipeline ran inside NASA's Earth Observing System Data Information System to triage architectural upgrades under a budget that could fund only a fraction of stakeholder wishes — evidence that utility curves and weighted votes survive contact with mission-critical engineering.

16.6 Running the Numbers: Strategies, Costs, Ranking

16.6.1 Commitments Come With Quotations

Each vendor proposes strategies, and each strategy touches specific scenarios. Strategy one addresses scenarios three, five, and six. Strategy two works only on scenario eight. Strategy three attends to nine and ten — attend to those two and customers stay very happy. The remaining strategies each cover their own smaller sets across the table — some a single scenario, some a pair. Alongside, vendors commit to response levels inside their quotations: your current is five percent failure, we can give you two percent; you suffer less than one percent loss today, we will guarantee zero percent loss, SLA signed; the sixth one also zero percent. Without a commitment on response, no order gets placed.

The commitment is what turns a quotation into an economic object. A promise of "better" cannot be placed on a utility curve; "two percent failure instead of five" can. Once the promised response level exists, interpolation converts it into a utility number, and the arithmetic of Section 16.4 takes over.

16.6.2 Interpolation and Extrapolation

An expected response rarely lands exactly on a labeled node of the utility curve. When it falls between nodes, interpolate to get the utility; when it falls outside the drawn range, extrapolate. This is the same interpolation explained earlier in the course — read the neighboring points, slide along the fitted curve, take the value.

For straight-line segments the sliding rule has a formula. Given two known points $(x_a,y_a)$ and $(x_b,y_b)$, where $x$ is the response level and $y$ the utility, the utility at a point $x$ between them is:

$$y=y_a+\frac{x-x_a}{x_b-x_a}(y_b-y_a)$$

The fraction $(x-x_a)/(x_b-x_a)$ measures how far along the segment the new point sits — zero at the left end, one at the right end — and multiplies the utility change across that segment.

Extrapolation is the same move made outside the drawn range, and it deserves suspicion. Beyond the best-case anchor the curve is flat by construction — stakeholders already said nothing beyond that level adds value — so extrapolated gains past the ceiling should be read as zero, not as continued growth.

16.6.3 The 950 Computation

Now assemble the table. Columns: current utility, expected utility, difference, weightage, product. For strategy one, three active rows:

Add the products and strategy one's total benefit is nine hundred fifty:

$$B_1=15\times 20+15\times 30+10\times 20=300+450+200=950$$

The weightage column comes straight from the voting round: scenario three carries fifteen points, scenario five carries fifteen, scenario six carries ten. The differences come from each scenario's utility curve after interpolation of the promised response levels. Blank cells elsewhere in the table simply mean the strategy does not touch that scenario — untouched scenarios contribute nothing rather than zero-effort guesses.

The re-explanation compresses to a three-beat rhythm worth memorizing: difference, multiply, sum. Difference reads the curve; multiply applies importance; sum collects the strategy's whole footprint.

Other strategies total: two hundred for strategy two; two hundred seventy-five for strategy three; then one hundred, one hundred twenty, fifty, seventy, one hundred fifty, two hundred twenty-five, and twenty-five for strategies four through ten. Entries can go negative — strategy three hands you three hundred points on scenario nine but loses twenty-five on scenario ten, because its bundling behavior helps bulk orders while slightly hurting oversized ones. One bidder jokes: place the order on me and I will make this situation worse somewhere — if you badly need scenario nine solved, you pay, and compromise somewhere else.

16.6.4 Opening the Cost Envelope and Ranking

Keep costs sealed while benefits are computed — technical tenders first, cost tenders opened after. List each bid's price, divide total benefit by cost, and rank the resulting value-for-cost ratios; the highest ratio is ranked one. Say the leader costs 1.2 million dollars and the others ask 0.4 million each. If the budget is 1 million dollars, the leader is out of reach. Scan the rest: one bid yields only 0.22 — not worth it. Option three delivers 0.69 for 0.4 million dollars. Even the 1.2 million dollar leader reaches only 0.79 — three times the cost for a gain of 0.10. Management may well declare the extra benefit not worth the extra money and award the deal to option three.

16.6.5 Marginal Benefit, Budgets, and Social Overrides

The ranking feeds a management conversation, not an automatic order. The company has other priorities — maybe everybody's salary increase, maybe a special bonus this year — so spending 0.8 million more dollars chasing a small ratio gain may lose. Beyond money sit social cost-benefits with overriding power: government priorities, the company's future outlook, factors no spreadsheet captures. Bring them in after the calculation, not before.

The ordering matters as much as the factors. Social considerations invoked before the arithmetic destroy the arithmetic's discipline — every stakeholder discovers a "strategic" reason their favorite bid should win. Invoked after, they act as a documented override: the numbers spoke, management chose otherwise, and the record shows both.

16.6.6 Strategies Are Packages, Not Single Items

The correction fixes a tempting misreading of the benefit matrix. Because the matrix displays per-scenario cells, students imagine benefits are à la carte — pick your favorite cells, pay for those alone. But a strategy is one engineering effort whose side effects land where they land; the cells describe the package, they are not a menu. This is the procurement twin of the roshugolla bundle logic from the case study.

16.7 Management Functions for Architects

16.7.1 The Function List

Management decomposes into functions: planning, organizing, implementing, measuring — and then governance, treated separately below. This material reads light, and going through the notes is enough; questions from here tend to be practical application oriented rather than definitional.

The list is worth carrying in order, because each function feeds the next: a plan tells you what to organize; the organization implements; measurement tells you whether the implementation followed the plan; and governance closes the loop by turning measurements into improved plans.

16.7.2 Planning: Two Plans Meet

Planning runs in two directions. Top-down: management intends the software, estimates what it should cost, and distributes that cost across aspects of the software — a quick process based on experience, giving a broad allocation. Bottom-up: break the job into small fragments, find the cost of each fragment, and add them up. The twin plans meet, get reconciled with a bit of matching left and right, and produce the development plan.

The two directions fail in opposite ways, which is why both are needed. Top-down planning is fast but can allocate numbers no real work fits inside; bottom-up planning is accurate but optimistic — fragments estimated one at a time forget their integration costs. The reconciliation meeting is where experience meets arithmetic, and the gap between the two plans is itself information about risk.

Agile keeps planning too. The claim that agile means no planning misses the point: you remain adaptive — you hold a plan, then change against the plan with good justification. Openness to change is the discipline, not absence of direction. Without a plan there is nothing to adapt from; a sprint backlog is a plan with a short shelf life.

16.7.3 Organizing: Architect and Project Manager

Organizing puts key people in place, and for architects the pairing that matters is project manager plus architect — they complement each other and build solutions together. Two study frames describe the PM craft: ITIL gives the service framework, and the PM Book — the older edition referenced here, book three — lays out process groups: initiating, defining the project and getting authorizations; planning, securing the three pillars of scope, time, and cost; executing, where the PM's talent goes into tracking progress against scheduled cost and scheduled time; monitoring and controlling, keeping track, giving feedback, regulating the project; and closing, tying up loose ends and formally handing over after deployment, into maintenance and continuous monitoring. Closing matters — projects do not just evaporate.

The pillar joke lands the interdependence: relax scope and any time and cost will do; relax time and the project never ends, so any scope and cost pass; relax cost and you fix scope and time, then name a price nobody can afford. All three pillars together tie down a project. Each pillar constrains the other two — which is why change requests that add scope must renegotiate time or cost, never silently absorb them.

16.7.4 Knowledge Areas

The same PM Book edition lists knowledge areas: integration management, scope management, schedule management, cost management, quality, resource, communication, risk, procurement, and project stakeholder engagement. Stakeholder engagement is a shared duty of project manager and software architect alike — keep stakeholders on board with an up-to-date picture of progress. In an agile environment there is always a working product, and the customer or user sees it transparently.

Notice how many of the ten areas are people-shaped rather than artifact-shaped — communication, stakeholders, resources. The technical work fails quietly when those areas starve, which is why the architect cannot treat them as the PM's private business.

16.7.5 Agile Plus DevOps

Two movements dominate modern delivery. Agile brings business stakeholders and designers close together. DevOps brings development people and operations close together. Put them together and business requirements flow continuously and smoothly into build and run — the net result is that projects seem to stay open all the time, continuously improving the product against current requirements. Human creativity and effort prove infinite; great products of the last two decades just keep adding features.

And with artificial intelligence advancing, humans are not becoming obsolete — the people who become obsolete are the ones who stop catching up with technology. Keep current: watching Uncle Bob — Bob Martin — on YouTube sharpens design fundamentals, and his SOLID principles remain required vocabulary for coders, developers, and designers.

16.7.6 Global Teams and Cultural Care

Global software development became real at scale. Offshore and on-site teams merged so closely that far-west corporates run day-to-day activity from the east, and people choose to live in India while serving employers abroad. Earlier you needed cultural correctness only in correspondence and during visits; now, always on audio and video, you must be culturally right all the time. Teams span Bangalore, Gurgaon, Noida, Kolkata, Hyderabad, Seattle, Los Angeles — sometimes you cannot tell whether a colleague sits in another city or another continent. Understand people's skill sets, thinking styles, ethics, and dedication. Some campuses now run virtual reality conference rooms where remote participants appear seated in one shared room.

16.7.7 Implementing and Measuring

Implementation issues are everything DevOps: trade-offs, incremental development, tracking progress with the many tools that now watch continuously, continuous integration, continuous deployment, continuous testing. Measurement has become absolutely important — metrics are the keyword, and without metrics you cannot do justice to projects today. Track the total cost of a project including the rolling cost of maintaining it, year after year.

That last sentence deserves emphasis because it closes the loop with this lecture's opening formula. The incremental cost in a benefit-for-cost ratio is honest only if it includes the maintenance tail; a cheap strategy that doubles yearly support costs re-prices itself the moment total cost of ownership enters the denominator.

16.8 Governance

16.8.1 Continuous Improvement Comes From Governance

Governance has entered popular parlance. Most professionals work in CMMI level five certified companies, and the fifth aspect of CMMI is continuous improvement — which grows directly out of governance. Planning, organizing, implementing, and measuring feed it; governance closes the loop.

The loop reads naturally in process terms: the plan sets expectations, implementation generates facts, measurement compares facts against expectations, and governance decides what to change about the plan, the organization, or the controls before the next cycle. A company at CMMI level five is one where that loop runs on evidence rather than heroics — improvement is institutional, not accidental.

16.8.2 Boards, Controls, Compliance, Accountability

A governing board owns the control systems: compliances toward internal and external regulators, and — for global software — the regulations of each individual country where the software operates. Governance also installs processes that support effective management and develops practices ensuring accountability.

For globally deployed software the compliance surface multiplies: data-protection rules, financial reporting duties, and sector regulations differ per country, and a system serving several countries must satisfy all of them simultaneously. That is why control ownership sits with a board rather than a team lead — only a body above every delivery unit can enforce standards across all of them.

Accountability is the design goal underneath the paperwork. Controls exist so that when something goes wrong, the organization can find out what happened, who decided, and what to change — without depending on memory or goodwill.

The closing summary of the whole arc: project managers and architects work closely, sometimes as best of friends, and see projects through together. The architect leans technical but carries heavy client communication, keeping the client on board, and can be a big support to the project manager. The project manager runs a technical function too — stewarding all resources on the project — and in an agile environment, the project manager's agility has a big bearing on what the software architect can accept.

Neither role succeeds alone: the architect's utility curves mean nothing without the PM's budget discipline, and the PM's schedule means nothing without architecture that can deliver into it.

Exam Guidance Summary

• Prepare the entire syllabus for the comprehensive exam; the second half sits on the first half. Revise the first half if midterm memory is weak.
• Open-book means nothing without advance familiarity. Know where answers live; never plan to search or study during the exam. Only printed material is allowed offline; tick-mark affordable pages if needed. Bound handwritten notebooks were historically allowed (hard or spiral bound, own handwriting); verify current rules with the examination department.
• Read every question carefully; wrong-question answers score nothing. Deliberately wrong or misleading questions now appear — state assumptions, or prove why given data must be wrong.
• Average marks are good marks; evaluators with decades of industry and teaching experience detect got-up answers. Abstract questions map back to syllabus tick lists.
• Cost-benefit questions may require all nine steps with calculations, fewer steps, interpolation or extrapolation, or just comparing supplied costs and benefits. Votes/weights should total one hundred; if not, normalize pro rata by multiplying each vote by one hundred over the collected total. Practice the full pipeline once, then stop over-preparing.
• Budget time by marks: minutes divided by marks, never exceeded (one hour per 10 marks on a 30-mark, 3-hour paper). Concise answer first, elaborate only with leftover time. Bullet points can score fully if the points are covered. Keep one uniform presentation style; expectations scale with the marks a question carries.
• Management and governance topics yield practical application-oriented questions; going through the notes suffices.

For quick self-check before the exam: be able to compute a benefit as expected utility minus current utility per scenario, weight it, sum it per strategy, divide by cost, rank the ratios, and apply the budget check — that single chain covers most of what this lecture can ask.

Key Industry Applications

• Real-world: SLAs convert quality attributes into payment obligations, forcing measurable responses instead of "feel" judgments. Cloud availability clauses are the everyday example — uptime below the signed number becomes invoiceable credits.
• Real-world: proof-of-concept trials vet vendor performance promises before contracts — demand to see it in practice, as earlier generations did by visiting sites where candidate solutions already ran.
• Real-world: account reconciliation systems (daybook versus bank entries, JDBC over MySQL) express business needs as ten-second performance requirements — and show how a step utility curve emerges from a competitor benchmark at fifteen seconds.
• Real-world: cloud platforms — AWS, Google big data APIs with AI services, Azure, Amazon Lambda — compete on availability, security features, and fit with in-house team skills; quotations bundle platform choice with price (eight lakh versus twenty lakh rupees).
• Real-world: large procurements collect competing bids from TCS, CTS, Wipro, Capgemini, PeopleSoft, or SAP service providers and rank them by value for cost, with technical tenders opened before cost tenders.
• Real-world: NASA's Earth Observation System applies the full nine-step analysis to satellite data distribution and bulk processing scenarios (50 GB per day, 1 TB per week), triaging far more proposed improvements than its budget could fund.
• Real-world: subscription packaging (silver/gold tiers, user-count bundles on platforms like OCI) shows why strategies arrive as indivisible packages — take it or leave it is a pricing model, not an insult.
• Real-world: CMMI level five organizations institutionalize governance-driven continuous improvement; global teams coordinate across Bangalore, Gurgaon, Noida, Kolkata, Hyderabad, Seattle, and Los Angeles with VR conference rooms bridging sites.
• Real-world: Uncle Bob (Bob Martin) videos and SOLID principles remain the recommended refresher for design fundamentals amid AI-era change.

The common thread across all of these: wherever money meets quality attributes — contracts, procurements, budgets, or platform choices — the benefit-for-cost discipline from this lecture is the working tool of practicing architects.