Measuring Value

A savings number is also a claim about capability. As the Introduction put it, cost optimization has no meaning apart from the outcome it is supposed to protect, so I want every saving stated with what the service will still be able to do afterward: the reliability, recovery, and customer experience it keeps, and any it gives up.

How to read this chapter

This chapter is about judging whether a change was worth making: the unit of measurement, the conditions of the comparison, the cost of getting there, and what kind of benefit arrived.

1. Choose a unit that means something — component allocation and unit economics, with their limits.
2. Preserve the conditions of the comparison — what makes two states comparable at all.
3. The double bubble — paying for old and new environments at once during a migration, with the payback arithmetic.
4. The decision due today — deciding on an extension when the analysis cannot wait.
5. Name the benefit that actually occurred — savings, cost avoidance, released capacity, and when a saving reaches the bill.
6. One improvement, several claims — when many teams point at the same saving.
7. Carry the operating organization into the comparison — why the first estimate for owning infrastructure comes out 40 to 50 percent cheaper, and what it leaves out.
8. A number worth carrying forward — a value record for the migration.

The lesson to carry: a savings number is a claim until its conditions, its staffing, its alternative, and the date it reaches the bill are stated — and the strongest comparisons survive having the operating organization counted.

Choose a unit that means something

Consider a hypothetical website, separate from the constructed portfolio, with $30 million in annual computing spend and 300 million completed customer transactions in that year, counted one consistent way. Its average computing cost is:

$$\frac{\$30{,}000{,}000} {300{,}000{,}000\ \text{completed transactions}} =\$0.10\ \text{per transaction}.$$

If $1.5 million of that total is attributed to load balancing, the same division gives $0.005 per transaction, or half a cent, and load balancing is $1.5 million / $30 million = five percent of the attributed total.

That half cent is an allocated average. It tells us neither what another transaction costs nor whether cutting that line would leave the service intact. Azure Application Gateway v2 shows why: it charges a fixed hourly amount per gateway, bills the capacity reserved by a minimum instance count whether or not traffic uses it, and counts capacity units by whichever of connections, throughput, or compute is highest.³ Extra transactions could cost almost nothing there, or raise the bill through connections and TLS handshakes that need not track completed transactions.

Finance may want all shared costs allocated so it can examine total efficiency. Engineering needs to know which resources and commitments would change if another million transactions arrived next month. Product needs support and other business costs to assess a customer’s profitability; our computing-only measure cannot answer that question. The report should make clear which of these questions its number answers.

Preserve the conditions of the comparison

A unit-cost report can stay concise if there is a reliable route back to its definitions, kept current by the teams who own them. For the website, that includes what counts as a completed transaction, whether failed work remains in the cost, which customers and operations are included, and how shared services, support, commitments, discounts, and one-time work are treated. The period and architecture version matter too, because we are comparing a system in particular circumstances, not a timeless attribute of the business. A changed outcome definition or allocation method should be visible as such, and a credit that reduced the month’s bill should be findable without dismantling a claim that the architecture suddenly became more efficient.

Azure reservation accounting gives us a concrete example. In the Actual Cost dataset for Enterprise Agreement and Microsoft Customer Agreement customers, VM usage covered by a reservation is priced at zero; the reservation purchase is recorded separately. Amortized Cost spreads that expense over the benefit period and attributes the used portion to the resources receiving it, with unused reservation cost identified separately.⁴ For an ongoing cost-per-transaction comparison, I would use the amortized view and agree where the unused portion belongs. Otherwise a resource-level report can make committed compute look free, or make an application’s unit cost improve while its unused commitment moves outside the report. Keep the purchase and billing view available for Finance’s reconciliation; FOCUS exports carry both views as BilledCost and EffectiveCost (Chapter 6). Changing the view has changed the explanation, not the expenditure.

Imagine a hypothetical service whose cost per accepted task falls after it stops accepting the hardest tasks. The remaining service may be cheaper to deliver, but somebody still has to account for the displaced work. The reverse is possible too: adding a difficult customer can raise aggregate cost per transaction even while the system improves for every existing customer, a mix effect Finance will recognize from its variance reports. Without useful cohorts, we might congratulate a team for narrowing the service and criticize it for successfully expanding it.

The double bubble

A major architectural change often requires old and new systems to run together while we move between them. I call that overlap a double bubble, although the expenditure need not double exactly, and while it lasts a steady-state efficiency measure no longer explains the whole bill.

Chapter 1’s portfolio carries a small one, most visibly $24,000 for the retiring system and $18,000 for its replacement every thirty days. The payback arithmetic is easier to see in a much larger migration on the hypothetical website. Assume constant demand, with the annual amounts spread evenly across twelve months. The old system costs $30 million / 12 = $2.5 million per month and completes 300 million / 12 = 25 million transactions per month. Suppose its proposed replacement would supply the same outcomes and obligations for $2 million per month after transition.

