Many of us are grappling with the modern demands of digital business; developing new mobile apps, evaluating security in the face of IoT, moving to hybrid clouds, testing approaches to defining networks through software. It’s all part of the hard trend towards service-oriented IT, with a primary goal of delivering a premium end user experience (EUE) to all your users – internal, partners, and customers – with the speed, quality and agility the business demands.
How do you meet these elevated expectations? As modern data centers evolve rapidly to meet these agility demands, network and application architectures are becoming increasingly complex, complicating efforts to understand service quality from infrastructure and application monitoring alone. Virtualization can obscure critical performance visibility at the same time complex service dependencies challenge even the best performance analysts and the most effective war rooms. While this may read like a recipe for disaster, within are secrets to success.
How beautiful is your app?
Remember the adage “beauty is in the eye of the beholder?” The same applies here; service quality is in the eye of the user. It’s hard to argue with that, especially when we consider the user as the face of the business. So, of course, 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”. We’ll ignore vendor attempts to dumb down its meaning, and acknowledge it is a subset of the more comprehensive term user experience, or UX.). 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
An important lesson: EUE measurement is key
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
Complexity drives APM evolution
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!
Everything old is new again
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.
But didn’t we learn a lesson? EUE key to effective service
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.
Back to the service quality adage: Dynatrace NAM and EUE
Dynatrace Network Application Monitoring (NAM) measures end-user response times, offering real-user measurements for a wide range of applications. In fact, NAM’s breadth of EUE measurements make it unique in the industry. NAM uses EUE, network and tier-level transaction visibility to analyze performance, to drive fault domain isolation, and determine business impact; in that sense, it is comparable to a very focused and pre-programmed operations analytics solution. Application-oriented dashboards give converged operations teams a unified view of service quality to enable effective collaboration – within IT operations domains as well as with development and business peers – always using the multi-discipline collaborative context of EUE. With optional drill-down into code-level application monitoring or packet-level network analysis solutions, IT teams have a macro-to-micro lens through which to view and analyze service quality. And, for organizations with active ITOA initiatives, NAM provides open interfaces offering both raw metrics (wire data, for those who want to build their own analytics) and more valuable packaged (pre-analyzed) insights.
Your mission: Understand and apply EUE data
How well does your organization understand end-user experience? And does (or will) your ITOA initiative include EUE?
As always, I’d love to hear your comments.