Capacity Planning Equals Budget Planning

To quote from my Gartner colleague Lydia Leong’s recent post on cloud computing: “Capacity planning equals budget planning, so it’s rarely an, “eh, because we can scale quickly, it doesn’t matter.”

I read this three times before it sunk in.  Capacity = budget?  Yes!

We’ve often in our Gartner EA practice discussed that EA should focus on service levels beyond just RAS (reliability, availability, scalability) into other “-ilities” like securability or interoperability, and even affordability (cost as an attribute of the system or solution, stated so that like other attributes higher is better).  This is not however common practice.  Mostly we plan the best (ie most RAS) solution, and then just tell the customer what the cost is.

But, perhaps the balancing of cost and RAS (or just performance or capacity) will become more common over time as cloud computing services change how we compute value for alternative architectures.  Within the most elastic of cloud services, the elasticity of provisioned service is directly exposed to the customer, both for performance and price. Both go up and down — this is what elastic scalability means.  Scalability alone connotes ONLY scaling up, never down again.

Furthermore, as capacity goes up (or volume of usage, anyway), the overall cost ALSO GOES UP.  This is why contracts, as Lydia so clearly points out, will move from simplistic usage only to all sorts of capped and other forms — look at your mobile phone bill for a model, for example.

Thus, as capacity is planned, the budget is also planned.  More to the point, as capacity is actually used, costs go up.  Not paying for not using capacity means paying for using it.  (I had to read my own sentence twice to make sure — yes, it’s true!)  The problem will move from overpaying for unused capacity to overpaying for used capacity (at a higher rate — like that mobile phone bill).  Which means we’ll be right back to paying for average capacity (and generally not actually using all of it) to get more predictability in budget.

It also means that EA teams should stop saying that they’ll design a solution (or even more general guidelines for solutions to repeat) for high scalability becuase that’s best.  It means we need to design to fit a budget, and that we’ll need bronze rather than platinum configurations.  Perhaps we can design a system that can do both service levels simultaneously, but I’m skeptical on this.  It seems possible in theory — and cloud computing is a new way to try for this kind of perfectly scalable solution — but hard to deliver in practice.  Even on the cloud, we’ll have some service providers that can scale higher but will cost more, while others opt for lower cost without the same global scale.  And, we customers will have to CHOOSE between them.  In fact, we’ll probably offer a variety of such choices to our customers, mixed in with ones we provide (versus sourcing from cloud or other outsourcing vendors).

More importantly, however, this can be used to manage demand, not just to design the supply.  Customers using elastic services will decide how much to use based on budget.  They will in some cases say we’ll just say no to scaling up capacity, because we can’t afford it!  The assumption that more is better (upsizing) will yield to the idea of right-sizing — just enough and of course just in time.