Capacity Planning is A Social Problem, Not a Technical Problem
The purpose of capacity planning, in layman’s terms, is to ensure that the right resources are in the right place at the right time. Some practitioners will add the additional criteria that it must be done in a cost effective manner, although this latter point may be debated by academic purists in the field. With respect to contemporary large IT organizations, capacity planning is typically a discussion around either when to purchase and deploy some amount of CPU, RAM, DASD, and network resources or the improved use of existing such resources. Large organizations focus (or should focus) their planning efforts on where money is being spent.
A variety of styles and interpretations regarding how to do capacity planning have emerged. The ITIL v3 provides a framework and specifies the essentials and best practices for contemporary capacity planning in an attempt to provide some standardization.
Much of the discussion around capacity planning is centered around technical topics. It is largerly perceived as a somewhat academic area, full of statistics, modeling, simulation, metrics, charts, tables, and the like performed by introverted trolls who rarely see the light of day and often speak using incomprehensible jargon. Well, this stereotype might be a slight exaggeration – capacity planners often see sunlight on their way out of the dungeon on their going to lunch.
Many years ago while with a now former employer, I was fortunate to find myself amongst a collection of exceedingly bright capacity planners – Ph.D.s, folks with Research and Development backgrounds, and others with incredibly rich and substantive industry experience. We were charged with capacity planning for a large computing environment composed of all manner of computing technologies, including mainframes, Unix systems large and small, Windows systems, and a set of exceedingly excentric proprietary solutions that few have seen or used.
All of the standard, logical, approaches to capacity planning were employed at the time, including modeling, simulation, statistical analaysis, etc. The results, however, fell significantly short of expectation with respect to accuracy and usefulness. Capacity planning, while theoretically sound, seemed lacking in actual application. Capacity planners were looked upon with scorn when their predictions were wildly inaccurate, and when on rare occassion they were reasonably correct, largely ignored or even permitted lunch.
The result of being inaccurate was that the trolls of capacity planning were marched back to their dungeon and given orders to produce something more useful. Window shades were affixed in the hallway connecting the dungeon to the lunchroom to screen out the sunlight away and drive home the point.
The solution came in the form that was not anticipated but was obvious after it arrived, as all many good solutions would seem to be. The problem was not the mathematics, the principles, or the technique employed. It was in the plans, assumptions, and data provided by the business units. The old adage “Garbage In, Garbage Out” became incredibly relevant. Business units did not take capacity planning seriously, but merely viewed it as an item on the checklist of activities they had to complete in bringing new features, functions, and products to market. It was a procedural impediment, not a value-adding process.
The solution to this was to convince the business units that they genuinely had “skin in the game,” so to speak. That is, the quality of data that they provided would directly affect the likelihood of success of their endeavors. If they gave faulty information, then the possibility of having too little resource capacity to run their products with reasonable response times could occur, which would be disasterous for new and prominent offerings they may wish to tout. The converse was also damaging – having too much capacity meant that financial resources were sunk into hardware that was not generating return for the corporation. Neither of these is desirable, and the larger the computing environment, generally the larger the impact on the business of one of these undesirable outcomes.
What was sought in interactions with business units regarding capacity planning was an agreement upon what level of business activity would be planned and the associated computing resources that would be needed to facilitate that business activity. If the actual activity aligned with the plan, then all parties involved were happy. If the agreed upon plan failed to reflect the actual load that arrived, the business units did not have the option to point their fingers at the capacity planners as the reason for the failure as they had fully agreed to the plan. No more blamestorming. Besides, the dungeon was out of capacity and there was therefore no room to accommodate the business unit folks who missed the mark.
The most significant determining factor in the success of capacity planning in a large computing environment is therefore more social than technical. The business units, users, and whoever is associated with the volume of work arriving at the doorstep of the computing environment must be convinced to fully participate by 1) providing useful information about what is happening from a business perspective, and 2) coming to agreement regarding planning for that level of activity and accepting responsibility for the outcome.
Instilling this into a culture takes time – the larger the environment, generally the longer it takes. One sign that this has been achieved is that business units are proactively contacting capacity planners with information regarding upcoming changes in demand whenever changes are identied, having fully grasped that the they (the business units) must help the capacity planners help them. Only when this happens do the technical aspects of capacity planning bring real value to an organization, as well as allow a few squinting eyes to see the sunlight at lunch time.