From Understanding to a Decision — First edition

At the beginning of this volume, the bill was something somebody had to be able to read. Reading it properly took us into the work: what the customer needed, what the systems consumed, which resources could substitute for each other, and which obligations would remain after a resource was released. By the end, an efficiency proposal needed an account of value and of the capability required to keep operating it.

That is enough to begin making better decisions. It is also enough to recognize when an attractive number leaves the governing question unanswered. A database can be lightly utilized and still need its recovery capacity. A model can produce fewer expensive tokens and still fail to complete the task. A hardware purchase can improve the unit rate while asking the organization to take on operating work it has not staffed. The specialists’ evidence and the customer’s purpose have to travel with the number.

For a first application, choose one decision that matters soon. It might be a rollout, an AI feature, a database expansion, or a proposal to retire an environment. Give it a boundary small enough that you can follow the work and large enough to include the consequence. Then build a record that someone else could examine:

Question	What the decision record needs
What must remain possible?	The useful outcome, service conditions, and person entitled to accept a change
What has been measured?	The workload, tested configurations, measurement interval, and limits of the evidence
What would we acquire or release?	Compatible resources, qualified readiness, failure conditions, and dependencies
What changes economically?	Charges, attribution, cash timing, continuing obligations, and displaced work
Who can make it happen?	Technical, business, operational, and funding owners with the relevant authority
What would reopen the decision?	A changed workload, missed date, failed experiment, or revised customer plan

If one of those answers is missing, give the investigation an owner and a date. A missing measurement may require a focused experiment. A missing service obligation needs a business decision. A missing account of continuing costs needs Finance and procurement. Putting all three under a general request for better data will leave somebody waiting for the wrong thing.

The constructed web-service case gives us an example we can already act on. Staging the launch, borrowing batch workers, and ordering a new failure group each has a distinct consequence. We can inspect the tested rate, calculate the failure allowance, price the new group, and identify the work deferred by the transfer. We can also see that the temporary transfer ends before the new group is estimated to be ready. Understanding the system exposes the gap; it does not grant us permission to extend somebody else’s agreement.

Volume II, Managing Demand, Risk, and Scale, takes up that continuing responsibility. It begins with seasonal variation, then follows demand across the large customers and the long tail. Relationships, reserve rules, anomalies, commercial commitments, and the monthly review show how to keep the decision connected to what actually happens. It retains the same portfolio, and the chapters continue from 14 through 24.

You do not need to finish the second volume before doing useful work with this one. Take the record back to the people affected and see whether its conditions mean the same thing to all of them. The answer may change the proposal. That is a useful result, especially while the choice is still available.