- Scope of a Capacity Plan
- Format of a Capacity Plan
- Maintaining Capacity Plans
- Storing Capacity Plans
- Summary and Next Steps
This chapter is from the book
This chapter is from the book
This chapter is from the book
Format of a Capacity Plan
The format of a single capacity plan is defined in Appendix J of the service design book. The format includes 11 separate sections covering all aspects of the unified capacity plan. In this section I expand on this basic format and provide some real-world experience that will help you to make your capacity plans complete, concise, and easy for your organization to read.
The Essential Elements
Although the service design book offers good advice for what makes a complete capacity plan, there are certain essential elements that should not be missed. Those elements are described here and depicted graphically in Figure 6.1.
)
Figure 6.1 A capacity plan has four essential elements.
Introduction
Of course, every capacity plan document should begin with an introduction. Somewhere in the introduction you should establish which elements the plan covers and what significant changes have taken place since the previous version of the plan. The introduction is also a great place to preview any significant issues that are described in the plan and to make a call for action if any action is necessary. Although the introductions to all of your capacity plans are likely to be similar, there should be enough differences and distinctions that the opening of the plan doesn't read like a template. If you find you are spending more than a page or so on the introduction, you are probably not summarizing well enough.
Total Available Capacity
After the introduction, the capacity plan should define the currently available capacity for the service or component. For IT services, this might include some theoretical information on what the upper limits might be and how they could be calculated. For a component capacity plan the task is much simpler because you can simply state the units of measure and define the real physical size of the capacity pool. For either type of plan, it is important to define the upper limits of capacity so that the rest of the plan, including any recommendations for expanding those upper limits, makes more sense.
In addition to total capacity, you will want to describe any capacity issues that are occurring with the service or component. If you have outstanding performance or capacity concerns, document them as part of the plan. This provides a strong base for the recommendations that you will make later in the plan.
Past Utilization and Future Demand
The majority of the capacity plan focuses on the current and anticipated capacity demand. It is this analysis of the demands facing a particular service or component that takes the most effort and provides the information needed for decisions. This section requires more detail and thus more organization than the other sections of the plan.
Your capacity plan should review trends in utilization. Document the long-term utilization trend, such as monthly averages for the past 18 months or at least for the past year. You should also document the trend in peak utilization if your tools are capable of gathering that. Often the peak utilization is more interesting than the average because you can learn more about what puts stress on your capacity. Understanding and working with peak utilization helps you to mix the right workloads together so that they can share capacity and each have available resources to meet their peak demand.
The capacity plan should also document shorter-term utilization trends. Profile an average day by showing the utilization for every hour during the day. Show an average and a busy hour by showing the utilization for every few minutes during the hour. All these trends provide the data needed to make capacity decisions about the service or component you are documenting.
The trend data show the history and one possible glimpse of the future, but you should also document any projected changes in utilization. As described in Chapter 3, "Understanding Capacity Demand," demand might come from IT projects or from business activities. Either way, whatever is known of the future resource needs should be captured in the capacity plan as more data with which to make decisions.
Observations and Recommendations
You should round off the capacity plan with analysis of the data. Look deeply at the trends and the upcoming demand, and see whether you can determine when new capacity is needed. Conversely, look at opportunities to save money by consolidating existing capacity, satisfying need with virtual servers, or even decommissioning systems that are no longer needed.
Don't simply observe these opportunities. You should also elaborate on them. Describe what should be done in sufficient detail that someone can create a project proposal or scope statement. Project potential cost savings or the capacity of a newly consolidated system. If you propose acquisition of new hardware, you should specify the configuration to be ordered and define how much new capacity will be created. Given the current trends, how long will that new capacity last?
The recommendations here should be reasonable and in line with the standards of your organization. Don't recommend purchase of a mainframe when a simple Unix box will do the job! Base your recommendations on the data presented in the capacity plan, and provide sound reasoning for why they are the right next steps.
As part of the observations and recommendations section of the capacity plan, you will also want to provide some follow-up on recommendations that were part of earlier versions of the plan. Did the recommendations get implemented? If so, did they resolve the concerns or head off any incidents? Review of past success strengthens your current recommendations, and review of past failures makes sure that you work harder on your current recommendations.
The Right Level of Detail
Now that you understand the basic pieces that make up the capacity plan, you might be wondering about the depth of detail that should go into the document. Although a capacity plan is fundamentally a technical document, you will not want to make it so detailed that it is impossible to read. You should strive for clear explanations without added complexity.
For a casual reader of the capacity plan, the introduction and recommendations are the most interesting. Casual readers are typically IT managers or executives, or perhaps even business unit managers who are particularly impacted by IT. These readers will be interested in knowing when capacity concerns will impact IT services and what the costs will be to alleviate those concerns. So the details in the introduction and recommendation sections should be sufficient to enable the casual reader to understand quickly and completely what the issues are and how they can be resolved.
The majority of the readers of your capacity plans will not be casual, however. They will be the technicians and engineers who provide and manage your IT capacity. These readers will want more than issues and recommendations. They will want to understand the details behind the current issues and the concrete steps to implement the recommendations. These readers will peruse the introduction and analysis, and then dive deeply into the current capacity and utilization sections. These readers may want details even beyond what your tools can produce. But remember that the engineers have real jobs to do and reading capacity plans is not their major focus. So, again, the rule is to be concise and provide the details that support the current position and recommended actions. Any details beyond those represent effort that you have wasted in writing the plan and that your technical readers have wasted in reading the plan.
There is one more audience to consider. The person or people who have to acquire new capacity will look at your plans with a completely different view. They aren't particularly interested in current capacity or utilization. They don't even care about the recommendations very much, other than those that drive new purchases. When new acquisitions do need to be made, however, this team will want enough detail to take action. There really isn't much purpose to a plan that says "buy another server." Instead, the plan needs to spell out exactly what model of server needs to be purchased and what features or components need to be acquired with that server. In other words, the procurement team needs to see a complete configuration that is ready to order. You don't want to end up with an approval to purchase new capacity and then waste time by not having the details of what needs to be ordered. Of course, planning in this light will also cause you to really consider the recommendations you make. Knowing that your recommendations need to go in front of someone to make investment decisions should cause you to really be sure the purchases are justified.