Availability Classes

When organizations conduct an analysis of which systems are truly business critical, the findings are often surprising: There are few truly critical systems, maybe 10–20 percent of all systems. However, analysis sometimes delivers wrong conclusions too. Email as a bulk service is often categorized somewhere in the middle of the scale in terms of criticality. However, when it one day goes down couple of hours, a panic is on because nothing works.

Setting service level targets is a very delicate task. Too high or too low a service level should not be allowed, but on the other hand, if the targets are set for each service separately, the result is usually an unwieldy mess.

A common solution is to categorize services into a few (3–4) criticality categories and set availability targets for each category. This is usually a sufficient trade-off between business needs and simplicity. Rating should not be static, but it should be able to be adjusted in connection with changes or seasonal variations.

There is also often a misconception that high criticality also automatically implies the need for extended service hours. This is not always true. For example, an order processing system may be very critical during the working hours of the order processing agents, but at other times its availability hardly matters. Or the other way around: an online store that serves consumers on the Internet may generate a relatively small part of the day's revenue during the small hours, but its repeated downtime quickly creates a negative effect to its reputation.

When designing the classification scheme, it shall be remembered that systems are usually part of a value chain, and the chain is only as strong as its weakest link. Therefore, if there is a critical system in the chain, all links in the chain must be critical. If the services are layered on top of each other, the entire service stack needs to be planned with the criticality in mind. For instance, if a database system is shared by several applications, its criticality must be the same as the most critical application.

In the chart, the red color represents the highest criticality. The paradox is that if less critical systems B–E lose their platform, the incident must be treated as critical.

If there a more services than only a few, everyone working for Service Management must be aware of the criticality of each service. The Configuration Management Data Base may be a natural place to store that information on the condition that there is a working practice for Configuration, and its scope includes all relevant functions.

The availability classification basics should also be communicated to the end-users in the name of Expectation Management.