Challenges facing THE ADOPTION OF DMN

DMN as the global standard for decision modeling, requires the mass adoption of the system in order to better organise and manage the industry globally.

Current challenges facing the adoption of the DMN

DMN is a powerful and flexible standard for representing decisions, but for clients, vendors and practitioners adoption is harder that it should be for the reasons shown below.

 

Challenges Customers

CLIENTS

Companies using DMN do not have a meaningful way of understanding what features of DMN vendors are offering and what they should be looking for.

Challenges Vendors

vendors

Vendors do not have a feasible on-ramp to adopting the DMN standard, a way of demonstrating a credible level of compliance, and the ability to provide reasonable value with DMN

Challenges Practitioners

practitioners

The DMN standard does not provide Practitioners a way to separate technical parts of the standard from requirements gathering and architectural considerations.

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

the Specific challenges with DMN adoption we intend to resolve

Below we summarize the key hurdles to easy DMN adoption. These are hindering the use of DMN in cases where it could be extremely useful. The committee is working to address these issues.

DMN Independence from BPMN

It appears that DMN expression languages were created to facilitate the Business Process Model and Notation (BPMN), with the incorrect assumption that decision automation is normally part of a BPMN process. However, in our experience with real-world decision automation implementations for larger decision automation problems, they are not usually orchestrated by BPMN based workflow tools and should be fully independent and on a level with the BPMN specification.

Decisions can be executed in numerous ways; as a batch job, as web services, as microservices, from streaming tools, in grid computing, as API’s, orchestrated directly by integration business, end-user applications, and more. Workflow tools with BPMN and case tools are seldom used to orchestrate larger decision automation problems.

Lack of meaningful conformance system

Currently, DMN conformance levels are not well defined to support adoption and are perceived to be all or nothing. Organizations that intend to leverage DMN, need a meaningful way of assessing the features of DMN that they need and that vendors offer.

DMN currently supports three levels of conformance based on how much of the syntax you use. But this stark partition was an historic distinction for vendors of DMN tools. It has little to do with the different ways clients use DMN or the features they need to support these different approaches.

Too technical

DMN attempts to define too much of what vendors consider to be technical implementation details and does not separate technical implementation details from requirements gathering metaphors and expressions. The DMN specification, unlike the BPMN specification, attempts to define its own expression language.

DMN is a broad standard that includes data definition and manipulation, a coding language, decision artifacts, visual artifacts, and more. Established vendors already have fully defined expression languages, and ways to manipulate data. For various reasons, it is not feasible (or necessary) for the majority of vendors to replace their implementation with all that DMN defines.

Vague on Data Definition
DMN does not define a specification or suggest a standard for an object model or a graphical representation for data modeling.
The provided structured types may be insufficient for most vendor implementations.
No business glossary
DMN does not define a specification or suggest a standard for a business glossary.
Too complex for business users
The lack of separation of requirements gathering metaphors from technical implementation details such as FEEL language and boxed expressions does not lend itself to business usage and general adoption by the business analyst, operations, or subject matter expert communities.