You've heard the application service provider (ASP) hype, and you're finally getting around to considering using one of those outsourcing services. But you're well aware of the risks; you'll be entrusting your most important processing tasks and a wealth of corporate data to a third party.
You can minimise your company's risks--or at least know clearly what you're getting into--by insisting on a service level agreement (SLA). Don't dismiss an SLA as just another acronym, because it can carry a lot of weight. And it just might keep your company--and you--out of hot water. The SLA outlines the rights and obligations of both the customer and the service provider in measurable terms, and it states the consequences if the ASP fails to deliver on its guarantees.
Before you contract an ASP, you need to know what to expect from an SLA. Ideally, a customer would like an SLA to cover every risk, but realistically the ASP can guarantee only the services over which it has direct control. A good SLA will outline:
- specific metrics, as well as related industry ranges and calculation criteria, on key measures such as availability and performance
- a clear statement of purpose
- a description of the services and their duration
- installation timetables
- payment terms
- termination conditions and legal issues (that is, warranties, indemnities, and limitation of liability)
Usually, an SLA will last from one to three years. During that time, the scope of the service will probably expand, with new applications and new users, so it's important to anticipate growth and the impact that might have on service.
Your agreement might also state that the contract will hold even if the customer subscribes to additional applications or adds a certain number of users. And the SLA might require that the ASP and customer meet to discuss any configuration or network changes and then modify the agreement as necessary.
This renegotiation is in everyone's best interest, since the real goal of the SLA is to articulate the service level with an eye toward creating infrastructure that meets the customer's needs and agreeing upon a level of service that is both acceptable to the customer and achievable by the ASP.
Many ASPs are working to create standard agreements while still giving their customers the flexibility they want. Many are creating multi-tiered plans that allow users to pick the plan that suits their needs and their budgets.
Qwest Cyber.Solutions, for example, introduced its ProofPositive SLA in October, which guarantees application, performance, and disaster recovery. The company offers three levels of service: 99 percent, 99.7 percent, or 99.99 percent application reliability. Each level--Standard, Enhanced Response, and Business Critical--guarantees different degrees of customer service response time, CPU utilisation, and storage utilisation.
SLA terms vary according to the type of agreement you have. According to the ASP Industry Consortium, there are at least four distinct types of SLAs.
1. Network SLAs cover the network connection between the customer and the ASP. The network service provider agrees upon a suitable service level for the delivery of IP services. Possible metrics include availability, network latency, or low packet loss.
2. Hosting SLAs cover the hosting services provided to the ASP. An ASP uses this type of agreement when hardware is hosted or co-located with a third party. Metrics vary, depending upon the type of service performance, service-order acknowledgment, and mean time to respond. As an ASP customer, you should also see this document to ensure that the ASP will be able to deliver as promised.
3. Application SLAs measure application performance. The ASP agrees to a certain level of responsibility, different classes of service, performance parameters, and a manner of calculating both the demanded performance levels and penalties that result if the ASP doesn't perform its services as planned.
4. Customer care/help desk SLAs refer to the point of contact for the customer with the ASP. These SLAs may specify how quickly a problem will be reported to the customers after it has been identified and how quickly an identified problem will be resolved.Of course, when a major problem occurs, the loss of data or business opportunity can't be compensated by any amount of money. However, a good SLA does outline exactly what sort of penalty should be paid in the event of an outage. This sanction should have enough teeth to make the ASP live up to its responsibility.
Penalties are often broken into minor and major categories, with a description of each being clearly articulated in the agreement. Often, a certain number of minor infractions will account for a major infraction. The agreement should also outline how many major infractions would be cause to allow you to withdraw from the contract without penalty.
Usually, penalties are designed to be a percentage of the monthly contract; the specific percentage is generally based upon the severity of the problem. Users should look for a proactive penalty approach in which the ASP uses sophisticated monitoring tools to spot any problems and voluntarily pays for any time that a metric is missed. A reactive policy, on the other hand, requires that the customer spot the problem and offer proof that remuneration is needed.As in any good business relationship, trust may be the most important factor. However, all risks can't be removed, so there is still an element of caveat emptor, and customers should be wary of any deal that seems too good to be true.
Be wary of an ASP that enters negotiations with unhesitating agreement to every request. Sometimes a vendor will offer 100 percent uptime guarantees, for example, but chances are that the ASP will ask the customer to take on the monitoring task or has hiked its higher rates in anticipation of the likelihood that it will be paying penalties.
Look for an ASP that offers monitoring software to track the metrics that have been set. The monitoring should track and log the metrics that you've identified as critical to your particular business.
Beware of too much flexibility. Although some vendors will negotiate on terms, both parties are best served when the terms are clearly and narrowly defined. Flexibility, a key requirement in many situations, may mean that you are not fully covered in certain instances. More often than not, an ASP will have already carefully crafted its SLA and will be reluctant to make sweeping changes. However, some providers offer tiered service levels to allow customers to choose a service that best meets their needs. As the complexity of the service provider offerings increases, though, customised offerings are promising to become more of a norm.
Make sure your SLA includes terms that clearly outline what happens in specific instances. For example, a "change management" clause stipulates that a customer can't change the system in ways that might undermine performance without notifying the ASP. Another clause might specify what level of failure of service allows the customer to get out of its contract without penalty.
Know when you can expect payback for an SLA violation. Does your vendor address its delivery failure at the moment of violation or after a set amount of time? Ask about the maximum service credit. Many ASPs will insure that they will pay up to seven to fourteen days of outages or up to a set amount (such as US$2,000 or US$5,000). Make sure that the ASP isn't putting the burden of risk on the customer.
Today, no standard exists for SLAs. However, the ASP Industry Consortium has stated its commitment to creating precisely these sorts of guidelines. The consortium is the global advocacy group promoting the ASP industry by sponsoring research and articulating the strategic and measurable benefits of this delivery model. The group has more than 700 members in 30 countries (including Australia) on five continents, including independent software vendors (ISVs), network service providers, and ASPs. As a starting point, the group has developed a "Buyer's Guide to Service Level Agreements for Application Service Provisioning."
Before you contract an ASP, make sure your prospective service provider spells out the ins and outs of its services, because in the end, your customers will blame you--not your ASP--for failed service.