I recently participated in a webcast that I called the “Top Five Benefits of Transaction-Centric NPM” – resisting some internal pressure to use the more common “Application-Aware NPM” or AA NPM term. Google the term “Transaction-Centric NPM,” and you’ll be hard-pressed to find content beyond recent references to the webinar. I’m not attempting to coin a new acronym – TC NPM, anyone? Instead, my goal is to shed some light on the often diluted meaning of AA NPM’s Application Aware prefix, and at the same time emphasize the value of transaction visibility.

In the context of AA NPM, application awareness can – and does – mean many different things to different people; it’s no wonder, given the differences behind the way many NPM vendors apply the term. In fact, Gartner’s description leaves the door wide open, calling it a maturation step to Network Performance Monitoring and Diagnostic (NPMD) solutions that “…adds some degree of application visibility accomplished via packet-based monitoring, which can provide varying degrees of application context….” Compounding the opportunity for confusion is the undefined overlap with the APM market.

Given this description, virtually any probe-based NPM vendor can claim the AA NPM label (and I don’t begrudge them). Awareness – meaning visibility – is accomplished via traffic classification, ranging from very basic address/port mapping (Port 80 – HTTP, Port 1521 is Oracle, etc.) to more sophisticated and granular DPI approaches such as NBAR2. The benefits are real; application-granular capacity analysis, application path routing, and insight into QoS policies are just some examples.

The waters get muddier when it comes to application performance, and I begin to poke a bit at this topic in the webcast. I’ll give you a preview here.

AA NPM solutions measure what is often termed “session-layer response time” – diagrammed here.

Session layer response time
Session layer response time

For a given TCP connection, a contiguous sequence of data packets flowing from client to server is considered a request message; when the direction of data flow changes, the subsequent contiguous sequence of data packets flowing from server to client is considered the corresponding reply message. From these measurements, network time can be separated from server/application time. Classification techniques associate these measurements with an application, resulting in a rather puffed-up metric called something like application response time.

The problem is that, while this response time measurement is generally uninteresting and often unactionable, it is often positioned as the foundation for rather lofty benefits, from collaboration and DevOps enablement to end-user experience visibility and business alignment. The point I make in the webcast is that these claims require something more than basic application awareness; they require a transaction-centric view of performance.

Of course the term “transaction” also has multiple definitions, so I’ve taken some time in the webcast to discuss these; the insights available from a network performance monitoring solution will to some degree be dictated by this definition.

As a teaser – view the recording here – here are the top five benefits:

  • Business collaboration (users are the face of the business)
  • Development collaboration (beyond cordiality)
  • Automated fault domain isolation (driven by what matters)
  • Broad application support (it’s not just web)
  • New relevance for network metrics (new tricks for old dogs)

I’ll be expanding on some of these topics with examples and more technical details in upcoming blog posts – but there are enough raw vegetables (I’m trying to coin a vegetarian-friendly substitute for red meat) to get you salivating in the webcast.

The webcast is two-part; Bill Kleyman (VP of Strategy and Innovation at MTM Technologies) is the first speaker, and talks quite passionately about the evolution of the cloud and the application, with insights into the impact these trends will have on performance management; my part begins at about 23 minutes into the webcast. I hope you enjoy, stay tuned for more on the topic, and feel free to comment below.