Service agreement: an expression of functional and/or non-functional aspects of a service delivered from one party to another, along with any obligations upon either party.
In an earlier post I described how at Arjuna we believe that IT service will increasingly be delivered by Federated Clouds. In This post I want to look at the glue which connect Clouds together – Service Agreements.
When a service is both commissioned and delivered within a single organisation, the appropriate IT resources are designated and trialled until an effective service is deemed to have been provided. In this case both the consumers of the service and the suppliers belong to the same organisation, are ultimately responsible to a single authority, and have common interest. Common interest results in a level of trust where formal contractual and detailed expressions of precisely what is required of the service can frequently be avoided. Knowledge of the specific dedicated resources being used and/or faith in the ability of the IT team within the organisation can reassure the IT consumer that the requisite quality of service will continue to be delivered.
However, today if you’re commissioning an application delivering some service you’d ideally like to push it into the cloud and forget about it. You want the cloud to be opaque. You don’t want to have to make resourcing decisions (and particularly you don’t want to incur any expense associated with over-capacity). But if the cloud is opaque then you don’t know what resources will be utilised, and as there isn’t the same level of trust, how can you, or the consumers of your service, be confident that a satisfactory quality of service will be maintained?
Well, if the risks associated with the failure of the service to behave as expected are low enough so as to be ignored or effectively mitigated by the consumer then a general purpose, low-cost, cloud which offers simple ‘best-effort’ quality of service may well be ‘good enough’. Many of the applications hosted on the cloud today do indeed fall into this category.
However, if the risks are perceived to be higher then a service may only be useable if backed by a service agreement which provides some specific contractual guarantees. Those guarantees might constrain the provider to utilise specific resources in support of the service e.g. fault-tolerant hardware, replicated storage, the availability of skilled support staff etc, and thereby reassure the consumer that the risk is lower than it might otherwise be; and/or the provider might agree to compensate the consumer if quality of service is not maintained. This compensation could be through the provision of an effective alternative service or may even be financial. Service providers supporting this form of service agreement are effectively reducing the overall cost of using the service for individual consumers by mitigating their collective risk.
A service agreement could specify not only how the service can be operated and what it is expected to do, but also what might go wrong and what then happens, the legal, financial and support obligations, what reporting is to be delivered etc. In the real world service agreements (just like other legal contracts) can rarely be absolutely complete i.e. aspects remain open to interpretation, but in the cloud they certainly need to be much more explicit than they need be when services are utilised within a single organisation. The trust relationship which exists within an organisation needs to be replaced by a more formal relationship i.e. a contractual service agreement which clearly defines all relevant aspects of the service to be delivered.