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?