… by which of course I really mean goal-directed event-driven rule processing…
One of the more common analyst questionnaire / RFP questions one comes across is “does your rule engine do “backward chaining“. From a business perspective, of course, this tends to be a vendor checklist item, as quite often the analyst / customer will have little idea as to when or why they might at all be interested in doing backward-chaining (and indeed, why should they?). And the usual vendor response is “yes”, because even if your engine is forward chaining, you can always invoke a PROLOG program to do a bit of backwardness if you really want to, or chain some event rules together to do the same thing. And you rarely want to resort to this in real projects [*1].
Of course, the main rationale for “backward chaining” is to do goal-directed reasoning. And the reason why one processes events / executes business rules, is to achieve some goal: in CEP terms these might be:
- situation assessment: the goal is to have some stable or known state
- sense and respond: the goal is to invoke some response action when some known state is reached
- track and trace: the goal is to know the state of any entity at any time
.
Here we can see that we are processing intermediate business goals (as opposed to business policies and strategies, per the OMG Business Motivation Model, although one could certainly consider using CEP for that level of BAM). We also see that a “goal” is really a “state” (or maybe set of states), and that state modeling (where you define your goal state, start state, intermediate states, and appropriate state transition rules) is a very good way to define what this goal is (and how you get there) [*2].
Notes:
[1] Which is why backward chaining was dropped from the OMG Production Rule Representation standard - lack of vendor interest.
[2] Which is why state modeling is included in TIBCO BusinessEvents.
