DecisionCAMP 2017: DMN Day

The first day at Decision CAMP 2017 is focused explicitly on the Decision Model and Notation (DMN) standard.

Alan Fish introduced the ongoing work on 1.2. He quickly summarizes the new features in 1.1 – such as text annotations and a formal definition of a decision service. Then he went through the new features, starting with those that are agreed:

• Annotation columns can be added to a decision table
• Restricted labels to force the use of an object name as a minimum
• Fixed some bugs around empty sets, XML interchange etc.

In addition, several key topics are being worked on. These three issues have not been voted on yet but we are tracking to get these done:

• Diagram Interchange based on the OMG standard approach for this so that every diagram can be interchanged precisely as well as the underlying model. Given how important multiple views are, this is a really important feature.
• Context free grammar is under discussion as it has been hard to make names with spaces, operators etc. parsable. Likely to use quotes around names with spaces and escaping quotes in names etc.
• Invocable Decision Services to allow a decision to be linked to a decision service instead of a BKM. This allows a more complex reusable package of logic. Using Decision Services as the definition allows packages to be defined and reused without forcing encapsulation. This creates several difficult issues to be resolved but we (the committee) is making progress.

Bruce Silver then facilitated a discussion on what people liked and disliked about DMN.

Likes

• Eliciting requirements using decision modeling is more productive, more fun, more rapid than traditional approaches to eliciting requirements.
• The use of explicit requirements helps with impact analysis, traceability at a business level.
• Really brings together an industry across multiple vendors in a positive way – it’s great to have a standard, customers like the idea that vendors are compliant.
• Ability to mix and match analytics, AI, rules, manual decision-making, machine learning, optimization and all other decision-making approaches in a single model.
• FEEL has supporters and has some great features – especially for certain activities like defining decision tables, possible for non-technical users to be very precise.
• Ability for business users to clearly express their problem and share this with others to get agreement, prompt discussion – and to do this at several levels.

Dislikes

• Perhaps too many details too soon, too much of a focus on the meta model and the internals v what a user can see.
• Sometimes the standard is too precise or limiting – not allowing decision tables and output to have different names, for instance.
• Dislike some of the corner case features because they can get people into trouble.
• Not really any good ways to show which kinds of technology or approach can be used in decision modeling – perhaps some icons.
• FEEL has people who don’t like it too, but this is partly because its new and a change and because it perhaps lacks some of the patterns and capabilities needed. More examples would be good too.