Next week sees the first 2009 get-together for rule standards developers, with the W3C Rule Interchange Format meeting to continue development of the Production Rule Dialect (among others). RIF PRD aims to provide a common rule representation for things like XML-based Domain Specific Languages (mostly for potential future versions of domain standards like XBRL, MISMO and ACORD, but possibly useful also for IT languages like BPEL).

Of course, production rules are relevant to complex event processing, as well as business rules, hence TIBCO’s interest. The shift here is that, with the recent take-over of Ilog by IBM, and with the meeting being hosted by Oracle, the contributors are nowadays the main infrastructure software players and rivals (TIBCO, IBM, Oracle). This shift does not seem to have been particularly commented on by the analyst community yet…

Other CEP connections to RIF are in the academic community: one of the PRD authors is Prof Paschke of Free University Berlin, a CEP researcher. And a recent comment on W3C RIF by Prof Kowalski at Imperial College London was interesting due to Prof Kowalski’s earlier work in the 1980s (!) on event calculus; the shift here is the feasibility of generalized event processing software brought about by the higher performance computer systems and networks in the intervening decades…

Sometime one has to take what one reads on the web with a liberal pinch of salt. I was amused to read on Intelligent Enterprise in the last few days that:

1. CEP is a “BI Megatrend”
2. CEP is a “marketing device”
3. CEP to be provided by IBM’s latest (rule engine) technology acquisition - presumably either alongside, or replacing, their “Appsoft” (per the article) acquisition… [*1]

The first article is the most interesting: the BI megatrends also of interest to us in complex event processing are:

- BI users demanding richer experiences / exploration of relationships: this is where highly visual tools like TIBCO Spotfire play in historical data analysis, and TIBCO Syndera in operational intelligence…

- Business modeling meets MDM: frankly this is a stretch for traditional BI, but certainly MDM tools like TIBCO CIM have a semantic angle, although this angle is usually downstream of the development of the concept models defined in TIBCO BusinessEvents [*2] or existing operational data source schema. The same semantics affect ETL (per the article), which also cross-links to event processing technologies: one of the use cases for TIBCO BusinessEvents is “intelligent” ETL (a.k.a. event-driven rule-based transformations).

- Breaking the BI/DW Mold: of course there is nothing mouldy about data warehouses! But this is talking about in-memory and other “unconventional” data stores for doing “operational” BI, or operational intelligence. We already see these in the CEP world with high performance event stores as data grids.

- MapReduce meets large scale data analysis: MapReduce is more about highly parallel operations rather than more course-grained event pattern detection. But despite the difference in granularity, both MapReduce and TIBCO BusinessEvents are agent-based distributed systems for collaboratively solving large scale problems…

- Column Oriented databases: this could be a red herring, as these are still static-query-oriented databases. But is the world moving towards continuous queries against real-time event-driven information sources, or even tuple and object stores?

- Event Processing for analytics: this made some sense, although the authors seemed to want to tie event processing to BI and data warehouse systems, rather than the other way round. Surely BI’s role is to identify the event and data patterns for use in operational event-based decisions? So BI should help CEP solutions, not the other way round?

Maybe 2009 will be interesting after all!

Notes:

[1]  Why sell your customers 1 CEP tool when you can sell them 3 or 4?

[2] TIBCO watchers may be interested to note that TIBCO CIM (MDM) and TIBCO BusinessEvents (CEP) are part of the same business unit …

David Luckham started a complexevents.com discussion on what lies in store for CEP in 2009. We won’t re-create that discussion, but instead look at probably the biggest challenge facing CEP: the terminology! There is nothing wrong or odd with businesses having complex (or abstract) events, and requiring detection of said events in a timely fashion with an appropriate reaction; however,  many many applications already do this in some restricted way or other. So what differentiates CEP technologies from, say, automated business processes in BPM or Java?

One way to differentiate CEP technology is through the event-oriented capabilities:

• continuous processing of events
• handling various types of event filters and patterns over type, content and time

Most conventional IT technologies that deal with complex or abstract events usually do so for either specific types of events or event delivery with specific performance bounds. Some of these applications / components / tools will increasingly claim to be “CEP”, too.

To mitigate this, the CEP vendor community, in the guise of something like the EPTS, probably needs to step in with a classification scheme for CEP technologies, providing certain prerequisites for the term CEP over “technologies that can do some aspects of CEP”.