DMN Demystified: The Decision Modeling Revolution Starts Now!

I caught up with Bruce Silver, well known for his work on business process modeling with BPMN, for his presentation on the Decision Model and Notation standard – DMN. Bruce began by introducing DMN – you can read my DMN introduction here – and emphasized that it is both a model (underpinnings) and a notation (for visual representation).  He identifies 5 key elements in DMN:

• Decision Requirements Diagrams
• Decision Tables
• FEEL
• Boxed Expressions
• Metamodel and Schema

While I would argue that the first two and the last are the most important, Bruce feels all five deserve their place in the sun and that FEEL and Boxed Expressions are particularly under appreciated.

Bruce thinks that one can learn from the history of business process management. In 2000 for instance business process relied on long text requirements diagrams or a poor proprietary modeling tool. In 2005 BPMN fundamentally changed this by standardizing the specification approach but the execution was defined in BPEL. By 2008 this become unsustainable and BPMN 2.0 in 2011 provided both a standard notation with execution specifics and the revolution really began. DMN he thinks will follow the same trajectory with requirements documents being replaced now in 2015/2016 with decision requirements models and decision logic models. These are executable to some degree and can be linked to executable environments but Bruce believes that this will evolve to true executable models in the next couple of years to transform the decision management space.

Bruce went through the various elements, highlighting the key points of each.

• Decision Requirements Diagrams he believes have power because they can include decisions that are human or external, allowing it to describe something larger than a decision service and managed/extended over time.
• Decision Tables are a well-established topic (see Jan Vanthienen’s work for instance) and DMN allows a wide range of tables to be defined in a standard way. There are some constraints but really it just helps standardize things
• FEEL – the Friendly Enough Expression Language – is the third element and is hard to learn about because it is a LANGUAGE. It’s an expression language that references variables defined in the models and produces an answer without side-effects. It has some powerful features for decision-making like iteration, filters, queries, list handling etc.
• Boxed expressions are the next piece. Decision Tables are one kind of boxed expression but this goes beyond it and provides a boxed, laid out approach to expressing decision logic. Bruce thinks this standardized way to show other kinds of language is as important as the use of decision tables.
• Finally there’s a metamodel and schema that will allow interchange of models between tools, a critical element. The new 1.1 specification has a much more robust schema and metamodel.

He discussed the conformance levels in the specification too but the consensus is these won’t matter very much as there’s no official testing of them. The one important element is that there is a subset of FEEL, Simple FEEL, designed to support decision tables only.

What’s missing? Well several things:

• No UI for modeling data
• No business glossary, though the details of one can be captured
• No link to SBVR rules or policy rules
• No methodology (as usual with notation standards)
• Nothing about testing, about actions taken to access data or about execution optimization or error handling.

These areas are where tools can differentiate (though some may come to the standard in the future)

Bruce is working on his own methodology called DMN Method and Style. This is based on his experience with BPMN and aims to standardize some layout and style guidelines for decision tables and to some extent for decision requirements models. But the biggest thing is the focus on a method to develop decision requirements models – how to decompose your decision down based on various structural

Bruce is very focused, quite rightly, on the overall decision as a thing – not just the pieces that can be executed in the process but the overall decision. Sub-decisions may be linked to process tasks for execution, subsets may be grouped into decision services etc etc. But the execution should follow the decision – as Jan said, get the decision right first then develop an implementation pattern.

Bruce seems to think that everyone else thinks decisions should be broken up into pieces in a process framework – while some people do, we (Decision Management Solutions) don’t – we always begin with the decision in mind and model/manage it as a whole. He makes a valid point that such a complete model may have a complex relationship to the process – the whole decision may not be executed in the process and/or several layers of decisions may be worth linking from the process model. This is exactly how we have been doing this for years – build the model for the whole decision, then figure out how to map elements of that to the process.

He wrapped up with a summary of the status – the DMN 1.1 specification is what you need for schema/metamodel information but the DMN 1.0 specification describes the notation pretty well. 10 or 11 tools support DMN (including DecisionsFirst Modeler, Decision Management Solutions’ tool). His book he says will be out later this year and he hopes also to offer training (Decision Management Solutions has already trained 700 or so people on decision modeling and has DMN training coming up in November).