Christian de Sainte Marie from the ILOG group at IBM presented to the OMG Decision Model Notation day on the role of decisions in the ILOG Business Rules Management System. Christian started by describing a BRMS (see my brief on what is a BRMS) and the ILOG BRMS in particular. He drilled down a little into rulesets – stand-alone executable containers for a set of rules that can represent a decision and be deployed as a decision service or can be part of a decision (see this post on decisions, rulesets and rules and how they relate). Obviously these rules must act against business objects – fact types – and like most BRMS the IBM environment takes technical object models (database designs, XML structures, Java objects) and presents them as a business friendly object/fact model by layering a vocabulary on top. Christian also made the point that the use of an underlying conceptual model that can be shared is critical for modeling and sharing.
The ILOG BRMS supports a number of metaphors to describe rulesets – decision tables and decision trees for example. Their use of decision tables is just as Jan described in this presentation and decision trees are used where segmentation or sharing of common conditions are important. At the end of the day, both metaphors execute as a set of business rules – a ruleset. Essentially the metaphors describe the structure of the rules and the data in the decision table, for instance, is combined with this structure to create a set of executable rules. With IBM’s acquisition of SPSS the integration of predictive analytics with business rules has moved on with models being imported as decision trees using PMML. Finally of course many decisions require multiple rulesets and so ILOG like other BRMS supports the notion of a ruleflow – perhaps better described as a decision flow. These looks like simple processes but are limited to basic flow concepts (a small subset of BPMN for instance). A step might be a simple ruleset but it might also be multiple packages of business rules with pre-conditions etc.
In general the use of a BRMS is different from decision modeling – it tends to be bottom up (assembling rulesets into a decision for deployment as a decision service) and much more technical (specifying execution styles etc). It is also true that there are non-declarative elements of business decisions.
Christian wrapped up by saying that business rule application design and decision modeling are complementary but not the same – that they are orthogonal to some degree. To be interoperable, to work well together, they need to share vocabulary and the “process” of decision making must be manageable as well as the rules.
