Working with an application service provider (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 says 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 notes.
Patterson says 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 notes. The nonprofit group needed an SLA tailored to its business' needs, which Patterson defines as 99.99 percent availability of its enterprisewide applications. "We are aiming for perfection," he says, but the organization's mission - to find cures for cancer - compels it to strive for nothing less.
ACS's top priority, says 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, explains 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 percent uptime. Although the math appears fuzzy and the second decimal place unimportant, 99.99 percent reliability means only five minutes of downtime per month, while 99.95 percent 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," explains 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 adds.
A second point of contention with SLAs is what David Caruso, a vice president at AMR Research Inc. in Boston, refers to as "teeth." ASPs have to feel some pain for falling down on the job, says 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 notes. "For example, one SLA guaranteed 99.9 percent uptime but didn't count the first 15 minutes of downtime."
Caruso says 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 online 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 says 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 makes 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.
Shand is a freelance writer in Somerville, Mass. Contact her at firstname.lastname@example.org.