Previous Section   Next Section

6.2  The Capacity Management process

6.2.1 Business Capacity Management
6.2.2 Service Capacity Management
6.2.3 Resource Capacity Management


Figure 6.3 shows the inputs to, the sub-processes within and the outputs from the Capacity Management process.

Figure 6.3 - The Capacity Management process

 

The inputs

There are a number of sources of information that are relevant to the Capacity Management process. Some of these are as follows:

The sub-processes

Capacity Management consists of a number of sub-processes, within which there are various activities. The sub-processes of Capacity Management are:

The activities that are carried out by the sub-processes are described in Section 6.3. Each of the sub-processes carry out many of the same activities, but each sub-process has a very different focus. Business Capacity Management is focused on the current and future business requirements, while Service Capacity Management is focused on the delivery of the existing services that support the business and Resource Capacity Management is focused on the technology that underpins all the service provision.

The outputs

The outputs of Capacity Management are used within other parts of the process, by other Service Management processes and by other parts of the organisation, as follows:

Capacity Management - reactive or proactive?

Some activities in the Capacity Management process are reactive, while others are proactive. The proactive activities of Capacity Management should:

However there will be occasions when the Capacity Management process needs to react to specific performance Problems. For example the Service Desk may refer Incidents of poor performance to Capacity Management for resolution.

KEY MESSAGE

The more successful the proactive activities of Capacity Management, the less need there will be for the reactive activities of Capacity Management.

The remainder of this Section describes the sub-processes of Capacity Management in more detail, and Section 6.3 explains the activities that constitute these sub-processes.

6.2.1  Business Capacity Management

A prime objective of the Business Capacity Management sub-process is to ensure that the future business requirements for IT Services are considered and understood, and that sufficient Capacity to support the services is planned and implemented in an appropriate timescale.

The Capacity Management process must be responsive to changing requirements for processing Capacity. New services will be required to underpin the changing business. Existing services will require modification to provide extra functionality. Old services will become obsolete, freeing up spare Capacity.

As a result, the ability to satisfy the Customers' SLRs will be affected. It is the responsibility of Capacity Management to predict these Changes and cater for them.

These new requirements may come to the attention of Capacity Management from many different sources and for many different reasons. They may be generated by the business or may originate from the Capacity Management process itself. Such examples could be a recommendation to upgrade to take advantage of new technology, or the implementation of a tuning activity to resolve a performance Problem.

Capacity Management needs to become included in as many of the planning processes as possible - particularly Change Management and Project Management.

KEY MESSAGE

Capacity Management should not be a last minute 'tick in the box' just prior to Operations Acceptance and Customer Acceptance.

Figure 6.4 shows how new requirements for Capacity cause the Business Capacity Management sub-process to work closely with many of the other Service Delivery and Service Support processes, for example SLM and Change Management, together with other processes such as procurement.

Figure 6.4 - How new requirements for Capacity drive the Business

Capacity Management sub-process

Much of the work that needs to be done by the Business Capacity Management sub-process is carried out in conjunction with other processes. In Figure 6.4 the three highlighted elements are largely the responsibility of Capacity Management, and of these only 'Identify new requirements' is the focus of Business Capacity Management. 'Ensure operational service complies with SLA' and 'Resolve Capacity related Incidents and Problems' are the responsibilities of the Service Capacity Management and/or Resource Capacity Management sub-processes.

The involvement of the Business Capacity Management sub-process with the other processes is explained below.

Identify and agree Service Level Requirements

Capacity Management should assist SLM in understanding the Customers' Capacity requirements, for example in terms of required response times, expected throughput and pattern of usage, terminal population. Capacity Management should help in the negotiation process by providing possible solutions to a number of scenarios. For example, if the terminal population is less than 20 then response times can be guaranteed to be less than two seconds. If more than 20 Users connect then extra network bandwidth is needed to guarantee the required response time. Modelling or Application Sizing may be employed here, see Paragraphs 6.3.7 and 6.3.8.

Design, procure or amend configuration

Capacity Management should be involved in the design of new services and make recommendations for the procurement of hardware and software, where performance and/or Capacity are factors. In some instances Capacity Management instigates the implementation of the new requirement through Change Management, where it is also involved as a member of the CAB. In the interest of balancing cost and Capacity, the Capacity Management process obtains the costs of proposed solutions.

Update CMDB and CDB

The details of the new or amended CIs should be recorded in the CMDB under Change Management. The Change Management process must identify the anticipated throughput, which is then translated into requirements for specific resources. In addition, the Change Management process identifies the performance requirements of the planned Change, for example response times. This information should be held as CI attributes within the CMDB.

The CDB should be updated to include the technical specification of the procured or amended CIs, e.g. disk space, speed of processor, the service performance requirements and expected workloads and demands that are to be placed on the IT resources. From this information thresholds can be identified and monitored. Any threshold breaches and near misses should be addressed by some of the iterative activities of the Capacity Management sub-processes. See Paragraph 6.3.5 for a full description of the CDB.

The CMDB and CDB may be the same database, but even if not a single database, there is a data set that is common between the two databases. For example the CMDB CIs and the attributes that are relevant to the Capacity Management process are held in both the CMDB and CDB.

