Take a top-down approach to SLAs

Armed with a wad of service level agreements (SLAs) from his suppliers, an IT manager may feel that every ingredient in the...

Armed with a wad of service level agreements (SLAs) from his suppliers, an IT manager may feel that every ingredient in the cocktail of IT systems under his command is safe from harm. But, according to Mark Darvill, technology director at IT services company Logical, this attitude is inappropriate and inadequate, writes Julia Vowler.

"Service level management means a lot of things to different people," says Darvill. "To a technical guy it can mean, for example, 'the system is up and 99.95% available'."

But this is to get too close to the issue. Darvill urges IT managers to take a step back and remember just what IT is there for in the first place - to enable a business process to take place.

The service whose level needs to be managed is not primarily that of the system, but that of the process it supports.

"Increasingly we need to be able to measure the service levels against the business process," says Darvill.

This is not mere semantic gloss. There are practical implications. To begin with, it means looking at the issue from a different angle.

"Instead of just asking 'how reliable is my network?' we should be asking 'how reliable are the systems that uphold a particular process?'" says Darvill.

A single business process can require a host of different technical components to support it, just as a single technical component can support a host of different business processes.

This requires you to approach the whole issue of service level management from the top down, rather than the bottom up, starting with the reason for a system rather than the technology behind it.

"IT doesn't own the processes, business does," says Darvill. "So we normally start with the business process manager - they own the processes, so they own any problems."

Of course, processes change with time, and something as dislocating as a merger or acquisition can completely redraw the map of business processes - let alone the technology underpinning them. Being able to prove a process for industry regulators is another challenge to meet.

Having identified all the processes and updated that schema, it is then essential for the business process owner to communicate what is critical about each process and to each process. Tolerance to downtime, for example, can change at the month end or other critical times.

With a comprehensive, up-to-date inventory of business processes, and all the elements of criticality that pertain to them, the match with IT can then be made.

"Once we have identified the service level hot buttons for business, we then go to IT so we can find out, from start to end of a process, which technology components impact it," says Darvill.

Of course, this can result in a complex mapping, but it is one that must be clearly understood. "The service level cannot be stronger than the weakest technology link," says Darvill.

If multiple system dependencies exist, where several processes require the same components, then it is up to the business to resolve any potential conflict in the service level requirements of those components.

It is also up to the business to understand clearly what the service costs.

"If you want to go from, say, 99.98% availability to 99.99%, the cost of making that change might be incredibly high," warns Darvill. "Business has to decide if that cost is worth it - does it derive value from that extra level of service, or is it preferable to buy into the service level below?"

Understanding the relationship between what is happening at the system level and what impact that can have on business processes is key to service level management. It is also complicated, so it may be worthwhile using service level management software, which collects all the performance monitoring and system management data and presents it in the context of business performance.

"It can tell you where the process is failing," says Darvill.

Read more on Business applications