Service Quality

The most immediate concern for our IT department is to keep the systems running. This takes precedence over developing new functionality. There are two processes that I want to talk about: measuring how well we’re keeping the systems running, and improving how well we’re doing it. They are clearly related, and must be considered in that order -- since we won’t be able to tell that we are improving unless we can measure how well we’re doing.

Today, we call this activity Service Quality. The first time I had to measure service quality, we used a Mac Plus -- which I guess dates me. The objective was then (and still is) to measure the availability of the system as perceived by the users. Back then, the approach was to build a model of the system which included the topology -- the interrelationships between the various subsystems. We wanted to reflect the fact that if one of them failed, we could calculate the set of other subsystems which would then be inaccessible to the user -- even if they were technically still “up