The SLA rule book

By Jeb Bolding
Network World ASP Newsletter, 07/23/01

Recently, the Information Technology Association of America released a set of guidelines that highlights the critical pieces of an SLA that enterprises and government agencies should consider when looking to buy services from an ASP.

All in all, the document, entitled, " ITAA ASP Federal Government SLA Guidelines, " is a good guide. It outlines the 12 key sections of an SLA that users should keep in mind, such as security, upgrades, help desks, and disaster recovery. The document is available as a PDF download at www.itaa.org/asp/itaaslafed.pdf

The first part looks at systems availability and the services that are monitored, including those that are excluded from the availability contract. The second is about security and focuses on the basics - How does the customer gain access (if at all) to the service provider's systems? How are new users are added? And how networks and network information are accessed, including monitoring applications or third-party vulnerability assessments.

It's also important, as the document mentions, to define how the ASP monitors and manages its systems, as well as how that data is presented to the customer. Again, the SLA assessment notes that specific clauses should consider regular, " objective " third-party reviews of the ASP and that those reports should be available to customers.

The fourth section is really no more than a corollary of the previous sections. It talks about defining the metrics for application, network and systems performance and notes that systems scalability is important for customers to understand. I agree here. Most ASP users have no clear idea what impact the adoption rate of other customers will have on their application performance. Are customers sharing databases? Are they sharing applications? Are they sharing servers? What bandwidth is available? All these issues need to be understood up front, but often don't get asked.

Once you have down the metrics and the means of SLA measurement, the ITAA document considers the remedies for violations of the SLA. In its parlance, remedies are not really remedies, they're compensation for violations. The recommendations for types of reimbursement are standard fee reduction rates, contract termination, and " monthly percentage fee rebates correlated to degree of under-performance. "

Section six, upgrades, is another area that isn't clearly spelled out for many enterprises. One of the general strengths of ASPs is that upgrades can happen " on-the-fly " at the ASP site. In many cases they occur with the user not even being aware that something has changed. The suggestion here is that ASP customers ought to be aware of the upgrade process policy in the event that there is a blackout during the upgrade or an upgrade failure (and therefore, a reversal).

Redundancy, backups, and disaster recovery are described in the seventh section. Here, the ITAA offers several key points to consider. First, describe the infrastructure of the backup, disaster recovery and redundancy systems. Second, describe the process for each one, and third, describe the outcome for each one. This last is actually my concern. In the example of disaster recovery, it's important to know the outcome of the process because in an emergency situation, you may only have 40% operability for a temporary amount of time until the main systems are up and running and you need to be able to plan application access around that.

In area of help desks the ITAA points to a number of key services and metrics. Most important are descriptions of the services including descriptions of the tiered offerings such as platinum, gold, and silver (or Elvis, Beatles and Hendrix, if I were to name them). There are also other important issues such as notification, escalation, and metrics, including response, resolution and recovery time.

Points nine and ten, termination and ownership, are both sides of the same coin in my opinion. Issues here include the time period for the return of the customer data, cooperation to ensure data transition, and a description of the process for unilateral termination from both the customer and ASP's perspective.

But tied directly into this is the concern of data ownership. This needs to be spelled out at the beginning of the relationship. In the case of Managed Service Providers, most of them argue that they own the monitoring data they've gathered from their customers. It's important for a company to realize this up front and negotiate about what they think is valuable to them.

The last two - intellectual property indemnification and indemnification by the customer - are reminiscent of shrink-wrap software licenses where customers protect themselves from penalties if the service provider has infringed on the intellectual property of another party. On the other side, if the customer improperly uses the services provided, it should be spelled out how the customer will compensate the ASP. In most cases, termination of the contract is the solution here.

The section under " general " looks at miscellaneous issues. Some worth considering are the impacts of an acquisition, both on the part of the customer and the service provider. The possibility of multitiered SLAs, which involve service arrangements between separate service provider entities and one customer, is present. The document touches on this only briefly, but it is worth considering as companies engage multiple vendors whose services may impact one another.

All in all, the ITAA has produced a good top-level document that should be quite helpful to anyone considering at ASP service.