Introduction
The Business Process Model and Notation, BPMN 2.0, has established itself as the dominant standard for process modeling since its release in 2011. The publication of the Decision Model and Notation, DMN [1] , adds a new perspective allowing decisions to be modeled alongside processes in an open, vendor-neutral way.
Integrating DMN and BPMN provides an even more powerful and capable tool set for business analysts, enabling four key benefits:
- Streamlined business processes
- Focused requirements process
- Improved visibility and flexibility of business rules
- Framework for integrating analytics into business processes.
Streamlined processes
A combination of process modeling and decision modeling simplifies business processes by eliminating and replacing entire sections of the model with a decision model—the decision logic of the process model is precisely captured by decision modeling a separate yet linked model.
Focused requirements
By focusing on decisions and processes independently the requirements process is more focused. Different stakeholders are frequently involved in the process and the decisions within the processes, so separate models often work better. Because the pair of models are simpler than a single combined model, the requirements and modeling activities are easier to manage and complete. Decision models link the tasks in a process to the required business rules as well as to critical organizations and business metrics. These steps improve the efficiency of the requirements process.
Improved visibility and flexibility
DMN structures and manages the business rules that a process requires, gathering them into a coherent model at each decision point in the process. This simplifies change management by connecting the decision with the correct right rules. Rules (decision) are positioned for change, independent of the process. Because the decision models are also linked to business metrics, organizations improve the visibility of rules’ impact on business performance.
Framework for analytics
DMN provides a model of the decision making in a process and this allows the impact of analytic models to be clearly expressed, allowing increasingly advanced analytics to be integrated into a process.
An Example
Source: "The MicroGuide to Process and Decision Modeling in BPMN/DMN: Building More Effective Processes by Integrating Process Modeling with Decision Modeling
A simple decision and gateway control of an execution path to respond to a purchasing decision.
As the figure above shows, the proper use of decision modeling uncovers critical directives that the process must address to comply with the decision. Decision-driven processes act on the directives of decision logic: decision outputs affect the sequence of things that happen, the paths taken, and who should perform the work. Processes provide critical input into decisions, including data for validation and identification of events or process-relevant conditions. The combination of process and decision modeling is a powerful one.
In most business processes, an operational decision is the controlling factor driving processes. This is powerful, as many governments and enterprises focus on minimizing the event response lag because there is often a financial benefit to faster responses. Straight-through processing and automated decision making, not just automated processes, is also emphasizing the importance of decisions in processes. Developing a decision model in DMN provides a detailed, standardized approach that precisely directs the process and creates a new level of traceability.
Decision modeling can therefore be considered an organizing principle for designing many business processes. Most process modeling in BPMN is accomplished by matching a use case, written or otherwise, with workflow patterns. Process modeling is critical to the creation of a robust and sustainable solution. Without decision modeling, however, such an approach can result in decision logic becoming a sequence of gateways and conditions such that the decision remains hidden and scattered among the process steps.
Without decision modeling, critical decisions, such as how to source a requisition when financial or counter-party risk is unacceptable, or what to offer a customer, are lost to the details of the process. When the time comes to change or improve a decision, a process model in BPMN alone might not meet the need. Providing a notation for modeling decisions separately from processes is the objective of DMN.
DMN Overview
As DMN is a relatively new standard, we will cover the basic elements. The core of the DMN standard is relatively straightforward, using only four shapes and three links. We provide a brief summary of the DMN notation in this section. The complete standard can be found on the Object Management Group’s website here.
Basic DMN Elements
Decision
A decision is represented by a rectangle that contains at least its name. A decision determines an output from a number of inputs by applying some decision logic. Decisions can be decomposed into sub-decisions. Top level decisions can be thought of as selecting an action from a range of possible actions. Lower level decisions often will simply provide input to other decisions. All decisions, at whatever level of granularity, are represented the same way, and there are no subtypes.
Input Data
Input data is represented by an oval that contains, at the very least, its name. Decisions require inputs, and many of these are input data, which is data that is input to the decision making from outside the decision context. When a decision is modeled and linked to an activity, input data is the data that can be passed to the decision from the process.
Knowledge Source
Knowledge sources are represented by a document shape that contains, at the very least, its name. Knowledge sources represent the source of know-how for making a decision. This could be regulations or policies about how a decision must be made, best practices or expertise about how it should be made, or even analytic knowledge about how it might be made more accurately. Knowledge sources are the authorities for a decision and typically refer to some external document or source that contains detailed guidance.
Business Knowledge Model
Business knowledge models are represented by a rectangle with clipped corners. Business knowledge models represent functions that encapsulate reusable decision making logic. The logic they encapsulate might be a set of business rules, a decision tree, a decision table, or an analytic model. The specifics of knowledge representation involved need not be displayed on the diagram, but many tools might do so. The initial DMN specification does not provide any notation for this, however.
Decision Requirements
The four shapes—decisions, input data, knowledge sources, and business knowledge models—comprise the nodes in all decision requirements diagrams. The links between these nodes are requirements links, denoting one of three kinds of requirements.
Information Requirements
The primary requirement link, shown by a solid arrow, is an information requirement. These are used to show the inputs to a decision. If a decision requires a piece of information, then it will have an appropriate information requirement link. The element at the blunt end of the link is required by the decision at the arrow end.
Knowledge Requirements
If Business Knowledge Models are being used then Knowledge Requirements show how those Business Knowledge Models are invoked to make decisions.
Authority Requirements
Authority requirements show where the process needs to go to find out how to make a decision. Shown by a dashed line with a round end, authority requirements identify that the element at the blunt end is an authority for the element at the round end. This allows for a knowledge source to be linked to a decision to show that it contains some of the knowledge needed to make that decision. Authority requirements are purely documentary and have no impact on execution.
Decision Requirement Diagrams
These four elements—decisions, input data, knowledge sources, and business knowledge models—can be combined to create decision requirement diagrams. The relationships created by adding requirements links to these diagrams produce a network of linked elements and form the basis of a decision model.
Multiple decision requirements diagrams can be developed, and the model contains all the relationships specified on any diagram. There is no requirement that any particular diagram be complete, and no one diagram needs to show all the requirements relationships in which a given element participates. Experience so far suggests that there are number of ways to use the diagrams.
A decision requirements diagram showing decision context.
Source: "The MicroGuide to Process and Decision Modeling in BPMN/DMN: Building More Effective Processes by Integrating Process Modeling with Decision Modeling
Connecting Decisions to Processes
The combination of decision modeling in DMN and process modeling in BPMN creates more focused processes by moving decision details into DMN. Using DMN alongside BPMN increases clarity and reduces the number of process gateways and script assignments, as well as the need for complex access to data sources.
A decision-driven process acts on the outcome of the evaluation of decision logic in several possible ways, including:
- Changing the sequence of activities that are taken after a decision, including what the next activity or process that is required to meet the directive of the process.
- Selecting between the paths on the diverging or the splitting side of a gateway.
- Deciding who or what participant should perform the needed activity.
- Creating data values that will be consumed later in the process.
Inputs into the decision include:
- Data that can identify events or process-relevant conditions.
- Data that must be validated for correctness.
- Data used in calculations.
The decision can be thought of as a meta gateway with merging inputs (events and data) and splitting outputs that direct the process in an overarching way (i.e., participants, tasks, and gateways).
Integrating business process modeling with decision modeling, as well as event processing, can create comprehensive, agile solutions in many problem domains. Without decision modeling, process modeling in BPMN can both overcomplicate a model with logic and miss critical design details. As decisions are modeled, things will be discovered that the process must do to accommodate the results of those decisions. Exploring decisions will lead to the discovery of implicit process events, activities, and sequences.
Process Discovery for Execution in DMN/BPMN
There are seven steps in a high-level process discovery effort using BPMN/DMN:
- Develop a high-level process model. This high-level model and other discussions will help identify the critical decisions.
- Identify decisions that support operational, compliance, and risk management objectives and that support these processes.
- Develop decision models that show how to deliver the needed responses within these processes. In turn, these responses suggest process elements in an iterative development cycle.
- A data model is necessary for executable decisions and processes. Develop a data model to provide specificity to process data elements and decision inputs/outputs.
- The narrative of each decision allows for the refinement of the decision models, showing how multiple logic elements or conditions are combined.
- Detailed decision logic can be specified to manipulate incoming data from input data sources or other decisions and produce the required outputs.
- Use the assignment of values to attributes by decisions to prescribe downstream process components, activity order, role responsibility, paths through the process, data, and events.
The diagram below depicts five abstract, iconic processes patterns that highlight or illustrate the connection between the decision and the responding process. They suggest what can be affected with dynamic operational decisions.
Source: "The MicroGuide to Process and Decision Modeling in BPMN/DMN: Building More Effective Processes by Integrating Process Modeling with Decision Modeling”
Conclusion
Well-designed processes simplify management control of business processes. In the absence of DMN, decisions are not separated from the business processes— the details of the decisions are scattered throughout the process model. This creates a weak model because decisions both change and control critical elements of the process.
Separating processes from decisions stabilizes business processes and permits change without having to change the process application.
Both business processes and decisions are important intellectual assets that need to be documented, managed, and shared in BPMN/DMN. This can be achieved across the enterprise using repositories and software tools.
Authors: Tom Debevoise & James Taylor
Tom Debevoise is a master solution designer, architect and systems integrator. Tom has process, decision and event modeling expertise in many areas including recent work in IOT, Next Generation Energy and Security C2. www.tomdebevoise.com
James Taylor is an expert on how to use decision management, business rules & predictive analytics to improve operational performance. James is also a contributor to V3 of the BABOK® Guide and a member of the submission team for the new Decision Model Notation (DMN) standard. www.jtonedm.com
- DMN 1.0 was accepted by the Object Management Group Architecture Board in December 2014.