WIRED magazine ran an article in the January edition titled “The AI Revolution is On”. This covered:

• automated warehouse control systems - think RFID, optimised storage and logistics, etc
• railway management - think resource management
• automated trading - algorithm trading and event stream processing

All of these are also event-driven applications, deducing complex events:

• orders for warehouse contents affect stock levels and rates of change in stock will impact ordering and production processes
  (complex event = new stock order required, etc)
• transport events affect situation awareness which affects planning of staff and railway rolling stock
  (complex event = train delay due to staffing unavailable, etc)
• see ALL the capital markets use cases for event stream processing engines!
  (complex event = stock A price at time t1 is < f(A,t2), etc)

So, is CEP the new “soft AI” (i.e. AI that works)?

Interesting to see that the Applied Artificial Intelligence Journal is calling for papers for a special issue (November 2011) on what they term “event recognition”. Being academic and about another “field” of computer science, they can’t possibly refer to the term “complex event processing”, but instead talk about:

• …events are particularly important pieces of knowledge, as they represent activities of special significance…
• …consider… the recognition of attacks on nodes of a computer network… the recognition of suspicious trader behaviour… and the recognition of cardiac arrhythmia…

For sure, a “recognised event” is going to (usually) be a “complex event” and (usually) “indicate” (rather than represent) some activity. And I would concur with some people’s opinion that the term “Event Recognition Systems” would appear to be a far more marketable name than “Complex Event Processing” … its maybe a shame the AI folks didn’t push to use that term earlier!

If interested, submissions are due Dec 1, 2010.

In a previous post we commented on IBM’s Conceptual Model for Event Processing Systems, but failed to observe that IBM’s rule engine group, Ilog, was noticably absent from its contributor list. So perhaps it was both fortuitous and timely that Ilog’s Daniel Selman recently added another “viewpoint” on the position of event processing (aka the rules viewpoint).

Daniel’s take on the “primary users (sic) of rules technology” are the (use cases for) automating decisions, event responses, processes and inferences. I think these might be better classified by renaming then as decision processing, event processing, and business process processing. But inferencing, which Daniel notes as being a technology to support Artificial Intelligence, is not so much a (user or) use case, but a means of providing knowledge-based reasoning to support any of decisions, processes, etc - “AI” is not (or should not be) a means unto itself.

Standard Event Processing Design Pattern

Indeed, one could probably argue that:

• all business processes are driven by events of some kind, and involve decisions and (re)actions;
• all processes, decisions and event processing are context (i.e. state) driven; however, some processes and algorithms are used in a subordinate fashion to a stateful process (consider a typical decision service that is subordinate to its application server and database layers);
• inferencing can be used to enhance any part of the event-handling process as a form of declarative rule control.

In TIBCO’s experience, an event driven rule engine (like TIBCO BusinessEvents) can be used to provide dynamic business processes, event-driven decisions, and real-time control mechanisms - and often all 3 - exploiting and building on the fundamentals of complex event processing.

So, on the utility of rule engines, we totally agree with Daniel!

Jacob Feldman from 4C presented to OMG this week on the need for standardization in the Constraint Programming (CP) community. Although you can (and often do) represent business contraints in business rules and CEP systems (for example, you can argue that any rule condition is a constraint, or a value range in a decision table is a constraint), CP usually uses special techniques to solve complex business optimization problems that require juggling / relaxing these constraints to find an optimal or near-optimal “solution”. Examples might be aircraft load planning, bus schedules, and delivery vehicle routing. CP solutions to these problems also intersect with the CEP space, as plans are disrupted by events (such as an aircraft flight diversion due to turbulence, an event requiring more bus capacity, and a delivery vehicle breakdown). Sometimes such constraint systems are implemented using production rules, too.

With respect to rule model standards, OMG PRR has defined a baseline “rule behavior” definition, and OMG UML already has object constraints in OCL. It will be interesting to see if standardizing the metamodel for CP problems and engines will exploit or work with these, and how future CP systems will be used with CEP systems.

… was the catchy snappy hip punchy title of our contribution to this year’s BPM(I) (aka OMG) Think Tank 2008’s RoundTable sessions. These are used to get feedback from end-users, consultants and indeed other vendors on a variety of issues - which in this case was the role of Complex Event Processing and business events in BPM (aka BPMN models).

For a warm-up, Jim Sinur (Gartner) gave a keynote covering “The Economics of Business Process”, explaining that businesses should expect to invest in BPM in a down-economy as they have even more to gain than in an up-economy. More to the point, he expanded on the need to augment conventional BPM with things like decision management, rule-driven processes, complex event processing, and maybe even “scenario management” (which could mean any of case management, case-based reasoning, or test case generation - it wasn’t clear). In particular Jim mentioned:

• the role of complex events combined with AI techniques to improve decisions
• rules will need to “surround” process, not just be invoked from decision tasks

Jim was a good segue into the CEP-BPMS roundtable, whose participants included a large insurance company, a DOD supplier, a government agency, the co-creator of the BPMN modeling standard, and some curious fellow (BPM and EA) vendors.

Firstly, and not surprisingly, none of the participants disputed the value of CEP to business processes.  There were a few different areas of CEP-BPM focus that were discussed:

• CEP providing a generic business-logic container for cross-process / cross-BPMS / cross-abstraction-level, system+process monitoring (a bit like TIBCO SPM provides, but more general)
• CEP was another reason for standardizing the enterprise view of events and event patterns alongside processes - as BPMN events provide a very process / task-oriented view of an event, which may have a totally different meaning in some other process (see also the OMG EMP effort for event metamodels, which hopefully EPTS will have an input to)
• Agility was provided by the CEP elements (like state models, declarative inference rules) being “easier to maintain” than (some) large process flows, as well as the fact that event-driven decisions are more useful in real-time scenarios where high responsiveness is required
• The use of rules, queries, states, alongside or augmenting process flows overlaps with “knowledge representation / management” (which is an interesting thought)
• CEP also had a BAM-type role to play in business process control and oversight: one participant used the terms “issue prevention, detection and correction”, which is a neat description.

The slides for the session (roundtable intro and feedback) are available in the file BPMI_EPandPRoundtableResults1008.pdf .