Readdressing the need to measure the quality of your end user’s experience

Opinion
Sep 18, 20065 mins

* Time to readdress quality of experience issues

Recently, one of my favorite topics for these columns has been ITIL’s Configuration Management Database (CMDB) but several years ago a topic that was nearly as active in these columns was quality of experience. There was a good reason for that focus then, and given new developments in the marketplace, I think there’s good reason for readdressing QoE now.

If a CMDB system is the ultimate enabler for IT service management providing unified and consistent access to a wide variety of data sources to support a mixture of disciplines, then QoE is the ultimate baseline for measuring the quality of services delivered. It’s perhaps the most prominent of the three key axes for measuring IT success – quality, cost and demand. If I have taken a somewhat radical position on the CMDB, I feel it’s time to reassert some radicalism in the area of QoE.

My CMDB radicalism suggests (largely observed from effective implementations) that the CMDB is a system and not a “thing”; it is inherently multi-brand and not even necessarily a database. The CMDB typically involves a series of technologies, including discovery, workflow, identity management and access control, of which database-related technologies are only one potentially key component.

My radicalism of QoE is, admittedly, more of an assertion. I believe that QoE is about “experience” and takes the technical metrics that most IT professionals are comfortable with and stands those on their heads. QoE posits that the customer or consumer of an IT service is the ultimate arbiter of quality and that the customer/consumer’s judgments will be multi-faceted, subjective and subject to change and even whim. QoE is the discipline of framing in technical and process terms that seemingly cannot be framed at all.

There’s no question that, during the last few years, industry progress has been made along these lines. While early service level management strategies focused on arcane or reasonable but still incomplete technical metrics – e.g. availability service-level agreement objectives for a critical application server – there has been a dramatic shift towards application response time. This has been true based on EMA research both among the vendor community, where the shift towards measuring application response has been most dramatic, and less consistently among IT organizations – many of which are still looking at component availability as an end objective.

There has also been a lot of attention to how application response time should be measured. Should it be done through synthetic transactions or pervasive observational metrics, or through some form of transactional replay, or all of the above? And should it be done at the data center, or at the end-user device, or both?

While this is progress, and while application response as experienced by the end user is a good beginning point, QoE is much more multidimensional than application response. In my basic QoE presentation, I talk about availability, responsiveness, consistency of responsiveness, security, flexibility and user choice, cost effectiveness and accountability.

More recently, some products are offering more complete transactional replay including issues such as error messages and site navigation. In some cases, the term “end user management” is applied to this more complete assessment of end user experience. Typically, these products are focused on Web-based transactions and in different ways are beginning to provide something of an actual narrative of the end user experience.

Two key points should be made to connect the dots back to the initial premise surrounding QoE. The first reasserts that “experience” is open-ended and may involve unusual but ultimately logical priorities. For instance, for some applications, consistency of format and mobility may be more important than fast response time. Or security might in some instances be the single most important metric. But how can IT know for sure? The answer is to ask. Customer dialog will always be required to wrestle QoE to the ground. This is a premise of ITIL’s IT Services Management – talk to your customers!

The second point is for those in IT who might say, “Well, all this is well and good if I were a service provider or making a living selling books off the Web but what relevance does it have to most IT organizations dealing primarily with internal clients like HR? Do I really need all this fancy information about site navigability or blow-by-blow transactional analysis, or worry about how the manufacturing floor might prefer wireless over tethered?” The answer is fundamentally, “yes.”

All IT organizations are service providers. And whether you get your information primarily through customer dialog, through well-chosen monitoring technologies, or a combination of both (hint – the latter is usually the most efficient), you’re in the business of helping human beings extend their very human, very complex, multi-dimensional and experience-based capabilities. Once you recognize this and implement it, you will probably be surprised to realize how much more efficient you can become because you know what’s actually relevant to your customers and, by implications, what’s not relevant.