The EBRC (European sibling of US-based Business Rules Forum) was held in Dusseldorf, Germany this year. TIBCO presented the concept of Complex Event Processing to the business rules audience, with the idea of extending the typical business rules audience view of rules (as decision services and business policy/practice/rule management) to what CEP can provide for event-driven businesses. This included the case study of the Union Pacific railroad, using TIBCO BusinessEvents to monitor trackside monitors and data on crewing, yards, available rolling stock and so forth to maximize train speed (and hence efficiency) for the track network. For a third party view of the session, see James Taylor’s blog .
To some extent, the idea of “educating the Business Rules world†on CEP proved pleasantly redundant. Some of the other CEP-related presentations at EBRC included
* the presentation on Business Rules with EDA and SOA expressed the importance of business events for agility, and as a result also covered (naturally) CEP. Noteworthy comments were “business events are the natural triggers for business rules” and “business rules are implicitly related to business events”. This presentation was also noteworthy for the number of new acronyms the authors tried to invent: BRA (for Business Rules Architecture), CEPA (for Complex Event Processing Agent), and BECO (for Business Event based Coordination)!!!
* a .NET based “multi channel retail†application used by Tesco stores in the UK was presented; real-time multi-channel consumer marketing is a good application for CEP, although I suspect this particular application is either batch or DB oriented, rather than event driven.
* the application of a remote (bluetooth) heart sensor, Java-enabled mobile phone, and rule engine technology to ensure best-available customized diagnostics in real-time for heart-risk patients was the winner of the “best application” in my mind. The sensor/phone combination reads the heart data rate and does some initial analysis before deciding whether to transmit data on to a diagnostic centre, or calls a health professional. Hardware is off the shelf except for the Bluetooth heart sensor. I term this more Event Stream Processing because only a single event stream is monitored – the heart rate. Although the inventors plan to add an accelerometer (to detect when the patient falls over!), it will require a few more sensors and correlation rules before it can properly be described as “complex” event processing. Regardless, its a smart application of off-the-shelf technology and it has plenty of use cases (emergency services or military personnel monitoring in the field, for example).
* the Northern California Power Agency (NCPA) described their use of business rules in an SOA environment for billing – real time, but “hourly†type events instead of millions per hour. This was interesting because of its similarity to project at California ISO, where power supply and demand was monitored and billing managed against power contracts described as sets of rules and against all sources across the network. This rigor was implemented as a direct result of the Enron-manipulated California brown-outs a few years back, and allowed California ISO to enforce its contracts and police its suppliers in real time. Energy supply and demand monitoring against a fixed set of physical resources (such as the electricity grid) is certainly a CEP application area, and is similar in that respect to the Union Pacific case study mentioned above.
So over 10% of the material at EBRC was “CEP relatedâ€, and there were probably other presentations that I missed in my review that could have benefited from real-time identification of business events and scenarios for downstream business rule processing. 10% is not at all bad considering the wide range of rule-related topics that EBRC covers!
