By Chapman Lever

The digital world is quickly engulfing every business and industry. Users at minimum now expect that their initial interactions with a business will be through a digital channel.

As a result, we’ve seen the technology world evolve to meet ever-increasing expectations of consumers. New front end languages built to leverage modern browser technologies, such as Node-Js, are now in vogue. We’ve seen the proliferation of cloud infrastructure that can handle extreme scaling, and we’ve seen businesses eschew traditional waterfall development processes to embrace more agile and DevOps friendly practices like continuous integration and delivery.

Relative to these advances, the evolution of the monitoring world has somewhat lagged behind. While nearly 70% of businesses are leveraging some kind of hybrid cloud or public cloud infrastructure, less than 10% of global enterprises leverage web-scale application performance monitoring (APM)  architecture in support of their digital business needs. Some of this is the fault of the enterprise, but in many cases, legacy APM vendors have failed in their attempts to rapidly upgrade their on-premises offerings.

Technology isn’t the only factor holding back APM vendors. Many legacy APM providers hold tight to philosophical views that are increasingly impractical in the modern digital world. Here are three of the most common misconceptions.

1. Make infrastructure monitoring a priority and address user experience later on.

This is arguably the wrongly held belief that hurts APM customers the most. We typically see APM vendors pitch the enterprise on instrumenting every JVM, then gradually scaling back their monitoring as they go up the stack.

In today’s world, however, user experience is paramount. The most important thing to monitor is the UX (or CX – customer experience), so you should start there. Then, from that starting place, work your way down from an investment perspective with infrastructure monitoring being the smallest bucket.

2. Shift-left monitoring means “Let’s instrument every pre-prod environment in your pipeline and give you 24/7 coverage of everything all the time!”

First, ouch. The total cost of ownership for an undertaking such as this is enormous. If the upfront costs don’t immediately shut down the conversation, then the reality of managing its implementation surely will. APM tools were not built to fit neatly into a CICD pipeline. Furthermore, at their worst, these implementations add a ton of noise (and cost) to your process and significantly add to the workload of developers.

Rather than instrumenting your pre-prod environments to provide 24/7 monitoring, look at tools that can pull data as part of a lifecycle event. For example, integrate a performance test as part of your CI build so that you can look for potential performance regression as part of a software release. Workflows like this provide immediate context without adding unnecessary friction or noise to your process.

3. All data–of any type–is valuable. Collect as much as you can all the time.

Again, this is false. Not all data enhances business context or adds value. More often than not, I hear business owners complain that they are “drowning in data.”

If no one is looking at the data is it providing value? I recommend only collecting data that will be actively contextualized and integrated into the internal processes of the business.

When evaluating whether you want to collect a type of data or not, keep these things in mind:

  • Data ages very quickly in the modern digital world
  • All datasets are inherently biased
  • Data collection is not free
  • How will you add context to the data?
  • Who will be responsible for contextualizing the data?

By making these considerations, you can ensure that your data is serving its purpose rather than just adding noise.

While these misconceptions remind pervasive, I’m hopeful that they are on their way out. As an industry, we need to evolve away from clunky “business as usual” approaches and toward more agile and cost effective solutions