Chapter26.Capacity Planning

Chapter 26. Capacity Planning

IN THIS CHAPTER

• System Hardware/Architecture Instance Design

• Planning for Growth

• Monitoring for Growth

• Ongoing System Concerns

• Federation

• Best Practices

Capacity planning is the act or process of planning for current and future application or system needs. Assumed in the concept of capacity planning is that minimal performance requirements (user perceived and/or system) must be protected. The goal of capacity planning is to achieve these performance requirements throughout the designated planning time frame (often the life span) of the application. Capacity planning can be approached in many ways; the following are representative options:

• Option 1 Examining the expected capacity requirements at the end of the target time frame and designing/procuring the architecture and hardware needed to meet those requirements.

• Option 2 Examining capacity requirements at the designated stages in the target timeframe, meeting the initial need through architecture and hardware, and laying out planned upgrades to meet the needs of the subsequent phases.

• Option 3 Understanding system scalability options, meeting the initial need through architecture and hardware, and enacting a performance monitoring program with alternatives for upgrading as specific bottleneck thresholds are reached.

For many companies, Option 1 is the de facto standard because many applications are not equipped to support the full monitoring (and its associated costs) of Option 3. Option 1 is also easier for initial budgeting and planning than either Options 2 or 3. In fact, the existing best practice guidance around Microsoft Enterprise Project Management (EPM) is to look out to the system needs two plus years from initial implementation and then meet those needs via Option 1. This is a reasonable approach from many angles. For example, the two years time frame is a good demarcation because it is reasonable to expect advances and upgrades in hardware performance and/or in application performance in new version releases within this time frame. These advances would make planning beyond a two-year time frame ineffective.

For many smaller companies, an initial investment in hardware or architecture to support needs that may not be realized over the next two plus years is simply not cost-effective. For these companies, Options 2 or 3 are much more rewarding.

TIP

Planning capacity requirements around deployment phases (and scoping hardware to match need) while monitoring the system performance for proactive action is usually the most cost-effective approach to an EPM solution deployment.

Unfortunately, in the world of enterprise systems, capacity planning is even more complex than you might initially consider because other factors play a significant role in performance over time. The performance of many (even most) large distributed applications is affected by the environment they are deployed in and changes to that environment. Many of these changes go unpredicted even in proactive IT environments. Knowledge of organization data and bandwidth patterns and of individual application architecture and usage all come together in capacity planning.

UNPLANNED NETWORK IMPACTS: THE CASE OF POINTCAST

In May 1996, PointCast Network was launched as the first personally tailorable, ad-supported news source delivered to your screensaver. It was a huge hit. Using a continuous polling and pulling application, news and advertisements were delivered directly to individual desktops. By September 1996, PointCast had 1.4 million users and was adding 250,000 new users a month. PointCast was a web phenomenon and a growing IT nightmare. Corporate gateways were hit in a double whammy. The popularity of the software itself meant that it was being downloaded repeatedly (once by each internal user interested in it, and many were interested in it). After the software was installed, each user controlled how frequently his information was updated (and most chose minutes). The corporate connection to the Internet jammed with traffic, and critical systems such as email were impacted. Network managers were initially taken unaware by the bandwidth demand, and corporate networks suffered, but eventually steps were taken to limit or block internal use of the software.

The PointCast scenario is an example of how one application impacted millions. Despite careful planning, unrelated applications can have a major impact on performance.

In addition, an implemented EPM solution has a special sensitivity to its own data and data complexity. The EPM solution is a mix of data repository, query, and analysis made more performance sensitive by the business knowledge layer being distributed on client machines. That means that the data complexity is not dealt with in a single server location but on each client station. The performance of each client station is a complex mix of the resources available on the local machine, network bandwidth, traffic volumes, and the complexity of the data served to it (which then requires more or less local machine resources to display and manipulate).

NOTE

In the world of EPM, data complexity can impact performance as much or more than user numbers and server/network bottlenecks. Data complexity can change over time due to user maturity and system goal changes. For example, the original vision may have been simply of supporting internal project management, but it is broadened over time by adding external vendor management and more refined resource forecasting.

In reality, at least some of Option 3 is a necessity for successful planning and implementation.

Instead of promoting any individual capacity planning option (1 through 3 mentioned previously), this chapter takes a different approach. This chapter provides some guidance on the components of capacity planning used in all three of the options, allowing you to mix and match to build a capacity plan that may be any combination of the three and is more appropriate to your organization.

NOTE

A large volume of material is already developed by Microsoft in support of capacity and installation planning. This chapter does not reiterate that information here but rather provides pointers to it as it is relevant in the following discussion.