What’s the Service Level Agreement?

September 17, 2007

Ron Charity recently gave an overview of SharePoint 2007 backup and restore in his blog. There he puts a good list of questions to ask yourself when planning for backup strategy, and the first question in the list is “What’s the Service Level Agreement?” Ron then goes on to talk about what is backed up, and how to ensure restore-ability, etc. But this is really a good question he asks.

What is the SLA? Do many IT organizations there really have an up-to-date SLA for SharePoint services? What does it cover? What should be a good SLA for SharePoint? And what should it not be? Here are my 2 cents:

  • An SLA should be about data availability both during normal operations and in case of hardware or software failures.
  • An SLA should describe all possible restore scenarios: separate metrics should be provided for complete “server farm down” disaster recovery situation, single site restore, lost document restore, emergency access to documents or sites during disaster recovery. If something is not in an SLA – well, the service does not exist.
  • If there is a need for the business to access historical data, this should also be covered by SLA.
  • All services described in an SLA should be described in measurable terms. Service availability has to be described as percent of uptime, and this should be tracked. Scalability means nothing without number of concurrent connections the service can handle, and the average response time. Backup retention policy does not tell much unless it specifies what historic backups are available, and what exactly does “available” mean here (e.g., how long the user has to wait for the data after submitting the request). And so on.
  • An SLA should never discuss what appears “implementation details” to the customer (be that internal or external customer). I mean, as the content owner or project manager I do not care about backup windows or number of front end servers. My concerns are: if I have to roll back because of the disaster – how much work do I lose? and how many users can access the data simultaneously?

Having these items in mind, you can create a document that will provide value to both the users and the IT organization. For the users it will explain what they can expect from SharePoint and be confident their business critical sites are available and protected. For IT these items will help understanding and justifying the needed investment when terms of the SLA require additional hardware for load balancing and redundancy or third-party tools for meeting specific recovery requirements or tracking metrics.

Finally, make sure your SLA is revised on a regular basis with all stakeholders – yes, including the SQL admin! – as both requirements and technology out there are constantly evolving. Who knows, probably something that was too costly just half year ago is already there free of charge on CodePlex?

Technorati Tags:
, , , , ,

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: