By Alan Fish
In the recently published Intelligent BPM Systems – Impact and Opportunity, an annual BPM and Workflow Handbook Series, I got an opportunity to co-author a chapter on emerging standards in decision modeling. In this excerpt, I give a brief overview of the "decision requirements" level of the new
Object Management Group standard DMN (Decision Model & Notation), which allows the structure of a domain of decision making to be represented as a Decision Requirements Diagram (DRD). The chapter in its entirety is available here: Download IBPMS Special Edition Emerging Standards in Decision Modeling.
Decision Requirements Modeling
DMN provides two distinct but interconnected levels of constructs for modeling decision-making: the decision requirements level, and the decision logic level.
Decision Requirements Level
The decision requirements level of DMN allows a domain of decision-making to be modeled at a high level of abstraction, using only four types of elements, corresponding to commonly-used business concepts: decision, input data, business knowledge model and knowledge source.
Input data elements correspond to the business concept of data. They are data structures whose values describe the case about which decisions are to be made. They typically group data into high-level concepts of business significance, e.g. “Application Form”, “Claims history” or “Invoices”. Input data are notated in DMN using the shape in Figure 1:
Figure 1 Input Data Notation
A decision element corresponds to the business concept of an operational decision. It is the act of determining an output value (a data structure) from a number of input values (also data structures), using some decision logic. The inputs to a decision may be input data elements or the outputs of other decisions. The decision logic may include the invocation of one or more business knowledge models. A decision is notated in DMN using the shape in Figure 2:
Figure 2 Decision Notation
A business knowledge model corresponds to business concepts such as “expertise”, “know-how” or “policy”. It is a function which encapsulates an area of business knowledge as executable decision logic, possibly expressed as business rules, an analytic model, or an algorithm. One important form of decision logic specifically supported by DMN is the decision table (see 4. Modeling Decision Logic In Decision Tables). The business knowledge model is parameterized, and is therefore a reusable component that may be called from multiple decisions, or from other business knowledge models. A business knowledge model is notated in DMN using the shape in Figure 3:
Figure 3 Business Knowledge Notation
A knowledge source defines an authority for decisions or business knowledge models, for example a manager responsible for a decision, a policy manual, or a piece of legislation with which a set of rules must comply. A knowledge source is notated in DMN using the shape in Figure 4:
Figure 4 Knowledge Source Notation
These four elements are interdependent, and the interdependencies are characterized in DMN as requirements:
- A decision requires all the inputs used in its decision logic: these are called information requirements, which are notated as solid arrows
- Decisions may require the invocation of business knowledge models (and business knowledge models may require the invocation of other business knowledge models): these are called knowledge requirements, which are notated as dashed arrows
- Decisions and business knowledge models may require sources of authority: these are called authority requirements, which are notated as dashed lines with filled circular heads.
When DMN elements are drawn connected by their requirements, the result is a Decision Requirements Diagram (DRD) such as Figure 5. A DRD shows the high-level structure of a domain of decision-making, revealing the relationships between a number of decisions, areas of business knowledge, areas of data and responsible authorities.
Figure 5 Decision Requirements Diagram
In this simple example, a corporate Policy group (a knowledge source) is responsible for defining a set of Policy rules (a business knowledge model), which is invoked to make an Eligibility decision whose output is (e.g.) ELIGI¬BLE or INELIGIBLE. The Eligibility decision uses input data from an Application form, and the results of another decision: Risk, whose output is a risk score. The Risk decision invokes a Score model to calculate the score from input data describing past Customer behavior.
Decision Logic Level
The decision logic level of DMN provides an expression language (called FEEL) for specifying detailed decision logic, and a corresponding notation (boxed expressions) which allows such expressions to be associated with elements in the decision requirements level.
FEEL – the Friendly Enough Expression Language – is a simple language with inspiration drawn from Java, Javascript, Xpath, SQL, PMML, Lisp, and others. In particular, FEEL extends JSON (JavaScript Object Notation) objects: A JSON object is a number, a string, a context (JSON calls them maps) or a list of JSON objects; FEEL adds date, time, and duration objects, functions, friendlier syntax for literal values, and does not require the context keys to be quoted.
The syntax and semantics of FEEL are defined using grammar rules that show how complex expressions are composed of simpler expressions, and semantic rules that show how the meaning of a complex expression is composed from the meaning of constituent simper expressions. As a result, DMN completely defines the meaning of FEEL expressions (provided they do not invoke externally-defined functions). There are no implementation-defined semantics. FEEL expressions have no side-effects and have the same interpretation in every conformant implementation.
Boxed expressions allow the decision logic to be decomposed into small pieces that can be notated in a standard way and associated with elements at the decision requirements level. A DRD plus its boxed expressions form a mostly graphical language that completely specifies a decision model.
For example, the simple boxed expression in Figure 6 might be associated with the Eligibility decision in the DRD above. It first defines the applicant’s age by reference to Application form input data, then calls the Policy rules, providing Age and the results of the Risk decision as parameters. The result forms the output of the Eligibility decision.
Figure 6 Boxed Expression
One form of boxed expression which is particularly important in DMN is the decision table (described in detail in the next section). The simple example in Figure 7 might be associated with the Policy rules business knowledge model in the DRD above. It represents a set of rules for determining Eligibility from Risk and Age parameters.
Figure 7 Decision Table Decision Models
The two levels of DMN—decision requirements and decision logic—together provide a complete decision model. At the decision requirements level, the notation of the DRD is simple enough to make the structure of the model immediately apparent, yet the decision logic level provides a specification of the decision-making which is precise enough to allow automatic validation and/or execution.
Figure 8 summarizes the relationship between the levels of a decision model in DMN, and one possible relationship of the decision model with a business process model in BPMN. Decision models are complementary to business process models, and may be used to specify in detail the decision-making carried out in process tasks. Here it can be seen that the Decision Requirements Diagram is able to form a bridge between a business process model and decision logic expressed (for example) as a decision table.
One of the most common ways to represent decision logic in decision modeling is using a decision table.
Figure 8 The Relationships Between Decision and Process Models
