Lee Lambert of New Wisdom Software presented on his RuleGuide product (see my first look on RuleGuide) to the group considering a Decision Modeling Notation for the Object Management Group. Lee initially focused on the typical complexity that comes when working with Business Process Management and Business Rules Management. Most projects started with a large rule harvesting effort – looking at legacy code, interviewing experts etc – that created thousands of rules that were managed in spreadsheets that in turn were turned into executable rules. Lots of manual linkages, lots of rules, lots of change management issues – even if you use the Decision Model or some other more structured process for rule capture.
Focusing on decisions, however, made a cleaner distinction between process and rules. Add in automation of rule and decision management and the process of connecting rule sources to the production becomes much simpler. This led to the core of his presentation on RuleGuide and its three levels of separation:
- Decisions – business context that defines a framework for logic
- Rule Families – business logic presented in reusable rule sets
- Values – variables maintained in value tables
Today they use IBM BlueWorks for managing business process and then use the KPI Decision Model and rule families (along with value tables and a glossary) as implemented in RuleGuide for managing logic. He gave an example of a healthcare decision – a pharmacy that needs to decide if a clinical evaluation is required before the prescription is dispensed. The problem requires information about new allergies and medical conditions (3 rules) plus 236 questions that are specific to about 40 products. This looked like 472 rules would be required as there were 472 combinations of conditions in the questions. But by keeping the values for variables in external tables they were able to reduce this to just 5 rules – treating the rules as a template into which values can be plugged.
