BSM integral to APM

Earlier in this Industry Insight series, I talked about the birth of application performance management (APM) and how it has gradually combined with BSM to create the new status quo in application monitoring. Now, I'm going to talk more about certain elements of BSM that have become integral to the 'new look' APM.

When combining the strengths of APM with user-defined transaction profiling, something truly special happens.

Jaco Greyling is solution strategist at CA Southern Africa

I will start with 'user-defined transaction profiling' and finish off with a new concept, called 'application runtime architecture discovery'.

It's important to understand the definition of a transaction when I talk about user-defined transaction profiling. In the traditional sense of the word, it means information processing that is divided into individual operations (unit-of-work). Each transaction must succeed or fail as a complete unit, and is designed to maintain a computer system in a known, consistent state.

In application monitoring, however, it has far greater meaning that encapsulates the users' actions. For example, if someone wants to pay a beneficiary via an EFT, it usually involves a few steps, including: selecting the beneficiary, entering the value, additional information like a reference, and finally confirmation of the payment. Behind the scenes, myriad transaction processes are kicked off - from database updates to reference data look-ups and more. Yet, from the user's perspective, this constitutes only one transaction, called a beneficiary payment.

The problem with traditional user-defined transaction profiling or business transaction (BT) monitoring is the lack of visibility into the sub-systems that underpin it. This is the Achilles heel of BSM, the inability to tie the business services to any back-end monitoring.

It is thus difficult to pinpoint the root cause of a performance problem, whether it is network-, database- or code-related. However, when combining the strengths of APM with user-defined transaction profiling, something truly special happens - the ability to monitor the end-user experience (EUE) from the user actions over the network, to the low level back-end calls that make up a BT.

Another benefit is the ability to break down the latency of each layer in the transaction path into: end-user time, network time, logic time and database time. This ability can empower operations immensely by pinpointing the fault domain more rapidly, allowing the subject matter experts to resolve the problem(s) sooner. This also eliminates the 'blame game' typically found in organisations, where different teams (eg, application support vs network support) tend to shift blame.

The reason each BT can be measured is due to clear transaction boundaries. The ability to record the beginning/end of every business transaction allows monitors to insert markers between each transaction and isolate one transaction from another. Using end-user monitoring techniques enables one to look for these markers and capture business transaction execution times while linking this to the back-end execution path via 'dope and trace' techniques.

Application runtime architecture discovery is a relatively new concept in application performance management. The necessity for runtime architecture discovery came about with the exponential increase in application complexity and the sheer number of independent modules in modern-day application architectures. In short, there are four distinct reasons for this:

* The increase in services-oriented architectures, representational state transfer (REST) and computational REST (CREST) architectures.
* The complexity and modularisation of modern applications.
* Adoption of rapid development methodologies like Agile.
* The deployment of cloud services which increases complexity.

A development technique called 'late binding' has stemmed from this - it facilitates the development of more modularised applications. Late binding uses the operating system to translate parameter lists at run time into calls to the drivers' members - systems people connect to. Users don't know how the architecture is going to reflect until they're in production.

There are various ways to observe and analyse patterns to create topological diagrams. The convergence of infrastructure management (IM) and APM - two quite distinct monitoring disciplines - have seen the successful articulation of both business services and the underlying infrastructure (topology) that supports it in one unified view.

This has come as a great benefit to enterprises, where manual service-dependency modelling was the only way. Updating these maps became a cumbersome task which only a select number of companies could afford. Instead, the convergence of APM and IM with user-defined transaction profiling - via EUE monitoring - gave birth to dynamic application runtime architecture discovery.

There are three major benefits to runtime discovery: change impact analysis; incident correlation to IT services; and gap analysis. This is very important in light of the fact that the industry is moving away from 'boiler-plate' monitoring to IT as a service.

The ability to see slow responses anywhere in the infrastructure - seeing slow components in the topology map of the IT service - is first prize for operations. Additionally, the ability to see what certain infrastructure and/or application changes do to the overall IT service is vital for change management. Without dynamic architecture discovery, it's nearly impossible to assess the impact of a change or extend a bottleneck on the rest of the IT service.

In a nutshell, application runtime architecture discovery allows users to assign business context to underlying performance problems.