Jan Vanthienen of the University of Leuven presented to the Object Management Group’s session on Decision Modeling Notation. He began by discussing how business processes need flexibility and this means you cannot hard code rules and decisions in your processes – processes often don’t change even when the decisions within them do. Rule Tasks in BPMN 2 for instance can manage how a decision should be made. There is a good case for an obvious separation of concerns with decisions and processes managed separately and collaborating (processes invoking decision services for instance) to deliver business results. A decision modeling notation would help manage this approach.
Jan’s focus is on decision tables. Decision tables have a much longer history than people think, dating back at least to a CODASYL report from 1982 (see the key chapters here)! Decision tables give a good view of our decision-making approach, they are compact, can be verified and validated, and support a modular approach. Of course there is also a lot of work done on how to execute decision tables. In a decision table we separate conditions and actions and lay them out in a tabular form.
A good decision table represents a complete set of mutually exclusive conditional expressions – a two dimensional grouping of interrelated rules where:
- Columns are exclusive and should not overlap
- Exhaustive so that all combinations of conditions are handled
Of course the use of a decision table metaphor to manage predictive scorecards is a slightly separate issue.
Tables must be normalized in the same way that data must be so that actions are dependent on the conditions, the whole set of conditions and nothing but those conditions. Most decision tables should be single hit tables – only one hit is possible for any set of values. Multiple hit tables should only really be used for additive scorecards – a predictive model.
Real world problems are complex and require not a single, simple decision table but a dependent network of decisions. Jan calls this a “decision goal network”, showing which sub decisions are required to make a new decision. Even the original CODASYL report highlighted the value of multiple linked decision tables. And this kind of dependency or goal network can be converted to a decision flow or a decision process in a variety of ways – determining all the dependent decisions first or sequencing them one at a time etc.
For decision tables, like most things, there are a variety of methods for developing them. You can capture the rules interactively by interviewing experts for instance and then gradually build a decision table (bottom-up). You could structure the decision table from the top down by analyzing policy or legislation and then fill out the details. Or you could mine text/data for rules – using predictive analytics/data mining or text analysis to find the conditions and actions needed for your table. And once it is complete, simplify it.
Decision tables are clearly going to be part of any Decision Model Notation and Jan’s understanding of decision tables is second to none. You can find more about Jan here.
