Service level agreements: difficult to know what to put in them

Feature

Service level agreements: difficult to know what to put in them

Service level agreements are a vital part of any hosting arrangement, but it's difficult to know what to put in them. Danny Bradbury provides some pointers

Entering into a relationship with a hosting provider involves so much more than just checking out its technical capabilities and assessing the competency of its management. Business marriages are not like conventional ones - every union requires a corporate prenuptial agreement, or service level agreement. But there are a number of things you must do to make sure that an SLA is worth more than the paper it's written on.

It is important to make sure that your contract contains escalation procedures, so if any of the terms and conditions are not met, there is an agreed course of action, possibly resulting in financial compensation. And it is wise to see if there is any accreditation from the hosting provider's vendor. Hosting companies have to buy their equipment from somewhere, and a vendor will often want to ensure that only quality partners use its product.

Follow these rules, and you will help protect yourself in the event of inadequate service or all-out failure on the part of your hosting provider.

Penalties
Cable and Wireless has suggested that the traditional 'carrot and stick' approach, where penalties are imposed in the event of a service failure, is not applicable in a hosted or ASP-centric environment. In fact, it's more important than ever as there are few things more threatening to a service provider than the possibility of revenue disruption. Make sure that your SLA contains firm financial penalties that are incurred when the hosting provider exceeds its allotted downtime, or fails to provide the quality and quantity of support outlined in the contract.

System availability
System availability covers the hosting provider's hardware, the network underlying its infrastructure, and the application itself [if it is provided by the hosting company or a third party under the SLA]. At the end of the day, you should be looking for a single figure guaranteeing a certain percentage of uptime. For an e-commerce-based organisation, anything below 99.9% is not really worth considering, and this still amounts to a total of 8.76 hours per year downtime, so you may want to make the percentage higher. Your SLA should include information about the level of fault tolerance inherent in the hosting provider's hardware and network infrastructure. Any good hosting company will have two points of access to two separate networks, so that if one goes down, it can continue to operate. If the application isn't yours, then an SLA should ideally include guarantees that it has been adequately tested against different data sets, so that the likelihood of a crash is minimal. However, getting a third party application vendor and the hosting provider to work together to produce an SLA covering application robustness on the hosting provider's infrastructure could be difficult.

Security guarantees
Any good security SLA will address the type of network over which the data is passing. If you are running a business-to-business e-commerce application, over which large transactions are passed, then a virtual private network between the various parties may be appropriate. Consider issues such as the physical security of the hosting provider's data centre, which should be built into the contract, and the level of encryption that is to be employed. Virus detection and intrusion detection are key elements outlined in a Cable & Wireless white paper on SLAs, and denial of service is a hot topic that should be covered.

Customer support
Support should be solution-focused, meaning that the SLA can determine how quickly a problem is fixed. Consequently, you'll need to consider problem escalation as part of the agreement - if the hosting provider is unable to solve a problem, how quickly can it go to the relevant party (such as a network provider or hardware vendor) and get a resolution?

This portion of the SLA should also cover response times and media. If you submit a question by email, how long will it take for someone to mail you back? What hours are the phones manned and, if they are busy, when will someone return your call?

Application maintenance and development
This is critical, and will depend on whether your hosting provider provides its own application or not. If it is running its own application for you, it would be handy to include a roadmap for new feature additions into your contract. The level of customisation is also a critical issue. If the hosting company is running your application, or an application provided to you by a third party partner, then you need a clear picture of how easy it will be for you to make additions to the application on the hosting company's server.

Response times
A tricky one, because any hosting companies will not include performance within their SLA, especially if systems are being accessed over the public Internet. Many ASPs are loathe to include this in their contracts, citing a lack of control of some parts of the infrastructure as justification. That being the case, you should at least be able to get performance guarantees for the application inside the firewall.

Penalties for changing ASP
ASPs and hosting companies make their money on a regular payment basis, rather than receiving a bulk sum of cash upfront. Consequently, they will want to sign you up for a specified length of time. Any early termination of the contract will result in a charge. Nevertheless, there should be some provision for early termination due to consistently inadequate levels of service.


Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

This was first published in May 2001

 

COMMENTS powered by Disqus  //  Commenting policy