Service Level Agreements

Particularly important in this respect is the SLA. SLAs are formal contracts guaranteeing quantifiable performance under specified conditions that define Quality of Service and attempt to quantify it so it can be measured.

MorganDoyle has developed a rich library of SLAs covering:

	Network services;
	Departmental IT;
	Hosted applications; and
	Messaging.

MorganDoyle's White Papers - Don't Get Bitten by Your ASP and  Writing SLAs - provide further detailed information.

A generic SLA should address the following issues:

	Define the service being provided, in terms of parties to the contract, boundaries, responsibilities and service features. It is often worth including an explicit statement of what is not included if this is not obvious.
	Specify operating conditions, environment and constraints in which the service will operate.
	Specify availability of the service usually in terms of a percentage uptime over a defined time period.
	Specify volume of transactions and/or user level events that can be performed in a given period.
	Quantify timeliness, delay or response times, usually in terms of a percentage of events, e.g. round trip acknowledgements or user transactions, which will be completed within the specified time.
	Define procedures for reporting and rectifying faults, e.g. response times, Mean Time To Restore, escalation, etc.
	Prescribe user or consumer responsibilities, so that the provider can perform his part of the bargain.
	Describe how the service is to be monitored both in terms of report contents and the reporting period.
	Provide unambiguous, technical definitions of all parameters or metrics which form the basis of the SLA.
	Specify a review timetable for monitoring service levels.
	In the longer term, allow for renegotiating the SLA as industry norms and your needs change.
	Provide guarantees in terms of compensation if service levels are compromised.