The business value of DMN

DMN is the global standard for decision modeling, using only a few shapes to represent them in a diagram and supporting common constructs such as decision tables.

WHAT is DMN?

DMN (the Decision Model and Notation) is a global, open (that is to say, public, not owned by any vendor) standard for decision modeling.

It is controlled and published by the Object Management Group (OMG), one of the most highly regarded standards bodies in the world. DMN is not the only way to represent a decision but it is the only global standard for decision modeling.

Decision Model & Notation - a Technical Overview

Please take a couple of minutes and watch the technical introduction.

Why model decisions with DMN?

Because of the broad experience of OMG’s DMN committee, the standard is potent and is the most widely used decision modeling notation. Furthermore, DMN is supported by many software tools and the standard dictates that models can be freely exchanged between these tools.

As a consequence, by adopting DMN, an organization is not only benefiting from having a well-defined standard for precise modeling of decisions but also leveraging commoditized DMN skills across their enterprise and the community, benefiting from the use of a wide range of software tools without product lock-in and integrating decision models with other compatible standards published by the OMG (e.g., BPMN, CMMN, UML). In addition, DMN supports the integration of analytic and machine-learning components into decision models; forming a very natural and powerful combination. To date, no other decision modelling notation offers all these advantages.

However, be aware that DMN limits itself to the representation of decisions and associated assets, while process aspects (which are dealt with by BPMN) are not in the scope of the standard.

It’s important to understand that DMN is a relatively young standard. Ensure you understand the scope of the standard. It does not address lifecycle management, data mapping or business matters other than decisions. Although, DMN is still sufficiently extensible: it allows tool vendors to provide features of value around it (such as lifecycle management, scripting support, and more).

DMN’s machine learning interface is still developing and does not attempt support explainable machine learning. Furthermore, means of connecting DMN models to business glossaries, motivation models or data models is still evolving.

Every decision management or modeling project is unique.

The functionality offered by any DMN tool cannot be measured in a binary fashion. Nor can it be represented simply as a checklist of items which are part of the tool repertoire. It cannot be described on a single, graduated path either, because there are many independent aspects of functionality that may be more applicable in some business scenarios than others.

Follow the link below and experience how the DMN can be used within your unique business context, to assess and assist you in developing better business opportunities.

EXPERIENCE OUR INTERACTIVE USAGE SCENARIOS

Why separate decisions from process, and why are they different?

Modeling decisions as a process, while possible, leads to very complex and difficult to manage processes. Not least because decisions tend to have a different change frequency to processes. Separating the two and representing decisions in DMN has multiple advantages, specifically re-usability, maintainability and suitability of representation. Often decisions are misrepresented as processes. For example, routing and assignment of work.

In fact, many decisions don’t require a process at all. The vast majority of larger real-world decision automation implementations are not orchestrated by BPM workflow and should be assumed to be fully independent of BPM.

BPMN Workflow tools are seldom used to orchestrate larger decision automation problems. In fact, with straight-through processing, full automation of a decision dramatically simplifies processes, making implementation in workflow tools unnecessary.

Decisions can be executed in numerous ways:

As batch jobs,
As web services,
As microservices,
Embedded in streaming applications,
Embedded in grid computing,
As APIs,
Orchestrated directly by integration busses,
End-user applications,
Embedded in mobile applications, and more.

Why can’t Artificial intelligence (AI) solve all your problems?

It may seem that manual decision modelling is unnecessary. For example, surely artificial intelligence could learn how to make a decision, in a given case, given an extensive repository of example decision inputs and the correct outcomes (i.e., a training data set)?

So why not train a machine-learning model from example decision data and remove the manual effort associated with “hand-modeled” decisions? Although such techniques are valuable in certain circumstances, a decision-making approach based exclusively on machine learning has several serious drawbacks.

So, while it can significantly increase the power of a decision model to include machine learning sub-decisions, using AI exclusively is unlikely to be a satisfactory approach for decision automation in the foreseeable future.

Require significant expertise to select, train and use; this expertise may not be available.
Have limited transparency and often cannot explain their outcomes.
Are not appropriate in areas where the rules are already formulated, e.g., law, compliance, product definitions.
Are implicitly dependent on the statistical distribution of their inputs; if this deviates from the training data set over time, machine learning models can give incorrect answers.
Cannot easily or reliably incorporate the experience of human experts.
Often require significant amounts of data to train (which may not be available if the decision has no recorded history).
Are poor at handling outliers or entirely novel situations.
May introduce additional regulatory, ethical or compliance implications.

Haven’t organizations already tried to automate decisions with business rules?

While there have been successes, numerous companies have created large and unwieldly sets of rules that became hard to manage and understand.

Organizations have applied business rules technology to automate their decision-making. While there have been successes, numerous companies have created large and unwieldly sets of rules that became hard to manage and understand. Many such rule sets are repetitive and denormalized while established rule analysis and harvesting techniques were slow, expensive and impractical.

A focus on decisions, units of business value, not individual rules, brings the discussion closer to the business. Breaking down complex decisions into a network of sub-decisions simplifies and normalizes the rules while improving their manageability. Structured models of decision-making, unlike lists of rules, can easily integrate machine learning and artificial intelligence into the same approach.

Focusing on decisions rather than the individual rules is also faster, more accurate and more engaging for the business. The detailed logic may be represented as a business rule, but the overall approach is dramatically improved.

Why can’t we do this in a database, code, or Excel?

While providing an immediate way to execute business logic, this approach means that the translation of decisions into executable entities and the subsequent management of decisions was mostly in the hands of IT.

Externalizing decisions (e.g., from a codebase) allows them to be managed (from their inception, to testing, to production and beyond) using a tool amenable to the business, or Business Analysts. Furthermore, this enables decisions to be reused by multiple applications, as well as changed independently from the applications using them.

This approach, which is not unique to DMN, provides greater flexibility for teams closer to the business to effectively manage, understand and maintain the decisions, without requiring IT to translate them. However, tools based on DMN rely on a common and interchangeable way of representing logic and models, thanks to a graphical depiction of decisions and their dependencies in a diagram using only a few shapes. This means that a decision model can be built starting from a blank page (on a physical or virtual whiteboard), and that an existing set of decisions can be represented and documented quickly. These decisions may also be implemented by means of decision tables or other constructs for some applications to execute them.

Even with the best intent, attempts to implement decisions at scale using spreadsheets, code or databases, rather than a Decision Management System, are limited. Important features tend to be overlooked, e.g., testing, business transparency, reusability etc. Would you build your own Database Management System?