Links - Business Rules Management
Oct 8 2009: I've neglected the subject but there seems to be growing interest in business rules management.
James Taylor wrote an short article about business rule management ( BRM ) a few days ago, Business Rules Management – the misunderstood partner to process.
He says some interesting things about rules management. His comments are interesting in themselves but more so because they are so rarely stated.
Business Rules as Distinct from Implementations of Rules
Rules can appear in various places in the architecture, the UI ( User Interface ), in the middle layer for logic or in the database, for instance. While these may be implementations of business rules, none of them are business rules in a precise sense. In BRM sense of the term, rules are something managed in a repository like business requirements that may or may not have anything to do with computers or code.
As a side issue ( #1 ), there is a school of thought that says business rules are not business requirements; I'm not convinced of that. It eludes me how a business rule like "all orders must be shipped within 24 hours" is not a type of business requirement. Moving on ...
BRM and Technology
James Taylor says that "BRM is more than technology Though it works better with some [technology], especially with a repository for rule management that supports rule meta-data like name, purpose, usage etc."
While it is true that BRM is more than technology, some sort of automated system is required in any real world situation. All rule base examples succeed in business rule seminars. Few real world systems succeed without either active rule management or else an exceptionally competent rule analyst at the core of the project to keep things straight. Otherwise, the rule base will be too complex to manage, particularly in maintaining visibility and "traceability" of business rules to perhaps several hundred policies and process models.
As a side issue ( #2 ), I happen to know that Taylor has written extensively on the subject of "truth maintenance" on other articles, so he understands the importance of tools and technology as well as anyone, but I think that the article glosses over the issue a bit ... he probably didn't want to scare them away. :-)
BRM Technolgy Is Immature ?
He also says that "in the context of BPM [ Business Process Modeling] , BRM is still immature". I've used business rules tools integrated with Rational Rose and other BPM tools and they work pretty well. Intriguingly, he says "the dedicated use of BREs (Business Rule Engines) is further along" - in other words, he is talking about using an inference engine and 'meta-rules' to maintain the integrity of relationships between hundreds of business rules.
For instance, two business rules might over-specify a single value, such as "IF number of products ordered > 10 THEN discount = 10%" and "IF number of products ordered > 20 THEN discount = 20%". To the human reader, the intention is obvious, but as stated, the discount for an order of 21 products could be both 10% and 20% at the same time. This would be an obvious conflict in a managed rule environment but maybe not so obvious in a paper system with several hundred rules.
In the insurance industry, it is common to have different subsets of rules that apply only in certain states, with majority of the other rules shared across all states. This creates exponentially increasing complexity in the rule base and is extremely difficult to manage without a BRM tool of some sort.
As an alternative to the daunting task of embedding a rule engine within a BPM tool, it is possible to implement a simulation of business rules in a repository by exporting the rule definitions to an 'expert system' type of engine and then validating the rules with the inference engine. Typically, an export feature takes a few days to a few weeks to implement.
Types of BRM Technology
Taylor identifies three types of business rule technology:
- BPMS. Some BPMS contain a rule engine and these are typically good for branching, routing and simple event rules
- Inferencing BRE. Traditional rules engine that fires rules based on terms and facts either forward or backward chaining (goal seeking).
- Event-based BRE. Strength in correlating and acting on events, good integration with event listeners.
Recently, there has been a spate of debates about rules engine pros and cons that seem to just go round and round in a self-referential loop. He may have had these debates in mind when he wrote the article.
While his definitions are adequate for most uses, I think there are six types of rule engine ( or inferencing scenarios requiring distinct types of rule engine ). These correspond to the six mapping modes of the Function-Structure-Behavior ( FSB ) model outlined in the E-Z Framework, albeit not very clearly.
Most business applications, particularly in the context of business processes, concern themselves with generating behaviors - that is F->|S|->B or S->|F|->B mappings ( the vertical bar means for a given or fixed structure or function. Most are S->|F|->B mappings, the function F being a fixed business function such "validate customer order" and the structure S being a customer order - in other words, the rules are firing processes ( behaviors ) in order to validate a customer order.
An example of where a F->|S|->B mapping might be used is in plan generation, that is what processes do I need to fire off in order to validate this customer order ? This is a much more sophisticated problem, perhaps requiring a forward-chaining engine. There might also be multiple answers for how to process a customer order ( for example if the customer gets a store credit card today, they can get an additional 10% discount on their purchases ).
The mapping for the BRM rule base "meta-rule engine" is a S->|B|->F, where S is the structural description of the rule base and B is the given behavior, that is checking the logically consistency of the rule base. This is a constraint propagation type of problem and can be very difficult to implement without a full-featured inference engine. It can be faked into a backward chaining problem by using a "for all rules" type of query, but validating every rule against every other rule can be monumentally slow and inefficient for a large number of rules.
Springtime for BRM ?
In any case, it is good to find that some one authoritative is talking about business rules management again. There was a little fad for BRM about 10 years ago that seems to have degenerated into debates about who has the 'best' rule engine, is C++ better than Java, etc .etc.
Companies that take the jump into BRM can realize tremendous dollar benefits without changing a line of code in their business applications.