COTS Software Versus (Hard) Coding in EP Applications

November 21, 2007

Opher Etzion has kindly asked me to write a paragraph or two on commercial-off-the-shelf  (COTS) software versus (hard) coding software in event processing applications. 

My thoughts on this topic are similar to my earlier blog musings, Latency Takes a Back Seat to Accuracy in CEP Applications.

If you buy a EP engine (today) because it permits you run some quick-and-dirty (rule-based) analytics against a stream of incoming events, and you can do this quickly without spending considerable software development costs, and the learning curve and implementation curve for the COTS is relatively low, this could be a good business decision, obviously.   Having a software license for an EP engine that permits you to quickly develop and change analytics, variables and parameters on-the-fly is useful. 

On the other hand, the current state of many CEP platforms, and their declarative programming modelling capabilities, is that they focus on If-Then-Else, Event-Condition-Action (ECA), rule-based analytics.  Sophisticated processing requires more functionality that just ECA rules, because most advanced detection-oriented applications are not just ECA solutions.

For many classes of EP applications today, writing code may still be the best way to achieve the results (accuracy, confidence) you are looking for, because CEP software platforms have not yet evolved to plug-and-play analytical platforms, providing a wide range of sophisticated analytics in combination with quality modelling tools for the all business users and their advanced detection requirements.

For this reason, and others which I don’t have time to write about today, I don’t think that we can say blanket statements that “CEP is about using engines versus writing programs or hard coding procedures.”   Event processing, in context to specific business problems, is the “what” and using a CEP/EP modelling tool and execution engine is only one of the possible “hows” in an event processing architecture.  

As we know, CEP/EP engines, and the marketplace for using them, are still evolving and maturing; hence, there are many CEP/EP applications, today, and in the foreseeable future, that require hard coding to meet performance objectives, when performance is measured by actual business-decision results (accuracy). 

Furthermore, as many of our friends point out, if you truely want the fastest, lowest latency possible, you need to be as close to the “metal” as possible, so C and C++ will always be faster than Java byte code running in a sandbox written in C or C++.   

And, as you (Opher) correctly point out, along with most of the end users we talk to, they do not process megaevents per second on a single platform, so this is a marketing red herring.  This brings us back to our discussions on the future of distributed object caching, grid computing and virtualization – so I’ll stop and go out for some fried rice and shrimp, and some cold Singha beer.


Latency Takes a Back Seat to Accuracy in CEP Applications

November 21, 2007

Opher asks, The only motivation to use EP COTS is to cope with high performance requirements” – true or false?.

The answer: True and False.

If high performance is discussed in the context of event processing speed and latency, then it is Absolutely False that speed and latency are the most important performance criteria for event processing applications. 

Detection accuracy (the performance of the detection algorithms for detecting derived events or situations) is the most important criteria, hands down. 

Emerging CEP/EP applications are centered around the concept of detecting (and acting upon) opportunities and threats in real-time.   The most important performance criteria is the confidence in the detection of the derived event, or situation, depending on your EP vocabulary.

For example, one of the most promising areas for CEP/EP applications is fraud detection.   There is a fundamental tradeoff in most, if not all, detection-oriented systems – the tradeoff between false positives and negatives.  The same is also true for cybertrading and other detection-oriented applications. 

If you miss an opportunity or threat, it does not matter how fast you missed it, or how low the latency was in processing, you simply missed it!     In theory, you could process events just below the speed of light –  So what?!  Making mistakes faster than others is not considered to be a superior skill that leads to a higher paying job!  (Well, we all have known quite a few who made a lot of mistakes but were buddy-buddy with the boss, but that is another story for another day!)

Likewise, if you detect a false opportunity or threat, if does not matter if you detected it in nanoseconds, or if the latency was just below the the speed of light.   Detecting false positives does not demonstrate superior performance.

Most, but not all, of the current CEP/EP vendors have relatively simple rules-based detection approaches and many have marketed “low latency” as their core capability.  The fact of the matter, well expressed by Kevin Pleiter, highlighted in Complex Event Processing – Believe the Hype? earlier this week, is that performance is critical, if the definition of performance is “accuracy” and “actionable” detection.  Latency takes a back seat to accuracy – as it should.

Kevin echoed what I have been saying for a number of years in the CEP community.  Detection accuracy that leads to high confidence, actionable business decisions is the most important performance criteria for CEP applications.

So, if we define performance in the context of event processing accuracy and confidence in decision making, then the answer is that is it Absolutely True  that performance is one of  the most important criteria for event processing applications. 

Latency discussions are a distraction, a red herring,  something intended to divert attention from the real problem or matter at hand.