How do you quantify service performance

Datacentre Service availability and performance are key to running businesses efficiently, given today’s massive reliance on computing systems. How do you determine how a system should perform, and how do you measure that performance?

The measurement aspect is relatively simple. All modern operating systems come with basic in-built capabilities for self-diagnosis of hardware issue, and it does not cost much to acquire a suite of tools for collating alerts and measuring everything from server availability up to application-level performance.

The knack is to quantify the measurements – subjective opinion is not enough. One can, however, take account of what users consider acceptable. Why not spend time with them as they work and analyse their experience? It won’t take long to agree a system that defines, say, an average response time of less than three seconds measured over an hour as “green”, between three and ten seconds as “amber”, and above ten seconds as “serious” and needing to be looked into.

The final brick in the wall is to configure everything in such a way that users can easily examine the statistics without disturbing the IT department. In addition to lightening your workload, users will feel comfortable that what they are reading is reality, not some sanitised version of it.

If measuring the service is quite painless, asking how the customers – the departments in your organisation – pay for it opens up a whole can of worms.

In the 1970s and 1980s, it was sensible for an organisation to buy a central computing resource and charge the departments according to the amount of resource (generally CPU time) they consumed. No single department could afford a computing platform of its own, so this was the only choice.

Centralised provision of computing is still a hugely desirable concept. It offers economies of scale when purchasing equipment, and it enables organisations to centralise backup policies, directory services, security measures, internet access, software licensing, system policies, storage, and so on. Centralisation brings control, and while it brings a certain amount of inconvenience caused, say, by a change management process or an IT team that doesn’t have infinite hours in the day, the overall effect on the business is beneficial.

Charge the costs back to the departments at your peril, though. What happens is that instead of spending £120,000 buying services from IT, they spend £45,000 on their own system and the rest on something else. There follows a regime of declarations of semi-independence: a NetGear router from PC World appears in place of the Cisco ASA, or a deal is done for £150-per-month web hosting arrangement with an unclear service level agreement and a strong aura of impending doom.

So the answer to the question of how the internal customer pays for the service is don’t even consider asking them to do so, at least not directly. Never put the financial onus – the budget line – onto the customers, because they will start to get ideas.

By all means budget for the £120k (in the above example) that is the minimum necessary to provide the service reliably – but keep that amount as a line item in the central service budget rather than making it directly available to the internal customer. Thus the department has the satisfaction of knowing that the funds are set aside for it, but you avoid the risks associated with devolving the budget to the department.

If you transparently show the performance of that service, using tangible, reliable data, and if the figures are good, you will be able to justify to all comers the central implementation of the service without breaking sweat. ®