A Rapid Introduction to Decision Model Notation

To those who are familiar with the OASIS WS-BPEL standard, Decision Model Notation should not be difficult to process. Here is a rapid, intuitive introduction to this notation.

The following infographic attempts to capture the essence of Decision Model Notation as depicted here:

Decision Model Notation enables process designers to express, declare, and represent the body of decisions they will need to map and document for day-to-day decision making. Each decision is taken to meet both strategic and tactical/operational objectives. Each decision must be associated with a Business Objective, as it is referred to in DMN terminology.

The business objective expressed here must be provided and sponsored by the organizational unit or the process owner, and the decision owners and decision makers can allow these aspects to be captured for a given decision.

The weaving and orchestration of any business process, irrespective of whether it is core or non-core, will invariably involve decision-making. The organizational unit that owns a given set of business processes must define a number of Key Performance Indicators (KPIs) so as to enable measuring and benchmarking performance among peers and industry domain. The performance indicators themselves, however, rely on the completion of a set of repeatable activities and tasks that belong to a given process.

In the Decision Model Notation, the Performance Indicator is a placeholder for associating any given decision with corresponding KPIs defined earlier and elsewhere.

Similarly, a decision is never taken in isolation, in disregard of the business process, activity, and specific task which has invoked it. This is the plane where Business Process Execution lands on top of decision-making bodies in order to get specific tasks accomplished. The progression of activity is typically conditional upon satisfactory execution of tasks, which themselves are measured against pre-established criteria.

The decision making that should happen based on the inputs received from the process execution must be based on a comparison of certain reference or benchmark thresholds. For instance, in plant automation, the reference thresholds can be about maintaining a certain level of effluents, or reactants, or about maintaining a certain position or elevation or angle of rotation.

And such comparison against thresholds to establish and regain control of the process such that the output remains within acceptable intervals must be documented, made available, and should be easily shared among qualified and appropriate users or operators. Therefore, the need arises for a business/process rules management system that can allow process designers to specify, describe, alter, store, share, reuse and recycle rules that impact decision making.

FEEL Expression Language: Rules will need to be expressed and evaluated based on certain predefined and standardized expression language, which in a DMN context, is referred to as FEEL, Friendly Enough Expression Language. The expressions can be direct or literal in a DMN context. Computing straight line depreciation of an asset such as property, plant, or equipment is one example of a literal form of expression.

Functional Expressions: As we declare and use expressions, their reusability and maintaince becomes a concern like it does in any programming task. Hence, we will need function definitions where business logic in the form of text, numerical, logical, conditional, looping, and boolean expressions can be declaritively maintained.

Contextual Invocation: As we define functions, we must also specify the context or conditions under which a given function will be invoked. The environment parameters which provide this context for invocation, can be about seasonality in demand, supply, costs, applicable consumer segments with pre-conditions (for instance, for determining health insurance coverage, consumers with a certain age, or with certain medical pre-existing conditions such as chronic ailments) and more such.

Binding Elements: The invocation of functions within a given context will involve specifying cotextual realities in the form of parameters which carry pre-defined values..

However, business process design and control is not only about defining, maintaining, and executing rules.

Rules serve as an expression of objectified business strategy execution, but a business must also have policies and governance in place to provide the greater context in which such rules become relevent, applicable and executed. For instance, rules that are triggered by a return request by a consumer must be subject to the returns policy defined and accepted by the consumer.

Another example can be whether a new decision about extending promotional offers such as a free trial period on a product or software license beyond 3 months can be operationalized, as an exception to the standard policy of 3 months. Any new decision should be subject to policy guidelines which, in turn, should be available declaratively. In DMN, this governing policy aspect is addressed in the Authority Requirement, which points or refers towards the Business Knowledge Source.

So, not only do we need a set of rules that check against established thresholds, that must happen in accordance to the policies that must be invoked and adhered to. In terms of functional needs, the system must be capable of supporting the lifecycle management functions such as the creation, edition/alternation, versioning, storage, sharing, recycling, and archival.

Rules or decisions do not work in isolation. They will need the information to work with. This information can come from a variety of sources, such as from predictive analytics or machine learning models, apart from other business processes, systems, and third-party sources.

In the Decision Model Notation, information and knowledge requirements respectively serve covering this aspect when specifying the declarative definition of Decision.

As we speak of information, the security, confidentiality, and integrity aspects must be respected and complied to. The established system must offer safeguards against unauthorized access, unintended exposure and alteration or destruction.

Decisions and rules must be applied consistently, repeatably, and in a standardized way. They must also be extensible at the same time so that they can include variations that domain specific, product line specific, and service specific.

Decision Services: This is where decisions which have been defined as above, are packaged as services in order to be discovered, orchestrated and reused. 

Beyond this point, after we have declared, specified, and represented decisions that must be taken for one or more business processes), it is about invoking one or more decision services, which in turn could be dependent on invocation of other such decision services or individual decisions, in order to compute outcomes.

Let's quickly review the qualitative aspects of declaring, specifying and documenting decisions. These are represented in the following infographic.

As with any information artifact, decisions represent proprietary, and business-critical information. Hence they must be protected from unintended exposure, unauthorized access, tampering or use.

While the decisions themselves should be secured and appropriate level of confidentiality/privacy should be included in design, at the same time, they must be traceable in order to hold parties which define, alter and use such decisions accountable.

Another important aspect is IP rights. This one should perhaps be addressed because decisions could get as proprietary as the business processes that invoke them. While the way decisions are modeled is standardized the business logic that is contained within them is not. So, this is still a gap which hopefully will be addressed soon.