By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
How this is managed is something for the parties to the contract to settle. However in practical situations, many of the continuity issues can be handled in a service level agreement (SLA).
An SLA is, and should be, a key part of any outsourcing agreement. A cloud computing agreement is no more than an outsourcing agreement that uses a network - usually the internet - as part of the delivery mechanism. So in this setting an SLA should be part of any cloud computing agreement.
In a cloud computing agreement, the service provider will make a number of promises in respect of the services it is to provide. Those promises will form part of the specification
of the services that it will provide.
An SLA provides a contractual means of ensuring that the service specifications are actually met.
Contractual promises In practice, many cloud service providers offer services on a 'take it or
leave it' basis. Therefore there is little scope for a purchaser to demand that the service provider provides realistic obligations, let alone service levels. However, that is only true
of ultimate cloud service providers.
Intermediaries, such as smaller web hosting companies for example, often provide contractual promises backed by adequate service levels.
The SLA will predetermine a variety of ways in which the service may fail to be provided properly in the manner that the parties originally envisaged. Where the services are not provided as planned, fixed payments will be made to the customer by the service provider.
These payments are known as service credits. They provide both an inducement to provide the service properly and compensation should this not be the case.
Sometimes, where a service is provided in an exceptional manner, service debits are provided. Service debits are additional monies paid by the customer to the service provider. In one sense, an SLA is nothing more than a predetermined estimate of the loss suffered by the customer in given circumstances.
To be valid the SLA must be a genuine pre-estimate of that loss. This is the position in English law, although continental laws tend not to have a similar rule.
In English law, if the service credit is too high and is therefore not a genuine pre-estimate of the loss suffered by the customer, it would be regarded as a 'penalty' and be unenforceable.
The customer would then need to sue the service provider and prove the loss suffered by the customer due to the service provider's failure to perform the service specification promised.
Conversely, if the service provider falls well below the service levels envisaged, the customer may wish to retain the right to sue for the total loss suffered. In these circumstances, the customer will not want to be bound by the SLA, but instead be free to claim up to the
agreed limitation of liability within the contract.
Service credits are really only appropriate for foreseeable and likely failures in the service. Where there is a gross failure to perform the service or a failure in some unexpected
manner, the customer should be free to revert to other legal remedies and to sue the service
provider for 'general' damages.
Indeed, attempts to circumvent or limit the customer's rights in those circumstances will be subject to the law on limitations of liability, and may then be unsuccessful.
Drafting the SLA
An SLA is an intrinsic part of a contract. It is important to recognise that, ultimately, it will have a legally binding effect and the parties will wish to rely on it should a dispute arise. Consequently, it is important that the SLA is as clear as possible.
One may need to err on the side of length rather than brevity to avoid introducing ambiguities, which may become the source of dispute later.
However, like all aspects of a contract, the fact that the service levels are discussed and talked about - and recorded - means that, in practice, the parties are less likely to have an
argument about the service level at a later date. The parties are more likely to have an argument about what they fail to discuss and record.
Despite the legally binding nature of an SLA, it is not usually appropriate for a lawyer to draft it because, by its nature, an SLA tends to be relatively technical. Most lawyers are not well suited to writing technical documents. There are, however, many businesses and individuals
who specialise in the preparation of SLAs, and it is these firms that are usually best placed to write them.
It may also be that, in certain larger channel organisations, there is sufficient expertise within the organisation itself to prepare an SLA. If an external consultant is required, the customer should still devote substantial time to assisting the consultant in the preparation of the SLA.
Without that assistance, there is a bigger danger that the SLA will not adequately reflect the customer's real requirements.
An SLA should concentrate on those aspects of the service which are most likely to fall down and so most likely to give rise to a dispute.
In addition, the SLA should concentrate on those areas that are critical to the customer and the customer's business. The underlying question to consider is how the customer obtains
value or a "business benefit" from the outsourcing contract and then to construct the SLA around the delivery of that value.
However, if an aspect of the service is of fundamental importance, it may not be appropriate to deal with it by way of a service credit but rather by recognising that a failure in that aspect will cause a fundamental breach of contract. In those circumstances, the customer may wish to
reserve its rights to sue the service provider for damages should the service provider fail to provide the service that has been promised.
Indeed, in certain circumstances, the parties may agree that certain breaches of the agreement will give rise to the right for the customer to terminate that agreement.
By way of example, consider an internet connection from an internet service provider (ISP). This is a straightforward form of cloud service contract which all readers will be familiar with.
One aspect of that service will be the basic obligation of the ISP to provide connectivity. The service provider may offer an obligation to provide connectivity in terms of the availability of the connection and also the number of 'points of presence' - the number of points at which the ISP has connections with the internet backbone.
Most good ISPs will have multiple points of presence. A good ISP will also normally offer a guaranteed level of connectivity, say 98%. This will normally exclude some aspects of the service, for example the time taken by the ISP for regular scheduled maintenance.
An ISP may then offer an SLA based on that contract obligation. Typically, the offer may be
based upon the further downtime experienced by a user over and above 2%. For example, a refund (or service credit) of 0.1% of the monthly service fee may be offered for each further 0.1% of the time per month during which the connectivity is not available.
This illustrates two further typical problems with service levels:
1. How frequently will the service level be measured? Here, the implication is that the commitment is monthly, which is probably an appropriate period, especially since most users pay ISPs on a monthly basis.
2. Who will measure the failure to meet the contractual obligation? In this example, one assumes that the ISP will measure the failure and that it can be easily measured.
This last matter raises issues that should not be overlooked. First, who is to measure the failure so the service credit can be calculated? If it is the service provider, which is usually the case, this presupposes a level of trust that may not in fact be present.
In any case, if the service levels are constructed so that only the service provider can measure them, at some point in time the service provider may abuse its position.
The second issue is how difficult and costly are the service levels to measure? In this instance it may be a straightforward matter to have software that automatically checks
whether the internet connection is present. However, this is not always the case with many real-life service levels.
There are plenty of examples of outsourcing contracts which have failed because no one had taken into account the complexity of the service level calculation. Indeed, along with that complexity comes a cost.
In real life, we also know that the cost will inevitably be passed on to the cloud service customer