Anyone that has been a participant in the ASP business model, whether provider or customer, is familiar with the concept of a service level agreement (SLA), which guarantees minimum levels of service for particular components of the service provider relationship. It's understood that with that guarantee, there must also be a mechanism by which the component is measured, as well as some recourse to the customer and penalty to the provider if those warrants aren't met.

While everyone may understand the basic premise behind an SLA, and know that they need an SLA, not everyone knows how to go about writing or negotiating one. To help address this fundamental aspect of the software service provider relationship, the Software Services Group of CompTIA, the Computing Technology Industry Association, has unveiled its Global SLA Navigator, a comprehensive tool designed to improve and streamline the process of drafting and negotiating SLAs for software service providers and their customers.

"We recognized that there's a wealth of information out there that talks about SLAs in general terms, that has educated the public for a number of years on the necessity of SLAs, and has provided information on the types of things that should be the subject of SLAs. But in our experience, it stopped there," Jeff Gorball, SVP Operations, Kingland Systems, told ASPnews.

Gorball led a task force made up of CompTIA members, with wide-ranging experience in writing and implementing SLAs, to develop a tool that would meet the needs of providers and customers, and satisfy the multiple requirements within those parties. A concerted attempt was made to ensure that the tool was not slanted one way or another, he said.

"What we wanted to do was take this to the next step and really provide a comprehensive tool that was not created in a vacuum by a legal entity, a technical entity or a sales entity, but really draws on the experiences of the members of our group that have experience in each of those areas and bring them together," he said. "We wanted to provide what we felt was a legitimate SLA that each of us would be comfortable using within our respective organizations."

Quite often, what happens is that SLAs are drafted in some sort of vacuum by one entity or the other, which can result in an SLA that has clauses that are incomplete, which essentially render it useless, Gorball said. Others may not provide definitions on some of the language and terms that are used, or may not provide a defined mechanism by which the metrics are to be measured.

"I've seen SLAs that when you really got into the SLA, it became obvious from a technical perspective that the crafter of the SLA really didn't have a strong handle on what it is they were warranting. Either the measures they were warranting couldn't be measured, or didn't have anything to do with the particular environment the SLA was governing, or the measures were simply ridiculous. There were vague descriptions of how breaches were to be satisfied or even lack of discussion within the SLA on what procedures were to be followed in the event of a breach," he said.

The task force attempted to describe all of the several components that need to go into an SLA. Then it identified many items that would generally be the subject of an SLA -- such as availability, bandwidth and throughput -- that would have a broad application across the widest user base. Each of those items is covered by detailed information that includes a definition of the term, description of the intended use and information on industry norms and practices.

The task force went so far as to create sample language for the SLA -- language which can be used for discussing SLA credits in the event of breaches and a discussion of the industry norms or ranges that would be appropriate for that type of an SLA. It brings all of those things together into a single point.

What resulted is a tool that balances the needs of everyone involved to provide clear examples of the various components of a typical SLA, drawing on standardized terms and industry-accepted languages and practices. All a customer or provider needs to do is extract information out of the tool, have their legal counsel review it, tweak it for their particular business with regard to the specific metrics being measured, and go forth from there, Gorball said.

The 60-plus-page document provides discussion on industry ranges and caveats associated with each component, and also identifies those things that would normally be negotiated. For those trying to craft an SLA, it can save them many hours of time putting their SLAs together, as well as avoiding headaches down the road when a breach or perceived breach arises.

"It should save companies a great deal of time, energy, effort and cost when they begin the process of developing an SLA. I've had numbers of people tell me that it's the most comprehensive resource they've seen on SLAs on the market today," Roger Bartel, director, Service Programs, CompTIA, told ASPnews. "This isn't intended to replace a full legal review by parties on both sides, but it takes you a long way down the road to getting a document that the lawyers will have an easier time agreeing on."

One of the other things that has been included that is not necessarily self-evident is a survey of worldwide regulations that address privacy of data and security. It's not meant to be a final resource on the topic, but rather a starting point, Gorball said.

"One of the things we recognized was that as this business model continues to grow, and the utilization of the ASP model expands worldwide, it's more important for those ASPs to understand what kinds of privacy and security regulations they're going to have to adhere to through serving a customer base outside their own region," he said.

Another important aspect of the tool is the introduction of a concept similar to the auto industry's Lemon Laws, that address situations of chronic failure. Automobile Lemon Laws say that if a buyer has a particular problem with a vehicle and has taken it to the manufacturer for repair a reasonable number of times without a resolution, the buyer can petition the manufacturer to purchase that vehicle back or provide a replacement vehicle.

In an ASP agreement, it's conceivable to have a relationship between a provider and a customer that has well defined SLAs in place, and for whatever reason there's a chronic failure on the part of the provider to meet those SLAs, but that due credit is provided in every instance. From a legal perspective, everything is still in compliance with the contract, but in reality the impact to the customer is potentially disastrous, Gorball said.

"If you've got a situation of chronic failure by the provider to meet an SLA, yet credits are being issued appropriately, there comes a point in time at which the relationship really needs to end, or at least be taken to the next level of consequence," he said. "We've provided some guidance on sample triggers that can be used to address those instances."

In the first couple of weeks it was available, nearly half of CompTIA's more than 150 active members of its Software Services Group accessed the document in the first three weeks. Some companies have even joined CompTIA just to have access to this tool, Gorball said.

In the past several years, SLAs have evolved in two distinct ways, Gorball said. One is that the nature of the items subject to SLAs is growing quite large, which is not necessarily to everyone's benefit.

"There are SLAs we're seeing more regularly now that are trying to describe things in way too much detail. You'll find SLAs that try to address error resolution, data loss, delay, internal and external response time, all within the same contract. They're trying to address each of those several things, when in reality what may in fact be most important is throughput. When you start to layer all of these very granular requirements that have to be measured and tracked, it becomes very cumbersome and expensive on the part of the provider and the customer. In some instances, both the provider and the customer can be better served by a higher-level SLA," he said.

The other change that's coming out is the refinement of the SLAs themselves. Ideally, what the industry is working toward is a uniform approach for creating the SLAs, and a uniform approach for presenting the SLAs along with accepted industry norms, something that is standardized from one vendor to another, Gorball said.

"If we have a standardized format by which SLAs are being presented, it's going to make it much easier for people to identify within the measures being warranted differences from one vendor to the other. It really allows vendors and customers to do apples-to-apples comparisons and really differentiate their offerings," he said. "I think this tool helps take us to that next step."