Continuing blogging from Building Business Capability and it’s time for Jan Vanthienen to talk decision modeling for the business analyst. Jan is a leading researcher into decision modeling and decision tables at the University of Leuven.
Observation 1: Decisions are important for business, not only processes.
Too often, he says, the process is modeled with no real thought being given to the decision-making required – a claims process that does not really describe which claims will be paid, only how to pay or reject them. To describe them, companies must model them and the DMN (Decision Model and Notation) standard is ideal. DMN defines two layers:
- The requirements for a decision in terms of other decisions, data and sources of knowledge.
- The logic of the decisions, derived from these knowledge sources and applied to the data to actually make the decisions in the requirements.
Once you model the decision separately, much of the decision-making complexity that overloads a process model can be removed to simplify and clarify the process.
Observation 2: Decision logic should not be shown as process paths.
Decisions should be modeled as peers of the processes that need them so they can change independently, be managed by different people etc. This reduces the complexity of processes by removing decision logic and decisions from the process model and instead linking the decision to a specific process task.
Observation 3: Multiple decisions in a process might be in a single decision model
Observation 4: Proven techniques exist to represent decision tables and decision models
From a methodology perspective we need to do three things
- Model the decision structure
- Build a decision requirements graph – a decision requirements diagram – to show how the decisions, data and knowledge sources form a network describing the decision making and its structure.
- Generally this is best done top down and descriptions of questions and answers in requirements or policies often lead very naturally to sub-decisions.
- Descriptions of data elements are similarly clear. But if you just try to write a decision table against these data elements you will end up with an unwieldy model. Build a model first.
Decision requirement models are built using expertise, by seeing which conditions depend on the results of other decisions, and by normalizing the model to eliminate redundancy.
- Model a single decision table
- Decision tables are not the only way to manage the business rules for a decision in the model but they are a very effective one and one that business users find very transparent.
Representing a description of logic as a decision table clarifies and makes consistent the logic it represents. And the logic read in several ways without ambiguity – what will I do if? OR when will I do x?- Decision tables can show rules as rows or as columns, with each column/row being based on a fact. This creates a repeated structure for each row. And the rows are all rows that only have ANDed conditions (ORs lead to new rules as they should).
- The standard also defines a “hit indicator” to define how to handle situations where multiple rules in a decision table are true. But stick to Unique and perhaps Any’s because the others get you into trouble…especially First which is just a way to code ELSEs!
- Decision tables can be correct, compact and consistent but generally you can only get 2 of the 3. Start focusing on correctness, work to ensure consistency. Only take compactness as a bonus.
- Jan likes to use rules as rows or rules as columns depending on the shape of the table. I prefer to stick to rules as rows unless it’s really important…
- You can build decision models and tables interactively with people, from text of policies or regulations, or by mining data/rules/code. You can also find all the possible condition values and outcomes and build an empty table. As you fill in the logic you can clarify and normalize.
- DMN allows the modeling of decisions alongside processes, simplifying processes and creating a more declarative and understandable model of decision-making. It also separates the structure from the logic while allowing them to be linked and reused. DMN standardizes and extends decision modeling and decision table approaches but builds on a long history of techniques and approaches that work.
- Model the process connection
- Sometimes the entire process is about a decision. Model the decision first and then think about how to execute it, how to build a process around it. A process might do all the sub-decisions in parallel to minimize the time taken OR specific decisions might be made first because they eliminate the need to do other parts of the process for efficiency OR some decisions might be made about several transactions at the same time in a group OR…
- The decision model describes how to make a decision so that you can not only build a decision-making system but also answer questions about how the decision works, how it is made.
By the way, my new book on DMN – Real-World Decision Modeling with DMN – is available
