The BTM Blog

There’s some ongoing discussions in blogland as a result of a recent blog posting here by my good friend Tim Bass.  In his post, he applauds the use of analytics to the point of damning the current crop of CEP vendors for being made up of companies that don’t “support or advocate advanced analytics”.

Opher responded here by saying that most of today’s CEP problems do not require advanced analytics, and used the metaphor of blind men feeling an elephant.

For me, I confess that I fail to understand the debate.  I’m curious as to the term “analytics”.  Just what is “Advanced Analytics” as applied to CEP?  Is it advanced situation detection – in other words, will I use advanced analytical techniques to detect a situation?  Or is it advanced visualisation – will I be able to produce a real-time updating graph or chart based on a series of complex mathematical calculations?

Here at WestGlobal, we tend to focus on detecting whatever situations need to be detected, in the lowest latency required.  We can use a variety of techniques, depending on the situation.  We might find that one situation may be detected with a series of very simple rules, but that another requires enrichment from a data source, while joining with a variety of other data streams, and a dependency on the occurance of a series of other situations within the past 2 minutes.  But is this advanced analytics? 

For me, analytics is not a requirement – at most it’s an implementation detail for a specific problem.  As Tim points out, there are probably many examples of event processing that require very sophisticated processing techniques (I’m avoiding the term analytics).  As Opher points out, most applications today don’t require it.  And I’d like to point out, if the requirement existed and someone could make lots of $$ doing it, then chances are there’s somebody doing it already (and they’re keeping it a secret for as long as they can).

I’d love for Tim (or anyone else) to post an example or two of specific problems that exist that require advanced analytics.  Otherwise, it may be that I, and many other people, conclude that the trumpeting of the requirement of advanced analytics is just another type of snake oil.

In our work with IT intensive enterprises, we observe different approaches to the implementation of IT and service monitoring. These range from a fragmented model dependent on multiple and effectively isolated ‘point’ solutions through to highly unified BPM (Business Process Management) models providing excellent monitoring performance but typically demanding significant investment, technology and process re-architecting and imposing restrictions on supported technologies or vendors.

In our view, the most successful approaches in terms of maximising IT ROI, technology performance and improving Customer Experience are based on a combination of pragmatism and planned coherence. Pragmatism comes from an approach that supports highly heterogeneous IT and network environments comprising multi-vendor technology deployed often over as many as 10 or more years. Coherence recognizes the need to combine different monitoring ‘models’ to achieve a rich, timely, efficient and complete view of how IT and network systems are interacting to deliver excellent Customer Experience.

At WestGlobal, we have found a 4-Quadrant grid is useful in explaining the ‘coherence’ element. On the vertical axis, ‘Monitoring Focus’ moves from Technology in the ‘South’ to Business Activity/Customer Experience in the ‘North’. The horizontal axis measures timeliness or immediacy, with non-real-time (nrt) to the West and real-time (rt) to the East. All monitoring approaches can be positioned on this grid and we can outline the key characteristics of each quadrant as follows. . .

NW (nrt/ Business Activity Focus): Business Intelligence / Data Warehouse exceptionally rich in the ability to create marketing and businesses views of customer and business activity; but ‘after the event’.

SW (nrt / Technology Focus): Historical technology performance measurement. Typically based on log and CDR file analysis and frequently used for capacity measurement and planning of underlying IT and network elements.

SE (rt / Technology Focus): Here the focus is typically on monitoring and alerting the health of individual or groups of IT / network elements or application servers (e.g. WEB servers). But this provides limited insight into actual Customer Experience which may depend on the interaction of many elements and servers.

NE (rt / Business Activity Focus): Here the focus is on measuring the health and performance of actual business activities. It is interesting that while it is this layer that the customer interacts with and can therefore reasonably be argued as the most important in measuring Customer Experience, monitoring often remains focused on the underlying technology i.e. the ‘South Side’. The emergence of Complex Event Processing as a means to enhance the performance of solutions in the NE quadrant provides excellent opportunities for enterprises to detect patterns and events that signal potential Customer Experience degradation even before the customer is impacted.

The most effective monitoring approaches reflect the need to ‘cover the bases’ in the above grid. This implies a need for organizations to have some degree of coordinated planning across the complete monitoring architecture. With such an approach, additional benefits arise from ‘Grid Synergies’. For example, while it can often be difficult for Business Intelligence solutions to access certain network or low level data directly, the data can often be proxied via elements in the real-time side of the grid. Similarly, integration between the NE and SE quadrants combines real-time Business Activity Monitoring with the ability to ‘drill-down’ into the underlying technology only when necessary, for example to investigate a degradation or failure in a Business Activity. This is approach we have adopted with Vantify Experience Centre, in other words an ‘East side’ solution.

Last week, I visited a Tier 1 European Telco, and spent some time with their Technical Operations director. We discussed the growing trend towards outsourcing, and in particular the difficulty that executives have in placing their trust in an external company running all of their IT systems and providing at least the same level of service performance as before the outsourcing occurred. A pretty basic requirement, I’d say. But it appears that traditional monitoring tools, focussed on infrastructure and the like, are really designed for “reactionary” organizations – that is organizations that wait until a problem has occurred and then rush to fix the problem. It struck me that this type of monitoring is binary in nature. Its alive = everything is OK. It’s not alive = react and fix it. When you think about it, traditional monitoring nearly always fits this pattern. This model also carries through to performance monitoring. Each single event is examined and is compared to a threshold – some value that equates to “Below the line = OK – but above the line = react and fix”. So I equate traditional monitoring with single-event threshold based monitoring for reactionary organizations.

The executive in question described the ideal solution as one that could predict what was going to happen next. I don’t think he meant a crystal ball for taking to the racetrack or picking next weeks Lotto numbers – but what he described as the ideal solution was one that would inherently understand what was considered “normal”, and to also understand what was considered “abnormal” – from a business activity point of view. By looking for patterns of abnormal activity over shorter periods of time, disasters can be avoided by spotting early warning signs and fixing smaller problems before they turn into giant ones. His ideal solution has a “Big Brother” feel to it, where all behaviour is analysed and examined and hit teams immediately dispatched to fix anomalies.

It made sense to me and gave me a lot of food for thought. What I like is the top-down approach – which made me ask the question “Why do we monitor bottom-up? How do I know for sure that the technical problem is causing a business impact?”.

Do I even care about a technical problem that doesn’t cause any business impact? Very Zen-like. Reminds me of trees falling in forests.

Brian Connell

CTO