Context for Decision Model and Notation

The Decision Model and Notation (DMN) standard has been created to complement the Business Process Model and Notation (BPMN), used primarily to model Business Process diagrams; the two standards have been designed to work together. BPMN has a specialized Activity called a Business Rule Task, which acts as a placeholder for a business rule calculation to be performed by providing inputs and waiting for the outputs provided by the rules engine. This element acts as the departure point into a Decision model, thus allowing complex and often volatile business rules to be defined and managed separately from the process models.

The Decision Model and Notation specification, however, makes it clear that the DMN can stand on its own, independent of BPMN,  and that there are a number of other standards and languages that can be used in conjunction with the DMN. This list identifies languages that - by design or by inference - can be used in conjunction with the Decision Model and Notation; new and existing languages will in the future define grammars that interface with the DMN.

• Business Process Model and Notation
• Unified Modeling Language
• Systems Modeling Language
• Case Management Model and Notation
• ArchiMate

Decisions do not exist in isolation, nor are they just the simplification of process models, but rather they are an expression of business intent and often form the fabric of what differentiates an organization from its competitors. The Decision Requirements diagram allows an organization to express how decisions are related, and the Business Process diagram articulates at what points in a set of processes they are invoked.  Enterprise Architect is uniquely positioned as an enterprise modeling platform to show how the decisions relate to other enterprise modeling content, including as described in the rest of this topic.

Business Process Model and Notation (BPMN)

This connection between the DMN and BPMN languages will result in simplified Business Process models and a clear separation between the description of what an organization does and the decisions it makes, ultimately allowing the organization to respond quickly and efficiently to change.

Business Rule Task

The Business Rule Task was added into the later versions of the BPMN specification to allow any Business Rules engine to be called at a specified point in a Business Process, and for the engine to return a result to the process once the request had been processed. It is this mechanism that can be used to integrate Decision Models with Business Processes, thus providing a syntactical mechanism to keep these quite different concerns separate from each other. Enterprise Architect is a rich modeling platform, and it not only allows both types of models to be created but also permits them to be visualized on the same diagram.

This generic diagram shows how these models can be viewed within the tool; the composite view is simply one option for displaying the two models, and in this view the modeler has only included the highest level Decision and the two contributing Decisions. Full details of the Decision model could be viewed by simply using the Decisions context menu and selecting 'Find | Find in all Diagrams'.

Systems Modeling Language

The Systems Modeling Language (SysML) is used extensively by systems engineers working with a methodology known as Model Based Systems Engineering (MBSE) to describe complex real world systems. There are many situations where decisions form part of the description of these systems.

Use Cases

The SysML Use Case can be used to describe a goal a user is trying to achieve by using the system. The Use Case can be described using a series of steps typically creating a backward and forward interaction between the user and the system. The steps the system performs often require decisions to be made and these can be modeled using a Decision Model. Consider a Use Case that describes an aspect of a Ship's navigation System. A step in a Use case could be 'The system decides on the optimal course and way points'. There would typically be a number of inputs into this decision which could be conveniently recorded in a Decision Model.

Activities and Actions

The SysML Activity diagram is a close (but older) cousin of the BPMN Business Process diagram and uses similar notation and  semantics. Traditionally, decision logic has been intertwined with process flows using Decisions, Merges, Forks and Joins to describe the choices and conditions under which decisions are made. This has lead to complex and often unwieldy Process diagrams. Using the DMN, the decisions (including their logic) can be removed from the diagram and placed in a Decision Model. This has the effect of simplifying the diagrams, resulting in straight-through process flows and a model where decisions can be reasoned about, easily changed, and also generated to implementation code.

Unified Modeling Language

The Unified Modeling Language (UML) has become the de facto standard for modeling business- and software-centric systems. The types of system that are modeled using UML commonly have important decisions that form part of their specification and implementation. There are a number of places where decision modeling plays an important role.

Activities and Actions

The UML Activity diagram is a close (but older) cousin of the BPMN Business Process diagram and uses similar notation and  semantics. Traditionally, decision logic has been intertwined with process flows using Decisions, Merges, Forks and Joins to describe the choices and conditions under which decisions are made. This has lead to complex and often unwieldy Process diagrams. Using the DMN, the decisions (including their logic) can be removed from the diagram and placed in a Decision Model. This has the effect of simplifying the diagrams, resulting in straight-through process flows and a model where decisions can be reasoned about, easily changed, and also generated to implementation code.

Use Cases and their cousins User Stories

Although there are often robust debates about the differences between Use Cases and User Stories, they are both concerned with a goal that a User is trying to achieve. Many of these goals require decisions to be made at various points in the Use Case or User Story. In the example of Use Cases, a Decision Model could be used to describe a system step in the Use Case, such as 'The system determines the level of access to give the user'.

Components

Many systems are partitioned into a series of Components that are responsible for a discrete part of a system's function or services. In order for a Component to carry out its work, it is frequently required to make decisions. Consider a Payroll system that has to determine if over-time is applicable in a particular situation, or an Air Traffic Control system that has to decide whether to put an in-coming aircraft into a holding pattern, and for how long. (Most people at one time or another have been on the receiving end of that decision!)

Devices

Whether virtual or physical, many devices are required to make complex decisions. Consider a router that has to make complex decisions about where to route network traffic, or a traffic controller that has to schedule various traffic control mechanisms to optimize traffic flow, or a firewall that protects an organization's network.

ArchiMate

ArchiMate is an enterprise architecture modeling language used to create, manage and visualize architectures at a number of different levels. There are a number of important places where decisions can be defined and described, including at the level of strategy. Consider an architecture that defines an Application Service that selects a default set of products to offer to a customer. The decision about which products to bundle could be expressed in a Decision model.

Drivers and Goals

Decisions can be related to drivers that create, motivate, and fuel the change in an organization. To fully articulate goals, decisions can be used to show potential differences in direction setting. There are often high level decisions that need to be made at this level of an organization.

Enterprise Information Models

Input Data required by Decision models can be related to entities in Information models at any level of detail, from high level conceptual models down to physical data model schemas. Connecting the Decision models with the Information models ensures that the data required by the decision is available when it comes to implementing the decisions.

Policies and Standard Operating Procedures

Decisions, Business Knowledge Models or Knowledge Sources can be related to elements that model polices, standard operating procedures or work flows. These are often the source of information that dictates or guides decisions.

Application Service

Decisions related to the provision of the service can be related to the Application Services to demonstrate how a service makes its decisions.