TIBCO’s presentation at BRForum, an event dominated by multiple flavors of “business rule engine” vendors, was not meant to be provocative but simply to explain some of the benefits of Complex Event Processing / event-based views on “business rules” from both the business analysis perspective and the rule execution perspective. However, it also seemed quite timely given the conference analyst presentations expounding the benefits of CEP for business rule processing. It was also timely given the CEP coverage at last week’s ORF, and recent blog postings on the benefits or otherwise of inferencing (/ Rete rule processing).
The basic premise is: for “business rule” declarations, associating the applicable events helps understand how such rules can be enforced. And once those rules are mapped into production rules or decision models, the same event-to-rule mapping makes execution both simpler and easier to update. Lesson over.
Unfortunately, my smugness at presenting this supposed “revelation” for BRForum attendees was short-lived. Later in the conference, consultant Brian Dickinson expounded on how putting “process silos” between “events” and “rules” was nothing more than a bad practice dating from the pre-IT age, when instead we should be modeling event contexts and bypassing the need to store data at “every step”. And later, decision-table guru Prof Jan Vanthienen explained how business process diagrams were nothing more than a visualization of a set of rules – and quite often a redundent onewhen used in business automation cases, where applying rules directly to events was a much more efficient representation…
For a less biased view of the presentation check out Sandy Kemsley and Eric Charpentier‘s blog posts…
This is something that fascinates me. Clearly today’s CEP technologies are complementary to SOA/BPM. SOA/BPM already makes extensive use of rules-based approaches and, as David Luckham constantly points out in TPoE, a event-processing agent is a kind of rules engine. At a higher level, we know we can express any workflow or automated process in terms of ‘rules applied to events’. I have some way to go, though, before properly understanding the impact of real-world CEP technologies on SOA/BPM architecture and design. It should prove an interesting journey.
Oh, by the way, the zip file originally published on the ORF site contained an early draft of one single paper. Chelanie updated this with the final submissions a couple of days ago.
Thanks Charles – your ORF paper on CEP was certainly a highlight and I think you should (a) get a publishing deal for it and (b) present it at some EPTS meeting!
On “When it comes to technology selection, however, … there are many, many more concerns than just the events and the rules” you are absolutely right… on the other hand, none of the concerns you mention exclude the use of CEP technologies (e.g. failover support, security, transformation, long-lived states, management, etc).
The fact that CEP tools might map events closer to required actions and behaviors may simply be a good practice only for *certain* types of applications, for sure. I guess we shall see how these technologies continue to evolve!
Disclosure: TIBCO of course also has BPM and SOA stacks which are complemented by, rather than replaced by, CEP technology. Usually TIBCO CEP is found working alongside tools like TIBCO BW and associated miriad adapters.
Cheers!
I love the self-deprecating ‘for a less biased view’. For my part, I thought you did an excellent job of giving an unbiased and well-balanced perspective at ORF.
In one of the ridiculously long papers I wrote for ORF, I talked about David Luckham’s example in TPoE where he discusses a ProcessOrder process that handles dynamic vendor selection. When I first read that part of the book, my initial reaction was one of disgust. My thinking was along the lines of “if you were going to build an application like that, you wouldn’t use an (ESP) CEP engine”. I design and build automated business process solutions for a living, and have been involved in projects building similar types of process. I use a combination of message brokerage, adaptation services, service orchestration, human workflow, rules, etc., so I claim some authority in that area.
Once I calmed down, I realised that I was probably misinterpreting David’s meaning. He is not talking about technology selection. He is simply describing a business process example from an event-driven perspective and showing how this relates to CEP. In essence, he is saying that the process can be understood in terms of applying rules to events. There may be other concerns, but these are relegated to the ‘IT Layer’.
While I agree that “business process diagrams are nothing more than a visualization of a set of rules”, and that there is no merit in introducing ‘process silos’ (I love it!) unnecessarily, I do have some qualms here. This is all very well when dealing purely with representation and visualisation of business processes. When it comes to technology selection, however, my entire experience has been that there are many, many more concerns than just the events and the rules. There is data and protocol adaptation. There is resilience and message recoverability. There is mediation of many different types. There is traceability between the business and technical implementation. There is handling of performance mismatches and impedances between different parts of the system. There is robust definition of trust boundaries. There is ability to handle long-lived activities. There is the need to manage change, versioning and process improvement cost-effectively, etc., etc., etc. In terms of implementation, ‘process silos’ may in fact reflect the need to address a whole lot of very important issues that go way beyond just events and rules.
In the interests of disclosure, I should point out that I work for a company that makes its money out of expertise in a specific suite of integration and process management tools. For a less biased view….