From the various disciplines of Capacity Management, Capacity Planning has always been the most unloved. All companies manage Service Levels in different ways, and consequently the performance of their systems and applications; most of them have Cost Accounting and Chargeback procedures, but only some of them have a specific Capacity Planning activity running regularly.

The major reasons for this situation are the following:

• Capacity Planning is the only Capacity Management discipline that doesn’t attain only to the past and present, but also to the future of systems and applications;
• even when based on metrics and methodologies, the forecast of something that will happen in the future is often affected by significant errors ;
• the accuracy of the result is highly dependent on the skill and experience of those that make the plan; these skills are difficult to find and very expensive;
• specific tools for Capacity Planning are generally very expensive too, and not really user friendly;
• Capacity Planning projects require long periods of time before some result can be produced.

Even with all these difficulties, Capacity Planning activities are always in someway performed, also in those organizations where there isn’t a specific group responsible for the discipline, by:

• system programmers, based on their judgment on critical issues to come and avoid (more often already existing);
• managers, with respect to their budget;
• vendors, sometimes more keen to their own goals and objectives.

The systems programmers approach could be the most valid from the technical point of view, but not really effective because it’s a based on a reactive approach and on the analysis of sporadically collected data.

The Capacity Planning methodology we suggest is aimed to discover the amount of capacity (CPU) needed to support the planned workloads; indications on other critical resources such as memory, I/O and disk space can be obtained by tracking the evolution of a set of indexes that correlates the utilization of these resources among them.

This methodology is based on three major assumptions:

• the most important resources of a system (CPU, memory, I/O, disk space....) must be balanced to allow a system to work at its best;
• the correlation between these resources will vary in time, depending on the architectural and software evolutions;
• in a specific point in time the ratios between the resources are meaningful also for new comparable applications.

We don’t model the response time of the applications, because we think that if the resources were planned correctly the response time should be affected mostly by the applications and systems tuning efforts and will not be a Capacity Planning issue.