Defining objectives for Monitoring and Control

Many organizations start by asking the question ‘What are we managing?’. This will invariably lead to a strong Internal Monitoring System, with very little linkage to the real outcome or service that is required by the business.

The more appropriate question is ‘What is the end result of the activities and equipment that my team manages?’. Therefore the best place to start, when defining what to monitor, is to determine the required outcome.

The definition of Monitoring and Control objectives should ideally start with the definition of the Service Level Requirements documents (see Service Design publication). These will specify how the customers and users will measure the performance of the service, and are used as input into the Service Design processes. During Service Design, various processes will determine how the service will be delivered and managed. For example, Capacity Management will determine the most appropriate and cost-effective way to deliver the levels of performance required. Availability Management will determine how the infrastructure can be configured to provide the fewest points of failure.

If there is any doubt about the validity or completeness of objectives, the COBIT framework provides a comprehensive, high-level set of objectives as a checklist. More information on COBIT is provided in Appendix A of this publication.

The Service Design Process will help to identify the following sets of inputs for defining Operational Monitoring and Control norms and mechanisms:

• They will work with customers and users to determine how the output of the service will be measured. This will include measurement mechanisms, frequency and sampling. This part of Service Design will focus specifically on the Functional Requirements.
• They will identify key CIs, how they should be configured and what level of performance and availability is required in order to meet the agreed Service Levels.
• They will work with the developers and vendors of the CIs that make up each service to identify any constraints or limitations in those components.
• All support and delivery teams and departments will need to identify what information will help them to execute their role effectively. Part of the Service Design and development will be to instrument each service so that it can be monitored to provide this information, or so that it can generate meaningful events.

All of this means that a very important part of defining what Service Operation monitors and how it exercises control is to identify the stakeholders of each service.

Stakeholders can be defined as anyone with an interest in the successful delivery and receipt of IT services. Each stakeholder will have a different perspective of what it will take to deliver or receive an IT service. Service Operation will need to understand each of these perspectives in order to determine exactly what needs to be monitored and what to do with the output.

Service Operation will therefore rely on SLM to define exactly who these stakeholders are and how they contribute to or use the service. This is discussed more fully in the Service Design and Continual Service Improvement publications.

Date: 2014-12-29; view: 1073