My last posting (“Transitioning to a World of Decisions”) began presenting observations of decision modeling, implementation and management as they have moved from theory to practice. These observations have been made from both the Business and IT sides of the Enterprise. Although the sample size is still relatively small, some definite trends are beginning to take shape. While the previous article focused primarily on testing, I also alluded to some difficulties arising from a strict reliance on using decision tables for ALL rules. I have observed this on several projects.
As we all know, nearly all major business rule management system (BRMS) platforms have provided a variety of means to express business rules to business users. These metaphors for expression have grown more sophisticated over the years and include IF/THEN rules in a friendly language, decision tables, decision trees, workflows, etc. Selecting an expression form has typically focused on using the format that most closely resembles the logic business users see in their everyday work. This facilitates the transition from source to rule and (hopefully) the ultimate ownership of the rule by business. In some cases performance (and other non-functional requirements) might dictate one choice over another. However, the bottom line is that there has never been a need to force a single representation format or assume a “one size fits all” expression. Operating in this fashion can result in producing rules that seem foreign to business users, an explosion in the total number of rules needed to satisfy a business requirement, and possibly result in performance issues. To that end, we have always attempted to create guidelines for rule expression – something that should ultimately come out of an Enterprise Center of Excellence or as part of best practices – to ensure consistent and practical application of an approach.
The emerging Decision Model and Notation (DMN) standard from OMG represents an attempt to provide a common notation understandable by business and technical users alike. It’s one of the most exciting things to come across our industry in quite some time and, I believe, it forms the basis of how we’ll all be operating in the years to come. It provides a separation and connection of decisions in a business process with a delineation of everything necessary for the decision to be represented and eventually executed. Making the decision (for now we focus on those implemented via business rules) operational is key. Thus far we’ve seen decision tables mostly mentioned for this particular task.
As we noted earlier, real world operational decisions are rife with logic that is often unclear and best addressed with a variety of decisioning artifacts and procedural steps. This is why BRMS platforms have provided a variety of ways to express rules – there has always been a strong belief that because of the usual uncertain nature of business logic, the optimal approach is to use a mix of rule expressions. I am aware that those who have developed decision analysis methodologies based on DMN will claim their approach eliminates that uncertainty and provides a cleaner logic in the decision. While this may be the case, that resulting reliance on decision tables still carries issues when we make the logic operational.
For the sake of this discussion, we’ll just consider decision tables and traditional IF/THEN conditional logic. IF/THEN rules are a more natural expression in many cases. It’s a familiar logic to most people. More importantly, it is very easy to add conditions and/or actions to existing rules (in addition to just changing values or attributes within rules).
Decision tables must be a comprehensive statement of all possible conditions and actions for a particular decision. Where IF/THEN rules need only specify what’s relevant for that particular piece of logic, everything must be specified across a decision table. This can be considered a strength in that it facilitates evaluating a table for completeness. However, there can be two potentially serious weaknesses:
1. It can result in a lot of repetition to ensure coverage thus increasing the number of rules (and potentially decreasing performance and manageability).
2. It is just not as easy to add conditions and/or actions.
It quickly becomes fairly obvious as to what kinds of rules or rulesets lend themselves to each representation. For example, a decision with lots of data validation specific to particular attributes is probably easier in a traditional rule. A decision with lookups based on a set of attributes (e.g., some instances of loan pricing) would fit well in a table. Ideally, this mix of expressions gives us the real power we need to accurately represent and make decisions operational.
Although DMN will most likely incorporate the Friendly Enough Expression Language (FEEL), most of the emphasis is on its use in expressing decision tables. Does this represent a gap (or limitation) between modeling and implementation? A subset of FEEL, S-FEEL, is ideal for simple expressions and decision tables may be sufficient. FEEL itself adds capabilities including the ability to express IF/THEN rules. This combination may indeed prove to be quite powerful when we make the decisions operational. However, it also implies that the approaches to initially delineating the decisions must not produce only decision table artifacts. The core concept of decision modeling is being able to articulate those points in a process where a decision must be rendered and then externalizing that logic. That logic may be a call to another system, a database lookup, a human expert, or rules. And those rules should not be restricted to only one format.
