Customers traditionally have established service level agreements (SLAs) as contracts with service providers. Recently, the requirement for these contracts has begun to penetrate to the IT organization. IT is being asked to sign a contract with business units guaranteeing that applications will perform at an acceptable level. This trend has many IT organizations concerned. However, we offer a different perspective on the situation. Because of the emerging service level monitoring tools, IT has the chance to transform this concept into a wonderful marketing opportunity to help promote the value of the IT organization to business units. In this article, we will discuss the evolution in the area of SLAs, what tools are available, and how organizations can start to use these SLAs to their advantage.
In the past several years, various third-party service providers have used SLAs to score competitive advantages. Typically, a telecom service provider or third-party desktop-support provider touts its SLA as a compelling benefit. With an SLA, the vendors boast, customers know what to expect in terms of service and know what corrective measures will be taken when the vendor fails to deliver the promised service level.
Essentially, the SLA is a contract that defines a level of service to be provided in specific, quantifiable terms and specifies the remedies and actions when the service falls short. SLAs focus on three critical areas:
For instance, an SLA might, in part, specify 99.5-percent application availability or four-hour response time for level-one (high-priority) problems. SLAs have become a key marketing tool among the large third-party service and support providers.
Customers gravitate toward SLAs because they make clear what in the past has been very subjective -- service performance. SLAs address a key customer frustration: service appears to have deteriorated over time but the customer can't quite validate the assumption. The SLA, by contrast, provides specific, measurable points that can form the basis of an analysis of past and present performance. And it specifies remedies when the vendor -- or the IT organization -- falls short in key measurements.
For the IT organization, the ramifications of not meeting an agreed-upon service level can be very serious. The message from business executives to IT may simply be that if you don't meet an agreed-upon service level, you will be outsourced. No wonder there is a sense of dread from IT about SLAs. Ironically, in most cases IT is doing a good job. Systems are typically working pretty well. Occasionally, there is a major problem that tends to get the attention of upper management. Some problems can't be avoided such as a power spike, a service provider going offline, and so on. People tend not to notice when things are working well; they take it for granted -- they only remember the occasions when they have been interrupted.
This reminds me of the old joke about the young boy who never spoke a single word. Suddenly, at the age of seven he said, "This meat is overcooked." His parents were shocked. "Why are you suddenly talking now?" they asked in shock and amazement. "Until now," he replied, "everything was fine."
Implementing tools that provide monitoring of service levels is one of the best ways to avoid this type of problem where business management only notices you when there is a service failure. Several software companies are beginning to offer solutions in this area, including Hewlett-Packard, Empirical Software, Compuware Corp., Candle Corp., Network General, Envive Corp., and Luminate Software Corp. Each of these companies takes a different approach to monitoring and managing SLAs. There are three different approaches that companies are taking in this market: Compuware offers an intelligent agent approach; Empirical Software, Network General, Luminate, and Envive offer network traffic inspection; and Hewlett-Packard leverages its Application Response Measurement (ARM) API for monitoring. The following is a description of each company's approach.
Hewlett-Packard offers a product called MeasureWare. It provides the ability to monitor performance at the database, network, and systems levels. HP is working closely with Tivoli to get the ARM-API embedded into development tools and packaged applications. Companies can use this approach to monitor end-to-end application performance. MeasureWare does not allow proactive management at this stage.
Empirical Software, formerly called Database Solutions, offers a Web-based service level management product called Empirical Director. This product allows IT both to monitor performance levels of the database and network level and subsequently to tune performance to meet the service level requirement. It also allows organizations to predict the impact of a software or system change on performance before it is implemented.
Network General's Sniffer Network Analyzer inspects network traffic to the application client and reports on which clients are noncompliant to the service level. By inspecting network traffic, Sniffer Network Analyzer can determine the specific application transaction response times and can pinpoint which application is causing problems.
Luminate's Luminate for SAP R/3 and Envive's Inspector both capture application transaction response times from network activity and can isolate the performance impact to the business users. For example, with either product it is possible to identify that accounts receivable is in compliance with the SLA and that accounts payable is not in compliance. Additionally, these products ship with prepackaged service level objectives for SAP.
Compuware offers both an intelligent agent approach (EcoScope) and network traffic inspection capability (EcoTools). This combination allows IT to assess the business impact of bottlenecks in application performance. Subsequently, it is possible to identify which application component is responsible for generating the specific loss of performance.
Candle employs an intelligent agent to instrument and monitor each component of the application and aggregates performance to determine end-to-end response time. In this way, Candle's Command Center can also identify which component is responsible for application failures and downtime.
By implementing these types of tools, IT can begin to give objective information to the business areas about the overall success of their service levels. It also provides a platform for negotiating with the business units. For example, the business area manager may insist on 100-percent up-time and full redundancy for a particular business application. Through the use of tools, IT management can demonstrate what type of hardware and software will be required to meet that objective. This requirement, in turn, can be translated into concrete costs including more personnel. Typically, we have found that the business unit may back down once these requirements are translated into dollars. At the same time, room for compromise exists. Perhaps there are certain times of day when high performance levels can be guaranteed. This would be based on a consultative approach with business management.
But IT can take this approach even further. Let's suppose that IT and the business unit agree on particular service level goals for a three-month period. At specified intervals, IT can go back to the business unit and proactively ask how the SLA can be changed to meet changing business demands. The approach therefore changes from one of fear and dread to one of proactively marketing service. This could potentially change the entire relationship between IT and the business.
As much as we'd like to empathize with IS managers who are disturbed by the growing interest in SLAs among their user communities, we don't believe SLAs represent a grave threat to conscientious IS organizations committed to delivering first- rate IS services to their users. On the contrary, the SLA process, if approached correctly, provides an opportunity for the IS organization to establish clearly its value to the organization in terms that are meaningful to the business users and hold at bay those who attempt to outsource IS.
IS organizations can use the SLA, just as third-party vendors do, as a tool to market themselves. Of course, if you are not committed to providing top-notch IS services, the SLA will spell the end of the ride -- deservedly so. As organizations have come to rely more and more on their distributed systems to support critical business processes as represented by the growth of such applications as SAP R/3, the need for management of the distributed environment, including management of service levels, has become crucial. SLAs offer an effective tool for managing service levels. Because we are witnessing a wave of such applications moving into production, expect a wave of SLAs to follow.
Similarly, the cost of the distributed systems environment is drawing increasing fire from top management, as evidenced by the heated debate over total cost of ownership. Corporate executives are demanding justification for the investment in the distributed systems infrastructure. SLAs provide a mechanism to capture and analyze information pertinent to the building of return on investment scenarios.
Finally, the emergence of the Web has impacted corporate networks, noticeably reducing response time for many applications. Like the child who suddenly had something to complain about, users suddenly notice the networks they rely on are not performing as well as they did just a short time ago, before those networks became loaded with Web traffic.
Rather than resist the call for SLAs, proactive IS managers need to recognize the valid contribution an SLA can make, embrace the SLA, and use it constructively. We see two major constructive uses of the SLA.
First, the SLA can be a powerful marketing tool for the IS organization by giving IS managers the ammunition to make a convincing case for the internal IS group. By defining key metrics in the area of availability, performance, and recoverability and capturing the appropriate data, you will be able to demonstrate that the internal IS organization does deliver quality service according to the key metrics. This information also can be used to justify additional investment. For example, if the organization makes an acquisition that adds a significant chunk of traffic to the network and application performance over the network begins to degrade, as shown by the SLA metrics, the IS manager can build a good case for increased investment in network capacity.
Second, the SLA provides the IS organization with a scorecard it can use to improve service quality. Low scores in key areas clearly indicate where IS needs to direct its efforts. In this case, the SLA becomes an effective tool for establishing priorities in any program to improve service quality. Over time, the SLA will show where progress has been made. Armed with a service-improvement plan based on clear, quantifiable metrics, IS managers will likely find corporate management more patient and more supportive of the IS efforts, especially as IS begins to demonstrate progress.
Developing a workable SLA needn't be daunting, although it does require careful thought. We recommend the following five steps as a start:
Implementing the SLA is mainly a matter collecting the necessary data, storing the data for comparative and historical trend analysis, and reporting the results. Vendors are introducing tools to assist with this effort, such as Empirical Software's performance monitoring tool, TPM 97.
IS managers need to take the initiative when it comes to SLAs to ensure the result is implementable and meaningful, in that it will help the organization understand what it is getting for its IS investment and will give IS the information it needs to improve service. Resist SLAs, on the other hand, at grave risk. In the end, you, as IS manager, have little choice but to go along. The organization will simply outsource the IS operation to any of the many third-party vendors more than happy to join with your business users in an SLA.
Steven Foote is vice president of research strategy and director of systems and applications management service with Hurwitz Group. He directs the research approach used by Hurwitz Group analysts and consultants and manages research in system, database, application, and network management. You can email Steven at sfoote@hurwitz.com.