The BTM Blog

Back from beautiful Trento in Italy where the 5th EPTS Symposium was held.  Marvelous location, and we even managed to find a really beautiful Michelin-star rated restaurant.

While it was great to meet up with some friends and colleagues, and there were some very interesting nuggets at the conference, my overall impression was one of disappointment and frustration.  We are still struggling with basic concepts, arguing about the definition of Event Processing (and there are some very … different … views), and still haven’t managed to produce anything that either identifies the major components you’d find in a reference architecture, or found commonality in any of the use cases.  Actually .. working groups aside, that’s kinda what we ended up with last year.  And the year before…

And before I offend the very people I wish to praise and give credit to, let me be clear.  It’s most definitely not the fault of the people collaborating on the working groups.  They’re contributing.  Giving up their precious time.  In order to make progress, we really need to get more people involved, and we need to set clearer mandates on the deliverables for these working groups.

A new working group was proposed to promote the EPTS.  This will also involve publishing the public deliverables from the working groups, and encouraging new members to join and contribute.

Here’s hoping that this time next year, I won’t feel another Bill Murray moment coming on!

A partner of ours returned from a meeting recently with the reaction from the prospect of “I already monitor my systems, why do I need more monitoring?“.  Great question.

I get that a lot. It’s a normal reaction. Usually from the IT Operations Director who has spent considerable sums of money on monitoring to date, and can boast an arsenal including:

• Hardware monitoring
• Application availability
• Network monitoring
• Website monitoring
• Transaction monitoring
• Speciality tools for monitoring Oracle, SAP and the like
• And perhaps some dashboard aggregators that consolidate information from many separate sources into one single dashboard.

So why would an organization need more monitoring?  Well, the single most compelling reason is to cut down on the number of outages and incidents that impact business performance.  To do this, there’s more to monitoring than just detecting when things go wrong which is what the products in use by most organizations are stuck with.  By then, the damage is done, and something has already gone wrong.

Ideally, monitoring should be smart enough, and powerful enough, to detect a situation that indicates with a high probability that something needs attention before the situation develops into something bigger and more costly.  It’s the equivalent of warning you that your car is about to be towed instead of telling you that your car has just been towed.

In other words, rather than coping with IT disasters, what about averting them in the first place?  A system that constantly monitors your key business activities and transactions, with the ability to connect events together in order to detect variances within your business transactions.  Tells you exactly what’s going on in real-time and provides timely warnings.

For example, your current monitoring systems for processing orders might provide the following information:

1. Database server OK, ping round trip 0.112s
2. Database OK, 32 transactions per second, average transaction 1.232s
3. Web Server OK, 42 connections

Whereas a system monitoring business events would instead report:

1. 14 Orders in progress
2. Average time to process orders is 6.687 seconds
3. Alert: 13% of orders processed in last 5 minutes were above 9 seconds.  Current trend is that an order will breach the SLA of 12.5 seconds within 40 minutes.

So rather than overworked IT staff trying to filter millions of seemingly disconnected IT events, most of which report little or nothing by way of business significance, they can instead focus on meaningful business objectives and performance indicators, and can react quicker to events that impact business performance, as well as communicate with non-IT staff using the lingua franca of your business.  And most importantly, if you’re already solely relying on traditional monitoring approaches, then you can expect to significantly further reduce the number of outages and incidents from anywhere between 20% and 80%!

A friend of mine has been tweeting about a very interesting use of Twitter.

Paul Watson responded to the challenge from DIYcity to build “an early warning system for outbreaks of flu, colds and other communicable disease at the city level”.

Paul’s design is to correlate twitter trends and location information to identify when people start talking about the flu. Then he can compare these stats against expected trends to identify possible spikes. Paul plans to use twitter to send out warnings and you can subscribe to these feeds to receive early warning of an outbreak.

Note Google did something similar for the US based on search terms but without the warning system.

How reliable will the twitter trends be? Time will tell but what’s fascinating about the Google data is you can see their results compare well with data from U.S. Centers for Disease Control and Prevention (CDC).

I hope we’ll see similar results with the twitter data.

This is a fascinating application, it’s built using data that is easy to access and with technology that is easy to use and open-source. To think that you would have probably needed the cooperation of the military to do something like this a few years ago.

I was recently giving a presentation to a rather large utility provider, and was asked the question “But why do I need real-time?”

Good question.  And a very difficult question to answer correctly in most cases.  There’s lots of answers that address the requirement – in theory.  Take your pick from the ones I come across most often, and may even be guilty of uttering one or two of these myself:

• React to an opportunity or threat
• Become more proactive
• Prioritize resources
• Make smarter decisions quicker

But sometimes the right answer lies in asking a question in return.  “Is there anything you could do if you knew something had just occurred?“  This turns the question around to the customer and they always find that there is always something that can be done to improve the situation!

Within a business context, knowing immediately if there are problems means that you know at least as soon as your customers do.  A well known analyst firm estimates that more than 60% of problems are reported by customers (and in our experience, this number is low.  We generally see numbers approaching 80%)  But the value of detection is completely lost if there isn’t a plan for reacting.

So one definition of real-time is defined or determined by the window of time that exists whereby a detection and reaction have maximum benefit.  So whether you need to react within 5 minutes, or 5 micro-seconds,  each situation has it’s own context and definition of real-time.

Ask The Brian