During a month of full overlap, assume each environment incurs its full recurring cost while together they deliver the same 25 million outcomes. Leaving migration labor and one-time cost aside for the moment:

The measure gets worse on the way to a potentially better destination. That deterioration is part of the proposed route, which is why I would want Finance involved before the organization starts treating it as evidence that the project has failed.

There is an especially convenient mistake available when both systems process copies of the same transactions. Counting the copies as separate useful outcomes gives $4.5 million / 50 million = $0.09, apparently better than the original $0.10, while we spend more for the same customer outcomes. Nobody needs to invent a number; an unsuitable denominator does the work for them. The report needs one count of business outcomes, with the combined cost shown beside the old and proposed steady states. It also needs a forecast of what will stop being paid for, and when, which may not follow the architecture diagram’s schedule once data copies, replays, and commercial commitments outlast the technical cutover.

The route to the saving has a cost

Suppose the hypothetical migration needs four months of full overlap and another $1 million of one-time work. Relative to continuing the old system, the new environment adds $2 million in each overlap month, so the modeled incremental transition cost is:

$$(4\times\$2\text{ million})+\$1\text{ million} =\$9\text{ million}.$$

After retiring the old system, the steady monthly difference is $2.5 million − $2 million = $0.5 million. Ignoring discounting, taxes, and growth, and assuming the whole difference reaches the bill at cutover, recovering the incremental transition cost takes $9 million / $0.5 million = 18 months after cutover, or 22 months from the beginning of the four-month migration. Simple payback says when the transition cost is recovered, not whether the project is worth doing; that depends on how long the difference lasts and what else the money could have done.

The $0.5 million is the fragile number: a small gap between two large estimates. If the replacement settles at $2.25 million a month, a 12.5 percent miss, the difference halves and recovering the $9 million takes 36 months after cutover. Before I trusted the 18, I would ask whether the $2 million was measured at production volume, extrapolated from a pilot, or quoted.

Now delay cutover by a month. Against the original plan, month five costs $4.5 million instead of $2 million, a $2.5 million adverse variance: the old system’s month we expected not to pay for. Against never starting the migration, the same month adds $2 million of overlap, and the expected $0.5 million difference doesn’t arrive. The accounts reconcile, $2 million + $0.5 million = $2.5 million, but they answer different questions, so I would agree on the comparison before arguing about the number.

Payback moves further than the calendar. The transition cost becomes (5 × $2 million) + $1 million = $11 million, recovery takes $11 million / $0.5 million = 22 months after cutover, and breakeven moves from month 22 to month 27: four months of the steady-state difference ($2 million / $0.5 million) for each month of slip, plus the month itself.

Payback is also a cash measure. Qualifying implementation work may be capitalized and amortized while both environments’ cloud charges are expensed as incurred, and US GAAP and IFRS treat the cost of configuring a supplier’s cloud software differently.⁵ Finance decides the treatment of the $1 million; the business case should label which figures are cash, so nobody compares a cash payback with an operating-expense report and concludes the project is behind.

The decision due today

Suppose a cutover check fails in month four and the team asks to keep both environments for another month. We already know the price: a $2.5 million adverse variance against plan and five months on the breakeven date. Shutting down the old system anyway would make both measures look better while abandoning the service assumption on which the investment was approved.

The immediate decision needs an explanation of what failed, which obligation the extra expenditure protects, what evidence would let us end the overlap, and someone who owns that work and the date we review it. Finance deserves a revised path to the destination, not an instruction to ignore costs until Engineering is satisfied.

Another extension can eventually change more than the schedule, and the test for that should look forward. The $8 million of overlap already paid is spent whether we finish or cancel, so it shouldn’t decide the next step. What matters is whether the remaining overlap and work cost less than finishing would save: two more months at $2 million each take eight months of the $0.5 million difference to recover, easy to justify for a system expected to run for years. An extension with no credible end date is a different conversation, which may lead to a different architecture, a narrower migration, or cancellation, and a capacity team has to be able to raise it while explaining why turning off the old environment would not solve the problem.

This is where I resist making unit economics the sole judge of a tactical decision. Supporting a necessary transition may mean accepting a worse number for a while. The deterioration should stay visible, but the measure cannot decide which customer commitment we are entitled to abandon in order to improve it.

Name the benefit that actually occurred

The simplest case is Chapter 4’s worker transfer: batch’s allocation fell by 8 × $40 × 30 = $9,600, but the enterprise saved nothing and spent nothing extra, and the delay to batch work is a separate cost that needs its own evidence.

Provider dashboards blur the line. Microsoft estimates reservation savings as what the covered usage would have cost at pay-as-you-go prices minus the reservation’s cost, used and unused.⁷ That benefit is real, but it is measured against a price we chose not to pay, so I would report it as cost avoidance unless the reservation lowered spending from an earlier baseline.

