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 [this post]
- Decision Modeling: Finding and modeling decisions
- Decision Modeling: Input Data and Knowledge Sources
- Building decision tables from decision models
- ML, AI and other forms of Data Analysis and Advanced Analytics
--
Obviously, a decision requirements model is just a structure. It defines the shape of a decision – the pieces and how they collaborate – but it doesn’t define any logic. To complete a decision model, you need to define decision logic for it.
The logic layer of a decision model can be defined at various levels of detail. You might sketch out the critical logic just to help validate the model you have developed. You might define most of the logic, but in natural language to help explain how the whole decision was made. You might define most of the logic in a precise set of unambiguous expressions so it can be reliably implemented. You might even use the Friendly Enough Expression Language or FEEL, part of DMN, to define a completely executable decision model. The right level of detail, and the right approach, will depend on what problem you are trying to solve.
Regardless of the level of detail, the core decision logic artifact in DMN is the decision table.
Decision Tables
Decision tables will be familiar to anyone who has used a Business Rules Management System or Decisioning Platform in recent years. A tabular representation of a set of rules, decision tables are the most popular and easiest to use of rule representations. In a typical decision table, each row is a separate rule while each column is either a condition, an action or an annotation. Take this example:
The table has a few condition columns, representing pieces of information that can be checked in conditions and an action column to show the result if all the conditions are true. It could also have an annotation column (green) to help explain what happened. Each row is a rule with all the conditions ANDed – a row is true if all the conditions in all the columns for that row are true and false otherwise. There are no ORs in a decision table – you create another row and another rule instead. Conditions in each column are generally simple comparisons though some decision tables allow more complex checks. The condition columns can show the allowed values for the column, to support error checking. The table also has a hit policy to instruct the engine on how to execute the rules – in this case it is marked Unique (the most useful kind) which means that the design has ensured only one row can hit for any given set of data so the engine can execute them in any order and stop as soon as it finds a hit (because there can only be one). There are others which I might get to later.
In one of DMN’s most powerful features, decision tables are linked to the underlying requirements very directly. Each column in the decision table is based on an information requirement (I’m simplifying a little), which means that each column can be linked EITHER to a decision or to an input data. Each column must be linked to a specific information item. Because input data can contain multiple information items, you can have multiple columns in a decision table that relate to a single input data. Decisions generally produce a single information item, meaning that a single column represents one of the sub-decisions. When decisions produce multi-part answers, the column is linked to one part. This means that any decision table in DMN can be mapped to the information requirements shown in the diagram.
Once you have a decision requirements diagram that covers your problem domain and have written decision tables for (most of) the decisions, you have a robust definition of your decision. Decision modeling works quickly and lets SMEs and businesspeople work directly with you on a complete, accurate and business-centric view of the decision-making. Everyone’s working from the same model and talking the same language. It’s great.
The Rest
While decision tables work for much of the logic in most decision models, some logic is best expressed as individual rules or mathematical equations. When documenting a decision model, you can simply choose not to write a decision table but instead to write some logic. It still needs to match the structure of the decision requirements model, but it doesn’t need to be tabular.
If you are writing an executable decision model then there are a wide range of other expression language artifacts available in FEEL and there is a great online handbook here courtesy of the Drools project – the open source project behind DMOE. If you are writing executable logic in ODM or ADS, this logic is in the rule syntax you are familiar with.
Once you get to this point, you are writing a snippet of code logic to implement a decision’s behavior and the decision model is providing a frame within which you work. I’m not going to cover this in any more detail as it’s not really different in a decision modeling context.
Finally, it’s increasingly common for some of the decisions in a model to be implemented using Machine Learning or AI. DMN (and DMOE) allows you to link a block of Predictive Model Markup Language (PMML) to a decision if you have one. You can also just hand off the implementation of the decision to your favorite ML/AI platform and hook up a suitable API call in your implementation. While this is practical in all the products, IBM ADS has some nifty user interface components to make this really straightforward. Hopefully I’ll get to this later.
In the next post, I’ll spend some time on how to identify decisions and build your decision requirements layer.
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