An SLA--though it takes effort to implement and perhaps more effort to live by--is in the best interest of both IT and business users. By developing a set of mutually agreed-upon service characteristics, business users know which services and response times are provided at what baseline costs. IT can show that it is providing timely services to corporate management and department users in language that's understandable to them. And an SLA provides a framework for getting additional IT resources when adding apps or improving existing services.

IT and business units must develop SLAs in partnership. An SLA should outline what business users can expect in terms of system response, quantities of work processed, system availability and system reliability. An SLA also should spell out the measurement procedures to collect the service-level data and any limit ations to the agreed-upon service provi sions. It's critical to describe the services in terms that business users understand--not CPU utilization, packets per second or WAN throughput--but a business-oriented metric such as message load handled per hour or call-center queue time.

As a document, an SLA should include the points of contact and their responsibilities, the minimum and maximum time to repair problems and escalation procedures. It should outline what happens if the guaranteed service levels are not provided. The SLA should also include the facility to review the service levels as applications or users are added.

You'll need to interview business managers--your customers--so that you can understand their current and future requirements, and then translate these into technical requirements. You must know the components of your system and their performance. Inventory your systems and networks, so that you have a firm grasp of total capacity and how much of it is consumed by your applications. You'll be able to quantify what IT is sp ending to deliver these services, and what additional funds are needed to meet the business units' requirements. As with service levels, discuss costs in terms that business users, not IT, easily understand. Then baseline your system and network performance over a sufficiently long time period to get an accurate view.

You need the tools in place so that you can measure and report the end-to-end application service levels. Report service levels on a normal and exception basis for capacity planning as well as part of the service agreement. Because of its multivendor, heterogeneous nature, measuring performance in a distributed client/server environment is inherently difficult. Management functionality is often a bolt-on after the application or underlying component is developed. Different vendors' management software for myriad equipment doesn't necessarily integrate and correlate events easily.

The performance management tools will need to deliver an end-to-end view o f the application or business proc ess. Fortunately, more of these tools are becoming available. Vendors have caught onto the idea of measuring performance, and it seems that another vendor announces a new SLA-related product or feature to its product every week.

Maybe you can't make that miffed business manager any happier when the application is slow, but at least with an SLA in place you have managed his expectations of what service is provided.

Patricia Schnaidt can be reached at pschnaidt@nwc.com.