Timing belongs in the name too. From cutover, the website’s run rate is $0.5 million a month lower, but the saving is realized only as the old system’s charges stop. Reservations bought for the old environment keep billing until they expire, are exchanged, or are used by another workload, and under a provider spending commitment, lower consumption reduces payments only while total spending stays above the commitment (Volume II, Chapter 20). Finance will want the payback rebuilt from the actual end dates.

The distinction protects good work as well as good accounting. If every improvement has to be called cash savings to earn recognition, we create an incentive to misuse the term. Capacity released for a consequential launch deserves credit for making the launch possible, and some value, such as a customer commitment kept or a recovery option preserved, resists a credible dollar figure altogether. Those judgments need an explanation and an owner; an invented financial effect makes the next review harder to trust.

One improvement, several claims

Consider a hypothetical change in which an application team changes a workload, the platform team helps implement it, and capacity specialists identify the opportunity and follow the result. Each team reports the improvement, quite reasonably, because each contributed. The mistake comes later, when somebody adds the reports together.

We can recognize all the contributors while giving the improvement one shared record: the baseline, resource change, kind of benefit, financial treatment, effective date, and supporting evidence. I would ask Finance to agree the baseline and treatment before anyone reports the number. Each team can refer to that record when describing its work, and if the result changes, revising the record while preserving the earlier estimate lets us find out whether the proposal was optimistic, delivery was late, or the cost treatment was mistaken.

Vested interests, which Volume II, Chapter 17 takes up in general, include ours: a capacity team rewarded for reported savings has reason to prefer the larger number, as does a team defending a technology or a budget. That doesn’t establish dishonesty, but it is a good reason to keep the comparison inspectable, including the evidence that makes the preferred answer less comfortable.

Carry the operating organization into the comparison

Changing a platform commits us to more than a new unit price: a transition to fund, an operating capability to supply, and eventually an exit with a double bubble of its own. One of the comparisons I meet most often now is a proposal to own infrastructure instead of buying a service, because some high-profile people have argued that owning is cheaper than cloud. Sometimes it is; often it isn’t. The point is what most people skip when they do the calculation, and I have seen the same omissions many times, at many companies.

The proposal usually arrives in a sentence: buy some hardware, put it in a colocation facility, and stop paying for BigQuery. Running your own infrastructure moves risk onto you, security included, so not all of it is about cost. But the first question is what the public-cloud price pays for: computers and a facility, and usually several teams as well.

The first comparison usually makes the move look obvious: private comes out 40 to 50 percent cheaper, so why would we not do this? It is usually an engineering leader’s calculation, often made after reading a blog post, and it usually prices the cloud at the public list rate rather than the negotiated discount, which is confidential even from most internal users (Chapter 1’s effective-rate point). Engineers calculate all the time, but not the way Finance does. Many don’t know how many years to spread the hardware cost across, and many never talk to vendor management about discounts.

The calculation leaves out most of what makes a data center work: a whole floor of racks, the network that keeps them running, power and cooling, the structure itself, the rights to bring power in from the municipality, insurance, and fire protection. It leaves out the staff who receive the equipment, rack and stack it, and do the wiring and networking, and the teams for physical security as well as site reliability. If staff are counted at all, they are the ones the estimator can see, perhaps a team of 10 managing the virtual machines.

Owned capacity also needs room left empty. My rule of thumb is that if you buy 100 racks, you leave 20 free: a 20 percent buffer for failures nobody can schedule (motherboards fail, systems go dark) and for an unexpected uptick.

The classic sequence of mistakes makes a usable checklist for reviewing an ownership proposal:

1. No staff.
2. No contingencies or insurance.
3. No infrastructure or security.
4. A one-to-one comparison, as if all 100 racks would be full of workloads.
5. No ramp. On public cloud you don’t pay for 100 racks before you use them; it isn’t perfectly elastic, and a commitment to a specialized SKU changes that, but it is far more elastic than hardware already bought.

Staff is the largest of these. Engineers aren’t HR and don’t see total compensation; they count base salary and leave out benefits. So when someone says we pay 14 cents an hour for a SKU on public cloud and it will cost only 5 cents on private, the staff they add is maybe 7 or 10 percent. In my experience, more than half the cost of the infrastructure is the staff.

For illustration, assume generously that the 5 cents covers everything except people and spare racks. Holding 20 of every 100 racks free makes each used hour cost 5 / 0.8 = 6.25 cents. If staff is half the total, the total is 12.5 cents; at 55 percent, 6.25 / 0.45 ≈ 13.9 cents. The promised saving of (14 − 5) / 14 ≈ 64 percent shrinks to at most (14 − 12.5) / 14 ≈ 11 percent and is gone once staff passes about 55 percent, before the ramp or any negotiated discount on the 14 cents. In my judgment the real public price is fairly competitive with private before staff is added; unless you operate with an economy of scale, ownership is not a winning game. A small business running a machine in the back room may genuinely be cheaper, because it doesn’t need a team of 20, 30, or 50.

