With the recent news that one of the 2 main pure-play BRMS vendors has got itself acquired, it might be a good idea to catch up [*1] on the differences between Business Rule Engine (BRE) and Business Rule Management System (BRMS) software components with their equivalents used in Complex Event Processing:
Business rules vs Decisions
If you compare, for example, the Business Rules Group definition of “business rule” [*2] with the types of rules we automate in CEP or BRMS tools, you find that the former mostly equates to constraints on the business, and the latter are types of behavior (as in: IT process implement behaviors, or decisions). BRMS tools manage decision-type rules that are in turn derived from “business rules for business people” (or “source rules”). The different philosophies are apparent in the 2 OMG standards, SBVR (covering business constraints) and PRR (for system behavior) [*3].
A Complex Event Processing system usually defines business rules as declarative decisions (in, for example, a rule-driven CEP system), or maps the rules to flows or procedural language constructs. Sometimes a CEP system just defines facts (such as a continuous query indicating some interesting complex event), or presents the complex events (such as in a dashboard) to support some manual decision-making process.
Business rules relate to Events
Quoting from Ron Ross’ book [*4]: “Processes connect to rules via events … which can fire one or more rules”.
Quoting from Dave McComb‘s book [*5]: “A more likely successor [to explicitly called rule engines] will be a business rules engine that operates on message traffic. ”
So these experts (in the related fields of business rules and semantics) seem to agree on the close connection between business rules and events: a corollory is that moving business rule definitions (and management thereof) closer to the source event would be “A Good Thing”. Until recently there has been no mention from the BRMS vendors of the Complex Event Processing space; the only BRMS vendor comment so far seems to provide a somewhat defensive response by implying that BRMS are for rich rulesets and CEP is for fast events. In the enterprise world, of course, you often need both rich rulesets and fast event handling. “Rule management” is as much required for the low-latency rules as for the high-latency workflow / BPM rules (as usually served by the BRMS vendors). Combining the 2 is clearly going to be an interesting evolution, already started with the TIBCO BusinessEvents rule-driven CEP product.
BRMS standards?
One interesting caveat to the propagation of rule management to Complex Event Processing, is the lack of appropriate standards at the rule management level. You can use SBVR to specify business constraints, and derive the likely events from the term and fact model (such as new car rental agreement, new customer, rental car return, etc). But you also need to map them to appropriate processes. For the most part, customers are delighted enough with the agility they get from rule management without demanding cross-vendor standards. Yet. But standards are often (as commented at a recent event) a prerequisite for federal etc adoption.
BRE Performance
… is, like in the Complex Event Processing field, a somewhat “hot topic” among certain Business Rules Approach fans. Although the vendors in this space tend to be quite relaxed on this – performance is almost always “sufficient”. And this is true, as far as rule engine performance goes. The main problem for the BRE vendors is that they get blamed for transaction performance, when the fault really lies in the data marshalling needs and the app server: there is not much point in shaving 10% off your rule transaction time of 40ms, if you are reliant on a database transaction which costs 400ms. This is where CEP-based rule execution can be surprisingly effective over traditional BRE approaches, as CEP systems generally avoid database transaction costs.
Notes:
[1] See earlier posts on this topic: Differences between a BRE and a rule-driven CEP engine (part 1) and (part 2).
[2] “A business rule is guidance that there is an obligation concerning conduct, action, practice, or procedure within a particular activity or sphere.”
[3] Both SBVR and PRR rules are “representations” of business logic – so both can claim to define “business rules”, although naturally SBVR notations are meant to be more “business friendly”. Usually PRR is used to explicitly define “decisions” including event-based decisions and rules.
[4] See Business Rules Concepts, 2nd Edition (thats the one with the green cover – google books only has the old version), Ch2, pp34. Note that in Ron’s view, you apply events to business (constraint) rules which in turn can generate events to indicate violations. Such as the rule “each customer has 1 and only 1 account manager”, which is applied to events such as newCustomer, deletedAccountManager, setCustomerAccountManager, and can generate appropriate exceptions when the constraint is not satisified.
[5] See Semantics in Business Systems, AppA, pp297.
