Remember the adage "beauty is in the eye of the beholder?" Similarly, service quality is in the eye of the user. So, to understand service quality, we should be measuring end-user experience (EUE). (Let's work with the intended definition of EUE, which is end-user response time, or "click to glass").

In fact, EUE visibility has become a critical success factor for IT service excellence, providing important context to more effectively interpret infrastructure performance metrics.

You may already be measuring EUE. Some of your applications – particularly those based on Java and .NET – may already be instrumented with agent-based APM solutions. But there are a few challenges to an agent-based approach to EUE:

■ These agent-based solutions may not be available to or suitable for operations teams.

■ Not all Java and .NET apps will be instrumented.

■ Your agent-based solution may not measure EUE.

■ Your agent-based solution may only sample transaction performance (let's call this some user experience, or SUE).

■ Many application architectures don't lend themselves to agent-based EUE monitoring.

For these and other reasons, IT operations teams have often focused on more approachable infrastructure monitoring – device, network, server, application, storage – with the implication that the whole is equal to the sum of its parts. The theory was (or still is) that, by evaluating performance metrics from all of these components, you could assemble a reasonable understanding of service quality.

The more ambitious – in some cases, thought-leaders – combine metrics from many disparate monitoring solutions into a single console, perhaps with time-based correlation, if not a programmed analysis of cause and effect. We might call these manager of managers (MOMs), or sometimes label it Business Service Management (BSM); too often, we referred to them with unprintable names.

Some still serve us well, likely aided by a continual regimen of care and feeding; still more have faded from existence. But we have (or should have) learned an important lesson along the way – EUE measurements are critical for IT efficiency for many reasons, including:

■ You will know when there is a problem that impacts users.

■ You can prioritize your response to problems based on business impact.

■ You can avoid chasing problems that don't exist, or deprioritize those that don't affect users.

■ You can start troubleshooting with a problem definition that matches your metrics.

■ You will know when (or if) you've actually resolved a problem.

ITOA: Solving the Big Data Problem

We (collectively as vendors and customers) continue to mature our performance monitoring capabilities, evolving from real-time monitoring and historical reporting to more sophisticated fault domain isolation and root cause analysis; maybe we're using trending or more sophisticated analytics to predict, prevent, or even take action to correct problems.

One of the compelling drivers is the increasing complexity – of data center networks, application delivery chains, and application architectures – and with this, an increasing volume of monitoring data stressing, even threatening, current approaches to performance monitoring and IT operations. It's basically a big data problem.

And in response, IT operations analytics (ITOA) solutions are coming to market as an approach to derive insights into IT system behaviors – including, but not limited to, performance – by analyzing generally large volumes of data from multiple disparate sources.

The ITOA market insights from Gartner tell an interesting story: spending doubled from 2013 to 2014, to $1.6B, while estimates suggest that only about 10% of enterprises currently use ITOA solutions. That's a lot of room for growth!

I'll not dive into ITOA in any depth here, and point out that the value of ITOA goes beyond our focus here on incident and problem management. For example, it can offer important value for change and configuration management. But let's focus on the use of ITOA for performance management; data sources could include system logs, topology information, performance metrics, events, etc., from servers, agents and probes. The information is stored, indexed and analyzed to accomplish important goals such as identifying trends, detecting anomalies, isolating fault domains, determining root cause, and predicting behavior.

Does this start to sound familiar? The resemblance to earlier MOM-like efforts to combine disparate monitoring data is striking. That's not to downplay the many capabilities and analytic promises that ITOA makes – such as machine learning – that should give it stronger legs; it's simply to point out an obvious similarity. And, in fact, ITOA is often talked about as the future of APM.

When we consider application performance, even the most considered ITOA implementations will come up short if they don't include the end-user experience metrics. Sure, you'll spot anomalies you never knew existed, and you'll stand to gain valuable insight into impending problems. But IT efficiency and business alignment – critical for effective service orientation – requires the context of the end-user's experience; to ignore this is to skip a big step towards maturity.

How well does your organization understand end-user experience? And does (or will) your ITOA initiative include EUE?

Gary Kaiser is a Subject Matter Expert in Network Performance Analysis at Dynatrace.