The importance of managing (monitoring as well as actively managing) networked applications for QoE should be all but self-evident. EMA data from 2007 (Figure 1) showed that a healthy 72% of respondents from a wide range of enterprises and service providers had more than 20 remote branch offices, and in a parallel EMA survey, 34.1% had more than 100 remote locations. Not only are IT applications becoming the heart of many businesses and central to their competitiveness, networked applications in all their flavors are reshaping how and where enterprises across virtually all verticals, government agencies, and even some service providers are doing business. Networked applications are in fact actually enabling new business models across verticals -- true today with Web2, and even truer tomorrow with unified communications, and in particular the advent of globally dispersed service-oriented architectures (SOAs).
Figure 1: How Many Branch Offices Does Your Company Have?
Given this challenging situation -- one that nevertheless is placing more not less attention on network operations -- many networking planners, engineers, managers and architects are looking to leverage more holistic and cohesive views of network-to-application performance, including QoE. But beyond this almost constant drumbeat for "cohesiveness," there are generally two types of approaches, two schools of thought, and often two types of personalities most associated with the challenge of managing networked applications. Group A includes those within the network team who prefer to see their role as absolutely bounded by the networked infrastructure without much (or any) interest in dialog with other constituencies. These constituencies might include application managers, data center managers, and even application developers, as well as service management teams or those groups that are directly customer-facing. To the degree that network operations has a defined set of customers -- and in some cases this group is often first call for networked application problems -- the constituencies can directly include the customers themselves. The second group, Group B, includes those within network operations who either grudgingly, or more proactively, recognise the need for these dialogs as an intelligent extension of their broader responsibilities.
As you may have assumed by now, this analyst, along with EMA's IT consulting team, favors Group B. And so to answer the question of QoE, this e-Book will reflect a wholehearted affirmation of the idea that application QoE is a collective, collaborative endeavor that cannot be done with stovepiped metrics and stovepiped thinking. In this section, we'll look at the differences between QoE metrics and diagnostic metrics. While the two may overlap, they are fundamentally different.
Figure 2: How Would You Rate the Following in Terms of Diagnosing the Root Cause of a Problem?
As you can see in Figure 2 -- taken from early 2007 EMA research -- network configuration, systems configuration and application configuration top the charts, followed by event-based information, when it comes to diagnosing problems with application performance over the network. Other technologies -- such as dynamic packet analysis, session reconstruction, and flow-based volume information -- follow. This data is striking in that it shows the growing awareness of configuration information -- changes made to the infrastructure, in actually diagnosing problems reflective of application performance over the network. The population involved with this research was about 60% network operations and 40% application management and data center (respondents had to feel that they "owned" or at least "shared in owning" responsibility for managing application performance over the network). This data alone reflects the need for collaboration, and the report also showed that more than 60% of our respondents actually had organisational changes made to support better cooperation between network and application managers.
All this is well and good, and useful in its way. In other research, the importance of flow-based information as a continuum (application flows, packet analysis, route analytics, transaction analysis) showed more strongly, which is worth pointing out here. But the even more important point is that none of this is QoE.
Figure 3: How Would You Prioritise the Below for Assessing Quality of Experience?
In this same research in Figure 3, we see some rather basic priorities relevant to QoE, with availability edging out response time 71% to 59%, followed by mean time to repair (MTTR), mean time between failure (MTBF), and round-trip latency across the network. In following sections, we will look more closely at what QoE metrics can and should be, and how you can best instrument to gauge them. Suffice it to say here, though, that the first step in planning for effective QoE for networked applications is to recognise that it is a collaborative effort. The second step is to realise that QoE and diagnostics are typically two separate categories of metrics, even if there is some overlap. One set of metrics, QoE, begins to capture that unfathomable complexity of actual user "experience" in dimensions, ideally, most relevant to the user.
Putting yourself in their shoes is the way to start. One hint: If you think that the network is a self-contained entity and that you should care only about the demarcations of your WAN, you're missing the point, even if that's how you've been trained organisationally. The network is a part of the larger delivery system for QoE in which the only true metrics that matter ultimately reside within the flesh-and-blood experience of your consumers. Even if you're a WAN service provider, you should begin to think twice about the complacency of ignoring this core requirement. As many as eight years ago, one CIO threw out his brand-name telco for one that would partner more smartly on applications versus plumbing. And in the enterprise, network management will forever be relegated to blue-collar status, without even a seat at the table to defend itself, if it ignores this increasingly relevant lesson.
The good news is that technologies are available today that are well tuned to network operations that can address this very requirement.