Coverage makes the staff line lumpy as well as large. Google’s SRE book derives a minimum of eight engineers for a single-site team keeping a primary and a secondary on call around the clock.⁸ An owned platform that needs its own rotation adds eight people, 8 × $240,000 = $1.92 million a year at Chapter 1’s planning value for a year of one person’s capacity, enough to turn a hypothetical $1.5 million infrastructure saving into a $420,000 loss. If an existing rotation absorbs the platform instead, I want to know what that rotation stops doing.

The biggest story in all of this is that engineering teams do financial calculations without talking to Finance. Owned equipment is capitalized and depreciated, so I would compare cash schedules, including each refresh and its overlap, rather than a year of depreciation beside twelve monthly cloud bills.

There is always one cost found late that nobody factored in, such as Chapter 2’s annual business-continuity test, which would have meant owning double capacity all year. Buying hardware also exposes you to market forces, supply-chain risk, and import and export controls that a provider otherwise absorbs or handles for you. Memory has become one of the most expensive parts of that market, a cycle Volume II, Chapter 19 traces through the latest forecasts.

The cloud side deserves the same scrutiny: commercial terms the organization can actually get, the risks that stay with the customer, and staff time charged to both sides on the same basis. Counting everything doesn’t always change the decision; Chapter 3 describes what happens when an executive already believes private is cheaper. The capacity team’s job is to make sure the comparison in front of that executive is objective.

A number worth carrying forward

Those reviews are where we find out whether the old cost stopped, the customer received the promised outcome, the released capacity found a use, and the benefit survived the next change in workload. A savings announcement on its own can’t tell us any of that.

Every number in that table assumed 25 million transactions a month for the 22 months it takes to pay back. That is the assumption most likely to be wrong, and a change in demand can move the old system’s cost and the replacement’s by different amounts, widening or closing the difference the whole case depends on. How much work will arrive, when, and of what kind is where Volume II begins, with Chapter 14 on seasonal variation.

Notes and sources

1. Tim O’Brien, “What’s the Secret to FinOps? I’ll Tell You Mine—Now Share Yours!”, May 11, 2025. The source of the opening’s questions about staffing, licensing, and list versus negotiated prices. It describes a recurring experience, not a particular proposal or realized saving.↩︎

2. FinOps Foundation, “Unit Economics”, FinOps Framework capability, checked October 4, 2026. Relates technology spending to the value it creates and divides unit metrics into resource-efficiency and business categories, with the examples quoted here. The website and migration examples are hypothetical.↩︎

3. Microsoft Learn, “Understanding pricing – Azure Application Gateway”, accessed October 3, 2026. For the v2 SKUs: a fixed hourly charge; capacity units reserved by the minimum instance count and billed regardless of use; capacity units counted by the highest of persistent connections, throughput, and compute. Using it to separate average from marginal cost is the author’s application.↩︎

4. Microsoft Learn, “Understand Azure reservations usage for Enterprise Agreement and Microsoft Customer Agreement” and “View amortized benefit costs”, accessed October 3, 2026. Documents Actual Cost, Amortized Cost, and unused reservation charges. The choice of unit-cost boundary is the author’s application.↩︎

5. Financial Accounting Standards Board, Accounting Standards Update 2018-15, August 2018 (internal-use software rules applied to implementation costs in a cloud service contract); IFRS Interpretations Committee, “Configuration or Customisation Costs in a Cloud Computing Arrangement (IAS 38)”, agenda decision, March 2021 (a customer often cannot recognize an asset for configuring a supplier’s software). Both accessed October 3, 2026. Orientation for a conversation with Finance, not accounting advice.↩︎

6. FinOps Foundation, “Unit Economics”, checked October 4, 2026. Lists “Separate avoidance, savings, and cost reduction measurements” among the FinOps practitioner’s activities. The five benefit names and their definitions here are the author’s.↩︎

7. Microsoft Learn, “Understand Azure reservations usage for Enterprise Agreement and Microsoft Customer Agreement”, “Determine reservation savings,” accessed October 3, 2026. Estimates savings as pay-as-you-go cost minus reservation cost, including the unused portion. Classifying the result as cost avoidance is the author’s interpretation.↩︎

8. Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy, eds., Site Reliability Engineering (O’Reilly, 2016), Chapter 11, “Being On-Call”, by Andrea Spadaccini, checked October 4, 2026. Derives the eight-engineer single-site minimum from a 25 percent on-call limit, primary and secondary coverage, and week-long shifts, and cautions that the approach might not be immediately applicable to all contexts. The $1.5 million proposal is hypothetical.↩︎