The Separation of Decision Modeling from BPMN

Collaboration between decision models and process impact both decisions and process outcomes. The Decision Model and Notation (DMN) was designed to complement the Business Process Model and Notation (BPMN) and particular concerns around implementing decisions associated with various process models. Some process models include encoded decisions throughout the flow structure and data flow elements. In this article, we will explore the separation of decision modeling from BPMN and which a decision model should capture components of decision-making. Lastly, we will look at how it plays a role in collaborative networks.

What is decision modeling?

To initiate decision modeling, start with the decision: “What question needs to be answered?” Then, add the inputs (considerations) necessary for answering the inquiry. Include all the possible combinations of values and outcomes (conclusions). Now, ask the following: “How does the outcome rely on the considerations?” For each consideration that does not include immediately-observable data, consider what would be required to create the input as a sub-decision outcome. Continue playing out all possible combinations and effects until every consideration is configured in verifiable data and does not need additional sub-decisions.

Consider a wine-of-the-month subscription box. The rules that determine whether an incoming order is accepted should be designed unambiguously. For instance, if the question is asked, “Accept incoming order?” then the outcome should only include two potential values, “Yes,” or “No.” Besides, there should be legal factors considered:

• Whether the customer is of legal drinking age in the state where they have placed their order.
• Whether their state allows alcohol delivery.
• Whether the shipping address is outside of delivery parameters, such as outside the U.S.

Adding all these factors together, the wine-of-the-month company can proceed with an unambiguous decision whether to accept the order or not. 

Decision modeling for order acceptance

When you break down decision modeling into sub-decisions, it becomes easier to reuse them independently. On the other hand, DMN can focus on decision tables and support decision variations and special considerations. If DMN does not include predictive models, decision trees, rule sets, or even scorecards, it may miss its target. When processes become more complex, multiple decisions can affect the outcome. Since the context of decisions can impact results, this aspect must be considered during process design. As a result, it stands in contrast to DMN’s declarative protocols. So then, ensuring consistency with decision and process models should also become a priority. Here are a few scenarios involving DMN and BPMN:

• Processes without decisions but with predetermined activities. Since no decisions are made, then integration will not occur. Decision outcomes can be used as inputs for the process flow.
• Processes include various interrelated decisions. The flow and the outcome depend on the findings. To improve efficiency, it is crucial to ensure that no decision is made twice.
• Processes are knowledge-intensive and only utilized to decide on one output.

For instance, imagine applying for a business loan and initiating a new process. After the bank receives the necessary financial data, a decision must be made whether the customer’s background deems eligibility for a loan. The criteria are based on financial health to minimize the risk of default. If the customer meets the criteria, the loan is accepted. If not, then the business loan is rejected. However, if eligibility criteria changes, then the process model and inputs must change.

Separate decision modeling from BPMN

When you look at BPMN 2.0, then you get a more standard definition for calling business process rules. The “Business Rule Task” uses inputs and outputs from invoked tasks. Also, these inputs and outputs can act as outcomes for decisions. In addition, sub-decisions contribute to a comprehensive business decision. It then makes sense for DMN to support BPMN 2.0.

Further, BPMN 2.0 sets the definition for “Global Business Rule Task,” which can be reused in various business processes. It looks at and makes decisions based on a global perspective. When these types of global rules are captured, businesses have improved capabilities of analyzing rules applied throughout their organization. Yet, while sub-decisions may be reused throughout processes, the outcomes can vary. DMN can define decisions that exist outside of but may also be associated with BPMN 2.0 processes. Here are more reasons why DMN benefits BPMN 2.0:

• It offers a decision management protocol set apart by integrated notation, similar to how BPMN 2.0 manages business processes. 
• It connects process-based, rule-based, and information-based perspectives of businesses. 
• It lets modelers look at business modeling from the above three perspectives.
• DMN provides a standard for business-based decision modeling.

Final thought

DMN can define a decision-specific protocol that will link business-rules modeling with computation-independent attributes while supporting components of BPMN 2.0, such as process-specific decision modeling. Instead of selecting modeling from a strict business rules perspective, DMN empowers tools that create an environment where modelers can transition between processes, rules, and modeling decisions. DMN is the missing link that can separate decision modeling from BPMN.