|By Gary Kaiser||
|February 7, 2016 11:00 AM EST||
IT's Little Secret: Too Little End-User Experience (EUE) Data Use
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 toward 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 from EUE perspective?
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. Of course, to understand service quality, we should be measuring end-user experience. (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.
- Understanding Application Performance on the Network | Part 1
- Understanding Application Performance on the Network | Part 3
- Understanding Application Performance on the Network | Part 2
- Understanding Application Performance on the Network | Part 5
- Understanding Application Performance on the Network | Part 4
- Understanding APM on the Network
- Understanding Application Performance on the Network | Part 6
- Can Wire Data Be #APM? | @DevOpsSummit #DevOps #AI #ML #Monitoring
- IT Operations and Digital Disruption | @DevOps Summit #APM #DevOps
- Application Performance Analytics | @DevOpsSummit @Dynatrace #DevOps #APM