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.

Next week, I’m attending the DEBS 2008 conference in Rome. The conference is a great occasion for people from the academic and industrial worlds to mix and share ideas. Unfortunately, I’ll be cutting my attendance short due to customer commitments, but I am looking forward to seeing how event processing is maturing as a technology on many fronts. The DEBS conference pushes large scale considerations to the fore, and focuses less on the minutiae of implementation such as event processing languages or correlation techniques. Instead, discussions will tend to focus on the distributed aspect of event processing, with issues such as security, availability and reliability, volumes, filtering, event ordering, and synchronization all being presented. And I’m especially looking forward to the software demonstrations.

A surprisingly interesting question; are we talking about a) the processing of complex events or b) the complex processing of events? Both possibilities lead to interesting follow on questions such as what is a complex event? or what constitutes complex processing of events? This has been a source of much discussion within the event processing community and rather than present the argument in this post, I’d like to present the outcome of the discussion.

Recently, David Luckham and Roy Schulte produced an event processing glossary which defines complex event processing as the processing of complex events, and defines a complex event as an event that contains other events (known as it’s members).

Of course, the members of one complex event can be other complex events, leading to a hierarchical tree (or even graph!) structure of nested events. The processing of complex events can consist of tasks such as aggregating a set of events into a new event; deriving events from other events; filtering events based on their arbitrarily deeply nested members and so on – a rich paradigm indeed!

Obviously this hierarchy of events must start somewhere; with simple events that do not have other members. According to the event processing glossary, these simple events can be used to represent anything that happens or is perceived as happening. Starting with source events a powerful complex event processing network can be built which uses tasks such as aggregation to build intelligent models of business processes in an organisation.

One of the first tasks of the newly formed Event Processing Technical Society when they meet, will be to produce an event processing glossary which will hopefully become an industry standard. We look forward to seeing what they come up with!

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.

In many organizations, despite knowing what everyone is doing, finding out what’s actually going on can be next or nigh impossible. Operators are delivered notifications about everything that happens, good and bad, and they end up in a fog of detail.

Complex Event Processing (CEP) allows us to tackle this “wood for the trees” problem in two ways. First, it allows the unimportant details to be discarded, leaving only those that are relevant. Second, it allows those details to be tied together into a business oriented view.

It is often the case that under normal operation, things don’t always go to plan. A user’s session may take longer than normal to start or a credit card validation times-out. These once-off errors are not that interesting, particularly, as by the time they register with the support staff, the cause of the error has passed and everything is back to normal. What’s far more interesting is knowing when five users in a 10 minute window are experiencing problems or the credit card validation fails 3 times in a row. CEP’s Event pattern matching solves this problem very nicely. It allows detection of patterns like “X is followed by Y or Z in a 10 minute window”. When the pattern is detected an alert notification can appear on an operators dashboard or be sent by text message to the support staff. Only the events that indicate something of interest is happening get presented to the operators.

Another problem is that the monitoring that does take place does not give any real insight into how the business is performing. Low-level service monitoring can tell us that the web application is up and running or that the credit-card payment gateway is functioning ok but does not tell us how these services are supporting (or not) the business side and, ultimately, the customer. CEP solves this problem by allowing the low-level happenings (a user a logged in, a credit card payment was processed) to be aggregated into a more high-level event (user bought something over the web). This is known as “Event Abstraction” where a set of basic events are represented by a more high-level one. Thus, the actual business value emerges from the deluge of detail but the detail is retained should it be needed.

So CEP allows the bigger picture to emerge from overwhelming amount of detail. That’s the well informed ones! The not-so-well informed ones may be oblivious to what’s happening until they get phone calls from irate customers.

Conrad O’Dea

Chief Architect

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

The Event Processing Technical Society (EPTS) has been officially launched, and the website is at http://www.ep-ts.com. A lot of credit has to go to Opher Etzion (http://epthinking.blogspot.com/) for being the main driving force and organizer behind the scenes, but there are lots of other names too that have been involved from the start.

The EPTS is an unusual group by today’s standards. It is made up of a great mixture of individual people and companies from the academic and commercial worlds, and even includes customers and analysts. It has officially met three times, and the fourth meeting will take place later this year. Work has been ongoing for some time now, albeit in the background. As the group gathers momentum, I anticipate a busy number of years ahead.

Brian Connell

CTO

I am delighted to announce the launch of our new BAM Blog. I hope over the coming weeks and months that you find it an excellent resource for cutting edge information and debate on the developments of Business Activity Monitoring.

First let me give you a bit of background information on WestGlobal and why we have started this Blog.

WestGlobal is based in Dublin, Ireland, and over the past number of years we have designed and developed Vantify Experience Centre. Vantify provides enterprises with a real-time insight into the performance of their Business Activities and Customer Experience. The power behind Vantify is driven by our own Complex Event Processing (CEP) engine, a factor which we are confident will be key to the long term success of any enterprise standard BAM solution.

Given the experience that our team has gained from our customer engagements and product development efforts, we hope that the wider BAM and CEP community will benefit from our shared thoughts, ideas and insights.

Well that’s enough of the marketing speak and if you would like to find out more on the product or company feel free to browse through our website www.westglobal.com

Now lets get down to business!!

Patrick Lennon

Chief Executive