Posts in the series:
- Benefits of Decision Modeling
- What is a decision model and what is DMN
- Decision Modeling: Decision Requirements
- Decision Modeling: Decision Logic
- Decision Modeling: Finding and modeling decisions
- Input Data and Knowledge Sources
- Building decision tables from decision models [this post]
- ML, AI and other forms of Data Analysis and Advanced Analytics
--
I wrote earlier in the series about decision tables and how they map to the decision requirements that you have modeled. In this post, I’ll touch on some additional tips for building decision tables in a decision model context.
Obviously, much of the process of building a DMN decision table is the same as building any set of rules. You need to think about the logic, figure out the thresholds and identify which combinations of conditions result in which outcomes. But there are some specifics to building decision tables when you have a decision model as your starting point.
Answers drive outcomes
When you build a decision table, you’re building it for a decision. When you found and modeled that decision, you defined a question and a set of allowed answers for it. These allowed answers are the only possible outcome of your decision table – the values in the action column. Your job, when writing the rules in the decision table, is to pick which allowed answer is appropriate for each row in the table. If the allowed answers were defined as “a number between 1 and 10” then your rules can only set the answer to a number between 1 and 10! If your allowed answers were Accept, Reject, Refer then you can’t write a rule that sets the status to “Mostly Accept” and so on.
When you are writing the rules in your table, you may find that you have a rule that results in an outcome you didn’t anticipate. That’s OK – just remember to go back and validate that the new allowed answer is OK and that any decision that depends on the one you are editing can handle the new answer (see below).
When you implement decisions in a tool like IBM ODM, each decision will need an element in the object model to store its result so it can be used as an input to other decisions.
Requirements drive conditions
Each column in your decision table is driven by a requirements link – to an Input Data or to a Decision. Each Input Data has a data structure (see this post) and the column in your decision table needs to be tied to one of those data elements as noted in this post. For instance, a decision that depends on the Customer Input Data object might have a decision table with several columns, each of which uses a different piece of Customer information (age, gender, status etc.).
A column in your decision table can also be tied to a required decision. Most Decisions have a simple answer represented by a single piece of information but if a decision returns multiple items in a structure, then the column is linked to one of them.
This link tells you exactly what kinds of conditions you can have in each column. If your column is tied to a decision and that decision has allowed answers of “Accept, Reject, Refer,” then your conditions can only check for one or more of these values. Nothing else makes sense. Similarly, if your column is tied to a piece of numeric data, then it should have numeric comparisons and so on. You should also make sure that your decision table handles ALL of the possible values or at least consciously decide that you are not going to.
One of the big advantages of decision models in this context is that you can write a decision table that uses the outcome of a decision you haven’t defined yet. As long as you know the allowed answers, you can consume them in a table – you don’t need to have defined the logic for picking between them yet. This allows you to work independently on decision tables across the whole model.
Mechanically, each column will be tied to the object model element that represents the required decision or the input data.
Columns are ANDs, Rows are ORs
As with all decision tables, columns are ANDed together. Each row checks all the columns and the rule represented by the row is only true if all the conditions – all the columns – are true. Columns can be marked as “-” in a row if the value of that column is irrelevant.
There are no ORs or ELSEs in a decision table – essentially you create a row for each OR and another row for an ELSE. This allows each set of conditions to be managed as its own row and simplifies management. Unless the OR was used to identify a set of potential values that are all OK when you would replace that with an In( ) statement…
Final Thoughts
KISS – as always, keeping things as simple as possible is always worthwhile and will repay your investment when you come to maintain the rules – or hand the rules over to someone else to maintain.
Normalize your rules - decision modeling lends itself to a “normalization” process where you break down the decisions until any given business change is encapsulated in a single decision – one business change, one rule change. I’ll come back to this in a later post on effective design.
Finally, not all decisions are decision tables. Some are better represented as a rule or calculation. Some are best represented by machine learning or other analytic models and some are going to be made by humans and the result passed to your rules. Decision models work regardless and let you see where these other pieces fit. It’s still worth capturing questions and allowed answers even when you are writing regular rules or treating the decisions as input to your rule execution.
If you want more detail, you can get a text book on the approach (written by me and Jan Purchase): Real-World Decision Modeling with DMN 2nd Edition. If you or your company need help with decision modeling, drop me a line james@decisionmanagementsolutions.com and we can schedule a quick call to discuss. And if you’re excited about decision modeling and keen to do more, why not join DecisionAutomation.Org and participate?
#IBMOperationalDecisionManager#OperationalDecisionManager(ODM)#AutomationDecisionServices(ADS)#DecisionManagerOpenEdition#DMN#IBMChampions#decisionmgt#DecisionAutomation
#IBMChampion