Have you ever been Experienced?
Somebody asked me about "Quality of Experience' (QoE) recently. While those in technical silos may offer a brilliant dissertation on abstract polymorphic interfaces in clients and servers (see Button, Button, Whose Got The Button? Patterns for breaking client/server relationships, by Robert Martin) or even Distributed QoE, my answer is quite a bit simpler.
In my experience users will (usually) let you know if their experience is poor. You don't like the program, you change the channel. You get bad response from a web site, you shop somewhere else. So, of course you want to know what your users are experiencing!
However, different IT tribes will want to measure QoE for different reasons. Many want to be warned of a storm brewing, and be well prepared to explain why thier tribe is not the source of the problem (or fix it before they call). I call this the "it's the other bastards fault" motivator.
QoE is absolutely consistent with best practice. However, when investing in QoE technologies one should be careful of who is defining QoE (i.e., QoE of what services?). It should be the customer (read business process).
Two things worth considering before putting your budget dollars on the line:
1) Defining 'end-to-end' - Citrix access services is NOT a business service. It may be a critical segment of an end-to-end business service, but it is rarely the entire service. So, having 'end-to-end' knowledge of the Citrix servers right to the desktop is great --- but most business service infrastructures have a dizzying array of network devices, web servers, application servers, data base servers and applications. 'End-to-end' means every layer of every component required to support a business process.
2) What are you prepared to do? - So you took the plunge and purchased a QoE tool. Now that you've been warned (pray that your investment will warn you of an impending storm; otherwise your user could have told you --- for free), how will you isolate and diagnose the problem? Nice to know it's not in the Citrix server or the client, but then where is it?
This is where analytics come into the picture (see Analytics & IT Service Management on this blog), and things can get really complicated. However, it's good to focus on this objective:
The key to effective business service monitoring is the ability to monitor what is happening at each layer of the infrastructure --- across an array of distributed network, system and application components --- and automatically identify which component layer, in which domain, is the source of a problem.
QoE decisions, like many technology investments, can be tribally driven. This is particularly true if the organization has not invested in the time to understand and define 'what is a service' and performed some due diligence in analyzing processes.
Some IT tribes will display true leadership and go beyond thier comfort zones by incorporating other technical silos into the equation, but I suspect this is going to be difficult for many. Taking an approach driven by best practices (such as ITIL) can help avoid experiencing the angst associated with knowing with absolute certainty where the problem isn't, but not knowing where the problem is.
posted by John Worthington @ 7:26 AM
0 comments
