Getting the most from a service-level agreement

Working with an ASP can be a risky proposition, especially for established companies that entrust the care and management of core business applications to small or emerging companies. How can you ensure an ASP will perform well, respond quickly to problems or perform regular maintenance checks?

In its march toward becoming a legitimate and permanent fixture in the IT outsourcing landscape, the ASP industry has promulgated service-level agreements (SLA) as a means of mitigating these concerns. An SLA provides some assurance that ASPs will support their customers’ business and technical objectives.

Last spring, the American Cancer Society Inc. (ACS) in Atlanta decided to find an ASP to host its Siebel Systems Inc. customer relationship management system.

CIO Zachary Patterson said he believed that the ASP model would free his organization from IT delivery, since technology isn’t the organization’s core business but is a critical enabler. “We were mainly concerned with hosting at the beginning; now I would rent the application,” he noted.

Patterson said he decided to take a new approach with ACS’s technology vendors: he wanted them to become partners with the nonprofit organization. The SLA ACS reached last fall with Annapolis, Md.-based USinternetworking Inc. to host the Siebel suite would be one step in that process.

The SLA is an “ongoing learning experience” for both ACS and Patterson’s team, he noted. The nonprofit group needed an SLA tailored to its business’s needs, which Patterson defines as 99.99 percent availability of its enterprisewide applications. “We are aiming for perfection,” he said, but the organization’s mission – to find cures for cancer – compels it to strive for nothing less.

ACS’s top priority, said Patterson, is customer satisfaction, and its SLA reflects this business imperative. As Patterson says, “Uptime on a router means nothing to a business.” Patterson worked hard to make certain that USinternetworking understood what ACS’s service meant to its cancer patients, volunteers and donors.

This doesn’t mean that his organization’s SLA doesn’t address finer technical details, explained Patterson. For instance, ACS does measure performance metrics such as availability of e-mail services. However, the SLA’s overriding goal – and its relationship with the ASP – is the business prerogative of service.

The business requirements fleshed out in the ACS’s contract with USinternetworking reflects how SLAs have changed during the past year. When SLAs first came into fashion in 1999, ASPs encouraged their customers to examine each piece of the technical puzzle, from the routers and servers to leased lines and storage systems. Then, the customers would weigh the overall importance of each area and decide how much uptime would be necessary.

Most ASPs promised 99.9 per cent uptime. Although the math appears fuzzy and the second decimal place unimportant, 99.99 per cent reliability means only five minutes of downtime per month, while 99.95 per cent availability allows for 45 minutes of downtime. For certain applications – especially given the vulnerability of the hardware that they run on – it’s completely unrealistic to tell a customer that it will be down for only five minutes per month.

These days, most SLAs focus on business requirements. SLAs were historically “negotiated for one piece, such as an SLA on network performance,” explained Jay Seaton, vice-president of marketing at NaviSite Inc., an ASP in Andover, Mass. “Customers now ask, ‘What about the server? If it goes down, I’m also out of business.’ Ideally, customers should look for comprehensive SLAs.”

The business objective, such as response time or problem resolution, should take precedence over specific technical metrics, he added.

A second point of contention with SLAs is what David Caruso, a vice-president at AMR Research Inc. in Boston, referred to as “teeth.” ASPs have to feel some pain for falling down on the job, said Caruso. Typically, when an ASP doesn’t meet its performance agreement, it pays the customer in either additional service or dollar credits. “I’ve seen some weasel words in these SLAs,” Caruso noted. “For example, one SLA guaranteed 99.9 per cent uptime but didn’t count the first 15 minutes of downtime.”

Caruso said that customers are starting to think more about “windows of performance.” For example, 15 minutes of downtime during peak buying hours represents a huge problem for on-line retailers, but 15 minutes of downtime at 2:00 a.m. probably has fewer consequences.

There’s now a greater effort to think through – and specify in the SLA – when maintenance activities are performed to avoid interfering with the business. Customers and ASPs can differentiate between uptime and performance levels. The SLA should reflect these business requirements.

However, Caruso said he has also seen SLAs that have been too detailed. “Companies should focus on specifying the mission-critical activities,” such as uptime or performance, he says.

Patterson made the following recommendations for companies that are negotiating an SLA: “The SLA should be clear and free from complex language. It should be tightly focused on business needs.”

In other words, avoid the weasel language.

Would you recommend this article?


Thanks for taking the time to let us know what you think of this article!
We'd love to hear your opinion about this or any other story you read in our publication.

Jim Love, Chief Content Officer, IT World Canada

Featured Download

Previous articleBriefs
Next articleMaster of his own domain

Related Tech News

Our experienced team of journalists and bloggers bring you engaging in-depth interviews, videos and content targeted to IT professionals and line-of-business executives.