What the computing costs, whether the systems can do the work, and who can accept the answer are different questions. This part gives each of them a chapter.
The first is about cost. Releasing a resource, cutting a team’s allocation, and lowering the enterprise bill can be three different results, even when the proposal calls all of them savings. We follow a change through to the obligation, and to the person who will have to defend the bill.
The second is about capacity. None of those results tells us whether the systems can handle the work that is actually coming, or whether the promise still holds after something fails.
The third is about the people who have to decide, and the words they are using. Finance, the business, engineering, and operations each hold part of the answer. Forecast, budget, and commitment do not mean the same thing in every one of those conversations, and knowing a constraint is different from having the authority to accept it.
We will use a constructed portfolio for the arithmetic. That sequence gives us a starting practice without requiring the whole enterprise to adopt one way of doing everything.
One more thing before the chapters begin. Whoever runs your capacity and cost work does not need to know every detail of every line on the bill, but they do need to know the overall feel of it: what has changed, what is changing, which changes were expected, and what showed up unexpectedly. Engineering teams are good at their own pieces and often poor at stepping back for the twenty-thousand-foot view of consumption as a whole — that is nobody’s day job, and it takes someone with an awareness of all the perspectives to fuse those pieces into a plan that says, “here is an idea: we can do this, and we can do that.” And once in a while — rarely, but it happens — the person holding that view sees something the engineering team is missing, because they are the one looking across the whole bill while everyone else is looking down at their own line.