Applying the "Two Types of EP" to recent blog posts

To help illustrate my discussion of Two Types of Event Processing, I will analyze two recent blog posts.

First blog post: an EP application

Take a look at the post So, What is This CEP Good For? by Marco Seiriö of ruleCore. Among other things, this post illustrates an awesome looking Event Processing application called FleetNotice.

At first glance, it may not be obvious how FleetNotice breaks down between Detection Oriented and Operations Oriented Event Processing. Hopefully I am about to shed some light.

FleetNotice receives events that show the periodic global position of couriers, as they navigate Manhattan. One assumes that the events come from cell phone GPS monitoring. As Marco explains: when you have hundreds of such moving objects, it is simply not practical for a person to watch them all.

So Marco has developed a system for watching all this moving data and trigger business actions using rules. To quote his example rule:

Alert me if Couriers Ben, Jerry and Mr Smith diverts from their designated route for more than five minutes and they take more than 20 minutes between the waypoints (40 minutes is ok if it’s between 4pm and 6pm on fridays, except last friday of month), but only on working days. Also alert me if the courier does not arrive before 6pm to it’s destination and alert me also if he does not leave the starting point before 1pm

From this rule, we can see evidence of both Detection Oriented and Operations Oriented Event Processing. But it may be surprising to learn that the rule statement itself is purely Operations Oriented Event Processing. The Detection Oriented Event Processing is hidden under the covers. This is a common scenario for a mix between Detection Oriented and Operations Oriented Event Processing.

The above rule statement is Operations Oriented because it takes in events with clear business meaning such as “courier diverts from their designated route for more than five minutes” and “courier takes more than 20 minutes between waypoints” and “courier does not arrive before 6pm”.

The focus of this rule is not on analyzing data to produce these informational events. The focus is on using these well-defined events to trigger some business activity: an alert.

So maybe now it is clear where the Detection Oriented Event Processing is hiding. It is logic developed by Marco (and/or his team) to take in a bunch of GPS signals and convert them to events like “courier diverts from their designated route for more than five minutes”.

Here are two brief points about why the distinction between Detection Oriented and Operations Oriented matters. There is a lot more to say on this topic, which I may get to in the future.

First of all, in this case the Detection Oriented and Operations Oriented Event Processing are developed by different groups. The Detection Oriented Event Processing is under the covers and developed by Marco. The Operations Oriented logic is developed by the business user (or business IT person). When Marco developed the Detection Oriented logic, he had some idea of how it would be used, but was not aware of every possible business scenario. When the end-user develops the rules, they could not care less about how the data is processed, they specify rules using business-level events.

If there is a bug in the Detection Oriented logic, the result will be an incorrectly detected business situation or activity.

If there is a bug in the Operations Oriented logic, the result will be that the wrong business situation or activity was referenced or the wrong business response was triggered.

Second, the Detection Oriented logic handles more complex edge or outlier cases than the Operations Oriented logic. The Operations Oriented Event Processing handles events that follow a nice contract. You will only get an event signalling “courier does not arrive before 6pm” under very specific conditions, which have direct meaning to the business. In contrast, the Detection Oriented Event Processing gets events that follow a much looser contract (the couriers may do what they are supposed to, but they may not). The Detection Oriented logic imposes a higher level of understanding and order on this chaotic set of GPS events.

Second blog post: a high level description of EP

Now take a look at 9 Predictions for the Future of Event Processing by Mark Palmer of StreamBase. This post is at a higher level, so to speak, than the post above. Meaning that it doesn’t go into technology specifics, but sticks to the broad concepts. Now StreamBase recently won very prestigious recognition as a technology pioneer. Since Mark is the CEO, we can be sure that Mark is very good at communicating the value of Event Processing.

Analyzing only the middle section of this post, titled What’s the problem? Why event processing? What is event processing? we see a very eloquent description of Detection Oriented Event Processing. Mark describes high-speed data analysis, which pulls relevant information (some might call knowledge) from a mass of moving data.

Do notice the contrast between Mark’s description and Operations Oriented Event Processing. Mark does not talk about what gets done with this information once it is detected. The eventual business activities that are triggered by this kind of high-speed data analysis – is the domain of Operations Oriented Event Processing.

Of course, it should go without saying that Mark is a pioneer in Event Processing and is fully aware of all of its aspects. This post clearly articulates the Detection Oriented aspect, and he’s written more than enough about the Operations Oriented aspect in the past.

About these ads