• What is an SLA?
• Why Do I Need SLAs
• Who Provides the SLA?
• What's in an SLA?
• What Are Key Components of an SLA?
• What about indemnification?
• Is an SLA Transferable?
• How Can I Verify Service Levels?
• What Kind of Metrics Should be Monitored?
• What should I consider when selecting metrics for my SLA?
• What Uptime Provisions are Typical for Network Service Providers?
• When Should We Review our SLAs?

Choose measurements that motivate the right behavior. The first goal of any metric is to motivate the appropriate behavior on behalf of the client and the service provider. Each side of the relationship will attempt to optimize its actions to meet the performance objectives defined by the metrics. First, focus on the behavior that you want to motivate. Then, test your metrics by putting yourself in the place of the other side. How would you optimize your performance? Does that optimization support the originally desired results?

Ensure that metrics reflect factors within the service provider's control. To motivate the right behavior, SLA metrics have to reflect factors within the outsourcer's control. A typical mistake is to penalize the service provider for delays caused by the client's lack of performance. For example, if the client provides change specifications for application code several weeks late, it is unfair and demotivating to hold the service provider to a prespecified delivery date. Making the SLA two-sided by measuring the client's performance on mutually dependent actions is a good way to focus on the intended results.

Choose measurements that are easily collected. Balance the power of a desired metric against its ease of collection. Ideally, the SLA metrics will be captured automatically, in the background, with minimal overhead, but this objective may not be possible for all desired metrics. When in doubt, compromise in favor of easy collection; no one is going to invest the effort to collect metrics manually.

Less is more. Despite the temptation to control as many factors as possible, avoid choosing an excessive number of metrics or metrics that produce a voluminous amount of data that no one will have time to analyze.

Set a proper baseline. Defining the right metrics is only half of the battle. To be useful, the metrics must be set to reasonable, attainable performance levels. Unless strong historical measurement data is available, be prepared to revisit and readjust the settings at a future date through a predefined process specified in the SLA.

Hosted network services offer various levels of uptime guarantees, at escalating prices. The customer should expect to pay less for 99 percent availability (which allows for over 7 hours of unplanned downtime per month) than for 99.9 percent (43.8 minutes per month) or 99.99 percent (4.4 minutes per month). For mission-critical applications, providers will offer near 100 percent availability, but it will be more expensive.

The operative word here is unplanned; service providers will have predetermined windows for network maintenance, although network redundancy should prevent customer outages.

As businesses change, so do its service requirements. An SLA should not be viewed as a static document, and should be reviewed periodically, specifically if:
• The client's business needs have changed (for example, establishing an e-commerce site increases availability requirements).
• The technical environment has changed (for example, more reliable equipment makes a higher availability guarantee possible).
• Workloads have changed.
• Metrics, measurement tools and processes have improved.

The SLA is a critical part of any supplier agreement, and it will pay off in the long-term if the SLA is properly thought-out and codified at the beginning of a relationship. It protects both parties, and, should dispute arise, will specify remedies and avoid misunderstandings. That can save considerable time and money for both customer and supplier.