No matter what sort of capacity planning tricks you think you have up your sleeve, if it doesn’t involve the procurement process, then you can’t call it planning.
Procurement is the part that happens after you know what kind and how much capacity you need. It’s the part where you, someone in some other group like finance, or the CFO (when he writes a big check) are getting quotes for, paying for, and waiting for delivery of, your stuff.Sometimes these things can take longer than you want. Other times, they can happen faster than you thought they would. Unless you work for the government, the time it takes from cash-in-briefcase to a cabled server on a rack should be treated just like everything else in capacity planning: another variable. Even when you’re architecture is scalable, you still need to do other things to scale (verb) and one of them is buying hardware. Ask iLike about their Facebook application and how much having a good procurement process was.
The lesson here, which we’ve learned, is: talk to the folks who buy things for you. Know them. Be nice to them. Whether it’s the people on your approval chain, the person doing the logistics of quotes and mass orders, or even your local vendor rep, they have knowledge on a daily basis that can blow any perfect plans you might have out the window. Make their plans part of your plan. Otherwise, it’s not a real capacity plan, it’s a wild-ass guess.
p.s. For those folks who are running on something like S3 or EC2, they can say “Ha ha! We don’t have to wait! We get instant deployment!”: They’re certainly right.
But remember, they’re also having to build their stuff to work within the constraints of EC2 and S3. So at some point, they’re putting in effort that might be considered the same as watching procurement times.