But the real value of detection is predicting situations in advance by being able to detect the patterns that indicate a high probability of something about to happen in the future.  This is possible so long as situations exhibit a consistent set of early-warning signs – to the uninitiated it can seem a little bit like High tech fortune telling.  But the results are definitely worth it.  We’ve seen results in our customers showing more than an 80% drop in customer detection rates and incidents tagged as high priority.  It’s where we definitely see the value of Complex Event Processing and Business Activitiy Monitoring intersecting.

Having read Opher’s excellent blog posting on describing CEP maturity models, I found that while I agreed with Opher’s descriptions of differences between messaging and events, I disagreed with describing phase 3 of CEP as “towards looking at ‘event clouds’ instead of events one-by-one”.

The glossary notes on the definition of an event cloud says that “CEP usually refers to event processing that assumes an event cloud as input, and thereby can make no assumptions about the arrival order of events”. This implies that events “arrive” – just not necessarily in a defined order such as creation time, etc. It also implies that events may arrive one-by-one. It certainly does not preclude one-by-one processing.

The other implication of Opher’s posting is that the cloud may somehow be processed as a whole. Looking at the definition of a cloud, it is made up of many events of differing types where each event may have been created at a different time, and may have a different time-to-live value within the cloud. But in order to make the entire cloud accessible to an event processing agent as a whole, a mechanism must exist that persists the events within the event cloud and manages the cloud events according to their time-to-live values.

(An easy parallel to this view is “ordinary” data processing where sets of persisted data (i.e. events) are made available for queries. Data/Events are stored in tables and keyed by their time-to-live values. Obviously, given a large enough quantity of events, the storage and processing requirement may be considerable.)

But I disagree that this is the only way to define CEP. Indeed it has long been a fiery debate among the CEP community on how, exactly, an event cloud may be practically processed without creating a partially ordered set of events (which may be regarded as a stream of one-by-one events). I would argue that persisting an entire event cloud is fine for ad-hoc processing and analysis, but that the vast majority of CEP involves detection of predefined patterns and is efficiently performed as a form of one-by-one processing.

In Operational Intelligence, applying CEP to the enterprise event cloud is a practical application whereby predefined patterns are detected and acted-upon in real-time. It would be impractical and practically impossible to persist the entire event cloud as the volumes of events are considerable, and the rate of events would require a lot of expensive equipment to provide the required processing power. Yet Vantify Experience Center uses CEP to process an enterprise’s event cloud, and provides real-time intelligence to operational staff to meet challenges and opportunities for maximum business benefit with relatively inexpensive equipment. The events are processed one-at-a-time rather than as a single cloud for efficiency, and the value to customers has been demonstrated many times. To imply that CEP excludes one-by-one processing is inaccurate and wrong – rather it is an important and critical subset of CEP.

The EPTS Use Case working group met on Monday in Rome before the DEBS 08 conference got underway.  It was hot stuff – temperatures touched 40C or 104F, laptops overheated, but great progress was made.  The new use case template should be available on the EPTS website in about four weeks.  After that, work should begin on trying to produce a reference architecture.  It was great to see Alex from Betfair, an end user of CEP software, with great views and great ideas.   Alex had some great ideas and great views on the benefits of CEP, and it benefits everyone to have real customers describe the value the derive, and the areas they wish to see progress.

The EPTS seems to be achieving some real momentum – no small part in thanks to the tireless Opher who pushes and organises everything behind the scene.  My thanks to Opher and to the DEBS 08 organisers for a great conference, but it reminds me that everybody has a part to play.  Those with an interest in CEP also have a responsibility to be heard and to play a part.

“Ambition should be made of sterner stuff”

Recently WestGlobal went through a rebranding exercise. We wanted to update our image to reflect our product strengths and also to find a new name for our flagship product.

Our product is built on a Complex Event Processing (CEP) engine and we present output to users via real-time dashboards (BAM), so wordplay and variations on a theme around these acronyms were bandied about with abandon.

Finally we settled on Vantify.

One of my suggestions, which I was quite pleased with in a smarty-pants way, was “roofbox”. Now you might think you know what a roofbox is, and may even have used one on your car in the past, but this word also has another meaning which is far more interesting and relevant to the topic in hand.

Here in Ireland there is a Megalithic Passage Tomb at Newgrange, Co. Meath. It is world famous and was built about 3200 BC. It is estimated that the construction of the Passage Tomb at Newgrange would have taken a work force of 300 at least 20 years.

It predates the pyramids by 500 years.

Of particular interest to us is one facet of this magnificent structure. That is, its ability to illuminate a passageway once a year on the winter solstice. To achieve this feat, an ancient device was, and still is, used to capture the rays of the sun. This device is called a roofbox.

This is defined in Wikipedia as follows:

“A roofbox is a specially contrived opening above a doorway, usually built for some astronomical significant event.”

Also interesting is the fact that the term was first coined by an Irishman:

“The term was coined by Professor Michael O’ Kelly’s during his excavation of the Newgrange passage cairn, at Brú Na Bóinne, Ireland.”

So , we at WestGlobal are not the first Irish-based community to try our hand at event processing. We are merely the latest in a very long line of innovative people who used the technology of the time in clever and lasting ways.

If we can achieve even a smidgen of the success and longevity of our illustrious forbearers at Newgrange, we think you will agree that we will have done a good job.

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.