Feature

The benefits of a prenuptial agreement

Before you hand over applications to an application service provider you need a watertight contract. Julia Vowler finds out what to look for in a service level agreement

If ever there was a three-letter acronym designed to draw a collective groan from the IT industry, it has to be SLA - service level agreement. But what should users look for in SLAs? Forget the five nines mantra of 99.999% uptime. "Five nines is an elusive and costly target," warns David Jones of global computer software organisation Pink Elephant.

It could also provide a false sense of security. The performance of a Web site is dependent upon many factors, including the Internet carrier, hardware, operating system, storage and application software. Non-stop hardware will not keep a site live if the carrier disappears or the application crashes.

Trying to get a five nines guarantee for levels other than hardware is tough. Some service level agreements amount to little more than promising never to unplug the hardware or take the phone jack out of the wall, warns Dominic Monkhouse of Web service technology provider Interliant.

"Some operating systems are more reliable than others," he says. "And the least reliable level is the application software."

The bad news, then, when it comes to setting up agreements for Web-based systems is that the SLA can only be as strong as its weakest link. Having 100% uptime on the hardware is no comfort when the dial tone disappears or the database locks.

The good news, however, is that 100% uptime may not be necessary. Users, not unnaturally perhaps, want the highest level of service they can get from an ASP. But it may well be more than they need. "Take up references from users who need the same kind of service as you do," advises Jim Simpson of application deployment portal SevenMountains.

Moreover, it may well be more than they want to pay for. "We did a project for providing 'session level failover' for an e-mail service," recalls Monkhouse. "So if an end-user were in the middle of an e-mail and the data centre was compromised, they wouldn't notice a thing. It would have cost the user £14m a year."

Instead, the user opted for enough performance protection to allow a user to log back into the e-mail system after a crash without needing to call the help desk. Being satisfied with that level of service brought the bill down to only £2m, says Monkhouse.

Users might think that they want their Web site to be live 24x7. But, warns Monkhouse, one user that wanted that degree of availability used a couple of night-time hours as a batch window to update the stock-control system - which meant that e-shoppers could not get accurate information off the Web site anyway. That meant they were wasting money when their own in-house service levels were letting them down.

Similarly, the user's own network has to be up to scratch. "If their network performance is poor with frequent backlogs and breakdowns the SLA is likely to fail, but it is pointless blaming the ASP," warns Russell Luke of application performance management company Precise Software.

The key phrase when it comes to SLAs is end-to-end - what is the achievable level of service across the service chain. There is no point in spending money over-specifying one link in the chain if the others are not up to scratch.

And the service supplier has to be specified as well. Not all may be up to the job. "Users would be wise to check behind their chosen ASP," says Mark Crichard of Andersen Legal. "The ASP will be reliant upon other suppliers and licensors whose reliability and financial stability will obviously reflect on the ASP."

Even more important is determining what is the acceptable level of service for the system in question. "We do e-mail for a major corporate which finds a worst-case delivery time of three hours maximum is acceptable," says Monkhouse.

This brings home the message that, fundamentally, service level agreements are not so much about technology as about business. The business risk from non-availability of the Web site has to be assessed by business, not by the IT department. If the risk is not worth the cost, there is no point in covering it. This is why, stresses Graham Parsons of Aveva Consulting, business users must be involved from the start. "They need to be actively involved in defining and agreeing the service deliverables," he says, and understand the cost implications of what they ask for.

This also brings home the issue that it is all too easy to overlook when it comes to SLAs - what remediation for service failure will be applied by the ASP. This, again, is a business, not technical issue. Users have to decide which is preferable - being let off next month's rent by the ASP in compensation for downtime or having the service brought back up swiftly by switching over to disaster recovery mode.

"Users want dependability," says Monkhouse - not compensation.

Compensation is a tricky issue in itself. Getting an application service provider to agree to cover you for consequential loss, such as loss of sales revenue due to non-availability of the site, is not easy. Putting it bluntly, "I would never take on a liability greater than the value of the contract," warns Monkhouse.

And if an ASP does offer to cover for consequential loss, he says, it will have to buy the insurance cover in the first place, which, as a service provider, it is unlikely to get at a discount. That cost will be passed on to the user, as will the administrative cost for having supplied it. Users might just as well take out their own insurance against consequential loss as expect the ASP to provide it.

Nevertheless, some providers will cover for this, and specialise in risk management. For some users, for example, "[We] will reimburse the user for loss of revenue caused by downtime," says Sara Gemmell of communications server provider Nextra.

Even though ASP contracts tend to be shorter term than a full outsourcing contract, in one respect they are absolutely similar - the user cannot skimp on the overhead of managing the contract, says Crichard.

Good contracts do not run themselves - they require a contract management team which keeps the relationship in good working order, both from the supplier and the user.

"The governance team, meeting regularly, will review performance and agree any changes," says Parsons.

Contracts also have an end-point, as well as a run-time, and some terminate early. "Careful consideration should be given to transition arrangements", warns Crichard, "such as data transfers and the removal of historical data".

But, as with any contract, the bottom line on SLAs is, as Simpson explains, "If you have to look at the contract the relationship is probably over."

Key areas a service level agreement should cover
Quality management -
what definitions and procedures will be used, and what is the role of all involved in the delivery and receipt of the service?

Development and maintenance - decide and define methodology, roll-out, timings, priorities, version control and configuration management.

Security/access - define user and supplier responsibilities and what methods will be used to achieve agreed levels.

Service availability and deliverables - unambiguous definition of what will be delivered, when, where and to whom, with what outage for back-up and maintenance.

Performance measurement and service reporting - agree metrics for monitoring performance, such as response times, acceptable packet loss and network availability, and what reports will be produced, when? How will problems be escalated?

Change requests - how will these be initiated, approved and applied - and how fast?

Disaster recovery - what will happen to restore service?

Compensation - what will you get back if the ASP lets you down, service credits or reimbursement of lost revenue?

Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

This was first published in September 2001

 

COMMENTS powered by Disqus  //  Commenting policy