You know the old adage:  If want something real bad, you get it real bad.  If you want something worse, you get it worse.  This comes to mind when I think about the DMN proposed standard.  Why?  There is something about the process that technical standards go through…

I am writing again about the Decision Model and Notation (DMN) specification which is a promising approach to modeling decision logic.  It is designed by a committee.

Committees

A group of people come together to accomplish a goal.  We call it a committee.  It most certainly is not an efficient machine for producing high quality design ideas.  Actually it seem more closely to a troupe of clowns doing slapstick than a machine.  I have participated in that, I know.  There are many different agendas:

The True Believer: This is someone who really really want to make an excellent contribution to the industry.  They work very very hard.  Unfortunately they follow a course set by myths and legends of the last system they designed.  They fear going down the wrong blind alley.  They tend to zealously follow a new, innovative, and possibly untested, direction.  The true believers spends a lot of time on Reddit.

The Gold Digger: This is a consultant who knows that complicated complex documentation of any kind needs a host of experts who can help explain it to people.  Like everyone, they fear ambiguity in the spec, but also they fear incompleteness and simplicity.  Justified by an attempt to be complete, they tend to drive the spec to be endlessly long and complex and to include as many side topics as possible.  The gold digger sticks to Linked In.

The Vendor Defender: The defender knows that the principle risk is that someone else will implement this before they do.  Therefor they contribute copiously when the spec appears to be going in a way contrary to their existing technology investments, but sit back and relax when it appears that the committee is going nowhere.  Their fear is that the spec will be finished before they have resources to implement it.  They tend to quickly bring up all the (obscure) problems with the spec (particularly ones that conflict with their existing approach) but are slothful when it comes to finding solutions that they don’t already have.  The defender watches MSNBC and CNN.

The Parade Master: This is a person who is primarily interested in the marketing value of having a well branded name, a logo, and the ability to claim support by many different products.  Their fear is that nobody will pay attention to the effort.  They tend to push the spec to be very easy to implement in superficial ways in order to claim support and to include all the proper buzz terms in all the right places.  You can find them on Twitter.

The Professor: This is a person from academia who is probably quite knowledgeable about all the existing approaches, even some from ancient history more than 5 years ago.  The professor typically proposes well thought out, consistent approaches without regard to pragmatic aspects of whether the average user can understand it or not.  Their fear is that this effort will needlessly duplicate an earlier one, or fail to leverage an earlier good work.  The professor, beyond blogging, has hacked Siri and Google Analytics together to bring them feeds from The Onion.

Levels Of Conformance

Different people with different agendas work together to make a document that leads the industry in a new direction.  Some want a super complete super detailed, some want everything that works and only things that work, and other want a minimal set just barely enough to glorify the claim to have implemented it.  The solution is to allow for levels of compliance, and DMN is no exception.  There are three levels of conformance:

• Level 3 – implementations must conform to the visual notation guidelines of the spec, both for the overall picture (DRG) as well as for the parts that compose the overall graph (DRD).   There are requirements on the metadata of these parts.  And the decision models must be expressed in the FEEL expression language.
• Level 2 – like above, but the actual expressions can be in a simplified language
• Level 1 – live above except that the actual expressions that there is no requirement on how the conditions that you base the decision on are expressed.  The expressions do not need to be executable, and could in fact be arbitrary pseudo code that looks like a conditional expression but that “are not meant to be interpreted automatically.”

Level 1 compliance is essentially useless for designing a decision model that actually makes decisions for you.  Since the expressions can be literally anything, there is no possibility to design a model once and use it for anything other than printing out and looking at.  Clearly, vendors are making decision tables that work, but they each work differently, with completely different kinds of expressions, and different interpretations.

Even within the areas that are supposedly enforced, there are many optional aspects of the model.  There are diagrams that are listed with the caveat that it is only an example and many other examples would be possible — without stating how those might be constrained.  There are places which actually state that the design is implementation dependent.

This is quite convenient for vendors.  You can take almost any implementation of decision tables, and claim level 1 conformance as long as a make the graphics conform to some fairly basic layout requirements.

What Does the Customer Want?

The purpose of a specification in the goals of the standard.  DMN lists these goals:

• The primary goal of DMN is to provide a common notation that is readily understandable by all business users, ….   DMN creates a standardized bridge for the gap between the business decision design and decision implementation. DMN notation is designed to be useable alongside the standard BPMN business process notation.
• Another goal is to ensure that decision models are interchangeable across organizations via an XML representation.

You want to be able to make decision models that can be created by one person, and understood by another.  The decision logic written by one person must be unambiguous, it must be clear, and it must not be mistaken for meaning something else.  Level 1 conformance simply does not meet either goal to any degree.  The decision expressions can use any syntax, any vocabulary, and any semantics.  By way of analogy, it is a little bit like saying that the message from the designers can use any language (French, German, or Creole) just as long as they use the roman alphabet.  The fundamental thing about a decision is how you write the basic conditions.

Clearly, allowing any expression language — even ones that are not formalized — helps the vendors.  They all have different languages, and the spec does not require that they do anything about that.

It is similarly clear that if you take a model from a level 1 tool, and bring it to another tool, there is no guarantee that it can read it and display it.  Most of the tools require that the expressions be in their own expression language, and so if it is not in that language it will most likely fail to be read.

What Do You Need?

If you are considering DMN as a user, consider what you need.  You are going to invest a lot of hours into learning the details of DMN.