Verify SLA

The SLA should include details of the anticipated service throughputs and the performance requirements. Capacity Management provides SLM with targets that have the ability to be monitored and upon which the service design has been based. Confidence that the service design will meet the SLRs and provide the ability for future growth can be gained by using modelling.

Sign SLA

The results of the modelling activities provide the verification of service performance capabilities. There may be a need for SLM to renegotiate the SLA based upon these findings. Capacity Management provides support to SLM should renegotiations be necessary, by recommending potential solutions and associated cost information.

Once assured that the requirements are achievable, it is the responsibility of SLM to agree the service levels and sign the SLA.

6.2.2  Service Capacity Management

A prime objective of the Service Capacity Management sub-process is to identify and understand the IT Services, their use of resource, working patterns, peaks and troughs, and to ensure that the services can and do meet their SLA targets, i.e. to ensure that the IT Services perform as required. In this sub-process, the focus is on managing service performance, as determined by the targets contained in the SLAs or SLRs.

When the business requirements for a service have come through the Business Capacity Management sub-process as described above in Paragraph 6.2.1, and the service has become operational, then the Service Capacity Management sub-process is responsible for ensuing that it meets the agreed service targets. The monitored service provides data that can identify trends from which normal service levels can be established. By regular monitoring and comparison with these levels, exception conditions can be defined, identified and reported upon. Therefore Capacity Management informs SLM of any service breaches or near misses.

There will be occasions when Incidents and Problems are referred to Capacity Management from other Service Management processes, or it is identified that a service could fail to meet its SLA targets. On some of these occasions the cause of the potential failure may not be resolved by Resource Capacity Management. For example, when the failure is analysed it may be found that there is no lack of resource, or no individual component is over-utilised. However the design or programming of the application is inefficient, and so the service performance needs to be managed, as well as individual hardware or software resources.

The key to successful Service Capacity Management is to pre-empt difficulties, wherever possible. So this is another sub-process that has to be proactive and anticipatory rather than reactive. However there are times when it has to react to specific performance Problems. From a knowledge and understanding of the performance requirements of each of the services being run, the effects of Changes in the use of services can be estimated, and actions taken to ensure that the required service performance can be achieved.

The activities that need to be carried out as part of this sub-process are described in Section 6.3.

6.2.3  Resource Capacity Management

A prime objective of Resource Capacity Management is to identify and understand the Capacity and utilisation of each of the component parts in the IT Infrastructure. This ensures the optimum use of the current hardware and software resources in order to achieve and maintain the agreed service levels. All hardware components and many software components in the IT Infrastructure have a finite Capacity, which, when exceeded, has the potential to cause performance Problems.

This sub-process is concerned with resources such as processors, memory, disks, network bandwidth, network connections etc. So information on resource utilisation needs to be collected on an iterative basis. Monitors should be installed on the individual hardware and software components, and then configured to collect the necessary data.

As in Service Capacity Management the key to successful Resource Capacity Management is to pre-empt difficulties, wherever possible. Therefore this sub-process has to be proactive and anticipatory rather than reactive. However there are times when it has to react to specific Problems that are caused by a lack of resource, or the inefficient use of resource.

From a knowledge and understanding of the use of resource by each of the services being run, the effects of Changes in the use of services can be estimated. Then hardware or software upgrades can be budgeted and planned. Alternatively, services can be balanced across the existing resource to make most effective use of the resource currently available.

New technology

Resource Capacity Management also involves understanding new technology and how it can be used to support the business. It may be appropriate to introduce new technology to improve the provision and support of the IT Services on which the organisation is dependent. This information can be gathered by studying professional literature (magazine and press articles) and by attending:

Each of these fora provides sources of information relating to potential technology, hardware and software, which might be advantageous for IT to implement for the benefit of the business. However at all times Capacity Management should recognise that the introduction and use of this new technology must be cost-justified and it should be required by the business.

Resilience

The Resource Capacity Management sub-process is also responsible for identifying the resilience inherent in the IT Infrastructure or any subset of it. In conjunction with the Availability Management process, Capacity Management should use techniques such as highlighting how susceptible the current configuration is to the failure of individual components and make recommendations on any cost-effective solutions. See Chapter 8 for a full description of Component Failure Impact Analysis.

Capacity Management should be able to identify the impact on the available resources of particular failures, and the potential for running the most important services on the remaining resources.

Figure 6.5 - Sample configuration and basic CFIA grid

 

Figure 6.5 shows a sample configuration and a basic CFIA grid that identifies the components that are critical in the provision of the services. In the above example the central computer is critical to the provision of both Service 1 and Service 2. For resilience reasons it may be decided to have a number of processors in the central computer, so that if one processor fails the computer can continue to operate with the remaining processors. This may satisfy the resilience requirement, but is there sufficient Capacity in the remaining processors to provide the two services to the levels documented in the SLAs? In the final solution the requirements of both Availability Management and Capacity Management must be addressed.

Ideally the requirements for resilience in the IT Infrastructure should be considered at the time of the application design, see Paragraph 6.3.8. However for many services, the resilience of the service is only considered after it is in live operational use.

Previous Section   Next Section