Introduction

A capacity plan can look good on paper and still be complicated by unexpected changes in demand or supply. The forecast holds, the review approves, and then a customer accelerates a migration, a supplier moves a date, or a launch lands in the same window as a hardware refresh. What is clear about this area is that nothing is ever straightforward, especially when you are operating at scale. The larger the operation becomes, the more places a surprise can come from and the more people it takes to keep the plan honest.

That is the subject of this volume. Volume I, Understanding Cost, Capacity, and Capability, worked through the foundations: what the work consumes, what supply can deliver, what we pay for it, and how to decide whether a change is worthwhile. This volume takes the work up a notch. It asks how to keep making those decisions as the work changes, as customers share resources, as agreements expire, and as the organization acquires more ways to surprise itself.

The calculation still matters, but it is rarely the whole answer. The next useful move is often a conversation with the person who can change a date, authorize an extension, or accept a smaller launch. Another forecast will not give us that authority.

Many readers will come to this volume without the first one on the shelf, so I want to be plain about how the two connect. You do not need Volume I in your hand to read this book. I will assume you understand the basics it defined, and when a chapter depends on its detail, the chapter names Volume I explicitly and points you to it. If you already understand the area, you can start here. I would encourage you to buy Volume I, of course, and to keep it available as a reference. But this volume stands on its own.

The boundary between the two books is useful, even though the work will not respect it. A forecast depends on the workload measurement; a reserve depends on the service promise; a commercial commitment depends on what the customer will actually consume. I want those connections visible. The chapters keep their numbers across the series: Volume I contains Chapters 1 through 13, and this book contains Chapters 14 through 24. References back to the first book name it explicitly.

The information that changes the plan

A utilization history tells us what happened under the conditions that existed. It cannot tell us that a customer is preparing a migration, that a product launch is waiting for approval, or that the team behind a large workload has decided to change its architecture. We need to learn those things from people who understand the work, then keep their information with its date and its conditions. In this book I call that demand intelligence.

It is tempting to treat the conversation as the missing input that finally makes the model reliable. Sometimes it does improve the forecast. Sometimes the launch moves, the customer changes its mind, or we misunderstand what the estimate includes. We should keep the unadjusted forecast too, so we can examine both outcomes. There is no point in building a practice that learns from our successes while quietly rewriting our failures.

The same care applies to the people supplying the information. A tentative customer plan is useful without being a guarantee. If we turn it into a promise the person never made, we make the next conversation harder. Keeping the distinction between a forecast, a target, a budget, a reservation, and a commitment is part of maintaining access to the information, as well as part of getting the arithmetic right.

This is why relationships belong inside the planning method. The capacity team needs to understand what its partners know, what they can decide, and what would cause them to revise the plan. That does not require a monthly meeting with every small application owner. It requires deliberate attention to the customers whose changes can move the portfolio, and a workable way to watch the rest. Chapters 15 and 16 examine that division of effort.

The example we will use

The chapters follow one constructed teaching portfolio. Its organizations, prices, resource quantities, and outcomes are invented. My personal accounts elsewhere in the book are recollections; the two should not be confused. The example includes data platforms, an AI support assistant, a customer-facing web service, a shared platform for many small applications, batch work, and a migration with old and new systems running together.

Volume I, Chapter 1 examines that portfolio’s bill through several views, and Volume I, Chapter 4 works through its launch arithmetic in detail. I will not repeat those numbers here. When a chapter in this volume needs the detail, it refers back to the first book rather than re-deriving it. If you want the full recap, the first volume is the place to look.

Keep the decision open to new evidence

The distinction among cost, capacity, and capability runs through both volumes. Cost describes the economic requirement, including obligations that can remain after the work changes. Capacity describes what the available supply can deliver under specified conditions. Capability describes what the business and its systems must be able to do. A less expensive configuration is useful only if we understand what it changes in the service people rely on.

We also keep the historical forecast apart from the business’s choices. Staged and full launches are alternative actions, not probabilities assigned by the capacity team. A reserve can support either choice only while it is ready and available for the relevant failure condition. A discount can improve the rate without securing the supply. When a plan stops fitting, we need to know which of those conditions changed and who can accept the consequence.

The runnable companion

The runnable companion makes selected calculations inspectable. It keeps forecast versions, dated event information, supply readiness, temporary transfers, and decision responsibilities. It uses synthetic inputs and runs without cloud credentials. It does not observe a production service or authorize a change. The guide at the back explains how to run it and where its boundary lies.

I want to be equally clear about what a book like this can carry. When you are running a capacity operation across several cloud providers at scale, it is impossible to capture all of the information, code, process, and analysis required to manage it between the covers of a book. This one is not going to hand you a repository with every script you will ever need to execute. What I have tried to assemble instead is a set of examples, structures, and ideas you can use to inspire or model the challenges you face when you are managing a complex problem. Treat the companion and the worked chapters as material to learn from rather than a guide to copy and execute. One of the things you realize fairly quickly at scale is that you are probably going to write a lot of your own analysis, and you are likely to write your own tools too. There are not many vendors selling software that helps you manage capacity beyond a certain level of scale.

Running the practice

Part III, Demand and Uncertainty, begins with the forecast: seasonal patterns, the mistakes we can measure, and the business information that changes our view of the future. It then widens to the large customers, the long tail, and changes that affect both at once. A portfolio needs more than a sum of individually plausible plans.

Part IV, Running the Practice, follows the people and agreements that make action possible. Relationships and specialist investigations lead into reserves, risks and anomalies, commitments between organizations, and the constraints of operating in several markets. The monthly review asks whether our assumptions survived and whether anyone needs to act before the next meeting. The final chapters examine how the obligations change at scale and what emerging markets for compute might add to the choices.

Those parts are an order of explanation, not a maturity ladder. An organization can need a simple forecast in one resource pool and a difficult commercial negotiation in another on the same afternoon. I would begin with one consequential decision, identify the conditions it depends on, and find the people who can change them. Then keep the old record when the next version arrives. That is how we find out whether the practice is helping while there is still time to do something about the answer.