Customers

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

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

Practitioners

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

DMN Independence from BPMN

It appears that DMN expression languages were created to facilitate Business Process Model and Notation (BPMN), with the incorrect assumption that decision automation is normally part of a BPMN process. Whereas in our experience with real-world decision automation implementations for larger decision automation problems, they are not usually orchestrated by PBMN 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.

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

Lack of meaningful conformance system

Currently, DMN conformance levels are not well defined to allow for an on-ramp 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 vendors offer.

DMN currently Supports three levels of conformance based on how much of the syntax you use but much is unclear. For example, it’s not clear with boxed expressions and the feel expression language, what level you need to be on to apply them.

No business glossary

DMN does not define a specification or suggest a standard for a business glossary.

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 & 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 for the majority of vendors to replace their implementation with all that DMN defines.

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.