I have been thinking about the response I got from David Campbell to my posting on his CEP article. In his comment David discussed the difference between using a business rules engine in CEP (Complex Event Processing) and using business rules more generally. He says that CEP uses business rules, but not business rule engines because BREs are "best suited to problems where the process steps are linear and predictable and don’t require contextual information about timing and sequence of event patterns "and goes on to say that "The reason for this is that most rules engines today require all of the data used in the rules, including the contextual data involving timing and sequence arrays, to be built in advance and stored in a database". He goes on to say that CEP solutions maintain this contextual information with the event messages to simplify this problem.
Now, while I don't think the statement about databases and BREs is 100% true (many rules engines allow for call outs to gather additional information as needed by rules while they are executing and allow for this data to come from other components or services, not just databases), it seems to me that this is similar to the arguments about keeping rules in a BRMS/BRE or in a BPMS and about the role of rules inBusiness Activity Monitoring also.
I believe that each of these specialized contexts - business process management, event processing, activity monitoring - can take advantage of a rules-based approach with the technology primarily responsible for it - BPMS, CEP or BAM software - but that this is not the same as using a rules approach to automate business decisions. Nor does using rules for routing, activity monitoring or event processing in anyway replace using business rules for decisioning. Why not? Two reasons - reuse and synchronization.
First reuse. By embedding rules in a CEP/BPMS/BAM solution I make it impossible to reuse those rules across the other members of this family of solutions and across my legacy applications. Rules for what makes a good customer, a fraudulent claim or the right next best action in marketing terms are the same across the enterprise and should be managed as the enterprise asset they are. Managing these decisions this way also allows me to invest in improving them, analytically for instance, while maximizing the return. There are rules that belong in each environment, but the core rules for decisions should not.
Secondly synchronization. Rules for routing and handling processes are synchronized with the process definition in the same way that rules for event handling are synchronized with the event definition. Rules for making business decisions within these processes or as a result of identifying an event are not. It is essential you don't over-synchronize business decisions and processes or business decisions and event identification. I must be able to change the way my business responds to an event separately from how it processes and identifies the event. Similarly I must be able to change how I manage a decision without having to change the process(es) that include it.
I am glad to see that CRM vendors, BPM vendors, CEP vendors and more are seeing the value of the business rules approach to managing business logic. The fact that these applications can and should have business rules in them does not replace the use of a business rules management system to manage core operational business decisions across the enterprise.