In a recent article on the LinkedIn Group ‘The Decision Model and Notation (DMN)’, and on his own blog, Bruce Silver elegantly described why DMN is different to (and better than) other means of representing business decision models and asserted that these differences are set to make DMN of crucial importance to businesses that rely on their operational decisions. While I agree with Bruce’s feature list, I have some reservations about some of his observations.
Bruce asserts that DMN is important because it has the following attributes:
- Designed for business users, not programmers. The logic is described entirely using diagrams and tables.
- Rich enough to handle real-world decision logic. Not a toy.
- Decision logic is verifiable and executable. What you draw is what you execute.
- Standardized. It works the same in any tool.
I completely agree that DMN’s ability to represent business decisions in a format that is simultaneously unambiguous, standardized, transparent to business experts and executable is the game changer. I think Bruce has put the case very well. DMN allows businesses to build a ‘living (executable) embodiment” of their business decision specifications that do not require explicit translation into an executable format. This means that they can
- remove a major source of errors (the translation process)
- encourage their business domain experts to experiment with (‘kick the tires’ of) decision logic through simulation – helping them to better understand and continuous improve the decision
- maintain the transparency and accuracy of business decisions and logic through many cycles of change – the specification of the logic remains ‘up to date’ by definition.
Bruce quite rightly mentions the challenge of maintaining business transparency of complex executable decision models. I think this is the true test—both of the standard and its users. In our experience, overuse of FEEL can look awfully like programming and move away from the ‘purely visual’ approach Bruce mentioned. On our DMN courses, we’ve seen some newcomers get carried away with FEEL. As with every other flexible medium, the “keep it simple” (KISS) principle applies. FEEL’s more advanced features need to be used only when there is no simpler means of representing the logic. We give some examples and best practices for this in our book.
One area where I think I would disagree slightly with Bruce’s article is when he says “the logic is described entirely using diagrams and tables”. Decision Tables are just one way to represent logic, one key difference of DMN is that it opens the door to many other representations of business decision logic, for example, analytical models. It’s possible (and highly useful) to use DMN to frame, analytical, optimization (and even cognitive) decisions and to use other formats to represent logic. Although there is room for further development of the standard in these areas, I think it’s too restrictive to consider that decision models are “described entirely using diagrams and tables.”
This aside, I can highly recommend Bruce’s article. Although, I would say that DMN has eight key differences that ultimately make it the decision modeling standard of choice:
- It’s an open, public standard–essential to support better collaboration with others
- It’s designed for use by business subject matter experts not just IT
- It’s precise and unambiguous – it can make your decisions accountable and transparent, but unlike businessrules it scales
- It’s executable–a decision model can’t get out of date because it is simultaneously a specification and and implementation
- It’s extensible – support means of representing logic other than Decision Tables
- It’s widely supported – over 16 tools available and growing.
- It has the richest set of features
- It’s been designed by the combined expertise of six leading vendors.