This page is powered by Blogger.


 
  corner   



HOME

ARCHIVES

SEARCH

Contacting Us
Recommendations
Mike Tarrani
Linda Zarate
Kate Hartshorn

Who We Are
TEAM Zarate-Tarrani

Our main weblog
Notes from the Field

Our other pages
Mike's home page
Linda's home page
Kate's home page

Forums
Simpatico [we]blogs
Dan Gilmore
Robert X. Cringely
Jakob Nielsen
Julian Bond
Deborah Branscum
Lisa Rein
CamWorld
Ed Yourdon

 

Monday, March 25, 2002

 

Tarrani-Zarate Model: Service Level Objectives. In my last entry about the Tarrani-Zarate Model I wrapped up the discussion on business requirements. The next layer in the model is service level objectives (see the illustration). Because we've extensively addressed service level management in previous entries I am going to keep this discussion short and focused.

Short. Instead of wading through the previous entries, download and read the whitepaper titled Successful Deployment of IT Service Management in the Distributed Enterprise. It succinctly and comprehensively discusses all of the key elements of service level management, and places service level objectives in their proper context.

Focused. Service level objectives are goals that are defined as the level of service to be delivered to the business. Examples include:

  • When the system will be available (principal period of operations)
  • What percentage of the time it will be guaranteed to be available during the principal period of operations (this gives room for unplanned maintenance).
  • How long will it take to respond to a reported incident.
  • How long it will take to resolve a reported incident.
  • How long it will take for a module to load or new screen to appear (key transaction performance)
As you can see these are measurable objectives.

Characteristics of service level objectives:

  • Each service level objective must be traceable to a business requirement. If it does not meet this test then the business value of meeting it is questionable.
  • They are defined by the business process owners. IT does not define them - a service level objective states a goal that the business defines.
  • Service level objectives are used by IT as the specification for service to be delivered. Any gap between what the business requires and what IT can deliver is negotiated when the service level objectives are used as the basis for the service level agreement between the business and IT for the level of service to be delivered.
  • Requirements and specifications for applications delivery for systems, applications and services are defined in part by service level objectives.
It's clear from the foregoing that any service level management initiative starts with eliciting business requirements. It's also clear that service level management is directly traceable to business requirements, which are driven by business imperatives, and the smallest unit in service level management is the service level objective.

There you have it: short and focused. That's not to say that it's easy - it's anything but. However, if you attempt to develop, implement and manage service level management processes without taking into account the definition of service level objectives, how they relate to business requirements, and their characteristics I'll predict failure.

In case I was too terse, or you want more information about service level objectives, I'll offer the following:

  • Service Level Management Factors, which is a short paper I wrote in 1996. It's embarrassingly out of date and was hurriedly thrown together, but I'll trust you to take those into account as you glean useful information from it.
  • Service Support Assessment, which is an assessment checklist in MS Word format. It has some excellent questions and forces you to examine the big picture. Tailor it to suit your own needs and save it because it's a valuable artifact for service level management practitioners.
  • Commitment to Service: The Role of Service Level Management - an online paper that touches the key issues.

In the next discussion I'll continue up the vertical path of the model by discussing processes and organization.