New name and face-lifting to David Luckham's site: complex event processing & real time intelligence

In this picture, taken seven years go, you can see me (somewhat heavier than I am today) with David Luckham (in the middle) and Roy Schulte (in the right hand side).  I have talked with David Luckham recently and found out that he is still maintaining his website, and now also face-lifting it.   On the website he also explains why he has changed the name.   According to Luckham, the name "complex event processing" is strongly identified with the event processing platforms, dedicated software to do event processing,  but this is a tiny fraction of the market, where the bigger market is embedded event processing inside other software.  This observation has been done before by various people (including myself), so I believe he is right. Luckham calls the bigger game as "real time intelligence", some people call it "real time analytics", but  there is an agreement that it is part of the big data game (and other games) and that event processing is in its backbone.   It will be interesting to see if such branding will catch on, and how exactly "real time intelligence/analytics" will be defined -- I'll write more about it.  

Taking the complex out of complex event processing

The quote of this week is taken from an article in InformationAge that talks about operational intelligence. 

The article explains what operational intelligence means, and you can read it to see if you find anything new.

The point of this post is a quote done by Ivan Casanova from TIBCO:  

“We should all be focused on taking the 'complex' out of complex event processing" 

This quote is in the context of explaining the acquisition of Streambase by TIBCO.    I don't know Mr. Casanova personally, but what I have learned from his statement is that he believes that going forward, the programming model and tools represented by Streambase are better fit and less complex to use that TIBCO has done before, where it extended RETE based business rules system to handle stateful event processing cases, while retaining the rule-based programming model.    Streambase is using an "event flow" model that is some variation of event processing network.    Without getting to analysis of specific products (a restriction I have taken upon myself in this Blog), I would say that overall I believe that as a conceptual model for event processing I believe in the EPN model (which is of the family of data flow models),  and in visual working environment (better than textual working environments) to design and program.   This reduces the complexity for IT developers, which I think is very important trend.   The ultimate reduction of complexity requires one more step -  event processing modeling in the level of the business user level and automatic translation to an implementation language.  

Bottom line: I agree with the statement in the quote -- actually this is my main area of interest nowadays. 

On continuous compliance

The Waters special report sponsored by Apama that was published recently,  ranked "risk and compliance" as the number one application of event processing in financial institutions.   Today TIBCO also published in its Blog under the "event processing" category its view on compliance - entitled: "The Y in comply".   It gives the view that people comply better when they understand the rationale of compliance, the example given is compliance with regulation in the food industry that employee has to wash hands before putting on gloves.  

I agree that people comply better when they think that the regulation makes sense,  however, my own subjective impression is that in the current culture, compliance became goal of its own whose sole reason as somebody described it "to get the regulator off my back".   Thus employees are required to do things that they don't see any reasonable explanation why they should do it, and IT systems check that they are doing it. Here, event processing is used  since in various cases auditing is event-driven, it is time sensitive an often involves calculation in time windows, and in some cases online auditing on the fly is required. The business value sometimes is just pleasing regulators, but this is often a great motivation for managements to take it very seriously...   Anyway, technologies are used for strange reasons sometimes...

Call for papers: special issue of ACM Transaction on Internet Technology on "event recognition"

ACM Transactions on Internet Technology issued a call for papers for a special issue on "event recognition".  In the CFP they explain that "event recognition" mean "event pattern matching".  This is an opportunity to report on interesting research work in that area, with a relatively short review and publication cycles.

On the OODA loop and the 4D

Richard Veryard asked in a comment to my post on  the recent tutorial given by Jeff Adkins and myself if our 4D scheme (which was introduced by Jeff)  is related to the famous OODA loop.  I have mentioned the OODA loop in the past in connection with the need to act faster than the speed of thinking. the strategy of air combats, later he also made claims about the generality of this method.    The 4D is certainly from the same family, and the four stages are indeed similar.   Interestingly Boyd's had event-driven thinking.    

The OODA loop was aimed to describe event-driven decision by a human - the human has to observe that an event happened, perform mental self orientation to analyze the meaning and implication of the event,  decide what to do, and act accordingly, have feedback loop to see whether the observation has changed.

The 4D describes a computational process, where the event is detected (not necessarily directly observed),  situation is derived (by computational means and not by mental process), and then a decision is taken (autonomic or manual) and an action is performed.   

The mapping is not 1-1:    

detect is always mapped to observe;

derive can be mapped to observe - as the detected situation is a derived event, and sometimes to orient - as it may derive a conclusion.

decide can be mapped to the combination of orient and decide in the OODA loop

do seems to be always mapped to act. 

More thoughts about the 4D and related stuff - later.  

Waters special report on CEP (sponsored by Apama)

Waters published a special report sponsored by Apama (in transition from Progress Software to Software AG),   I wanted to copy one of their figures, but they had "no copy" notice, thus I've posted some cool picture of water instead.   

The report views the Apama view on the event processing use in financial markets and include some articles contributed by the Apama guys, and some articles by financial market people.   It is interesting to note their audience polls.  They don't specify exactly who the audience is, but they probably refer to financial market  organizations.    

Some highlights:

14.9% of the organizations are using single CEP platform,  25.5% prefer to use their own solutions, and 44.7% use mix of their own code and platforms.     I guess that in other industries the percent is somewhat lower both in use of event processing and in use of COTS products. 

Risk and compliance became the major reason to use real-time analytics based on event processing, while the front office trading is second.  We see risk and compliance taking its place as a major type of event processing application with the move to continuous applications.   

Performance is again the major criterion for event processing (with the "big data" trend) and ease of development is second.   

On actions and success criteria in event processing

I am now in Durham, North Carolina, the second stop in the USA business trip (that included 4th of July dinner with friends).   A reflection on one of the DEBS 2013 presentation given by Steffen Hausmann, a PhD student supervised by Francois Bry about "complex actions".   The model built specifies an action model for event processing.  The interesting insight is that unlike traditional systems where the success is determined by the successful completion of a task, event processing systems are goal-driven, an action goal is a reaction to some situation, and is intended to satisfy some goal with respect to this situation, for example: resolve a problem.   Thus in the presented model each action has success criterion that determines whether the action satisfied the goal.    In the presentation this criterion is an event, typically emitted by a sensor, but this can be generalized to a more comprehensive model.   The idea to define success criteria for actions as part of event processing system is very useful, and in a sense closes the loop of sense and respond.