One of the most significant aspects of DMN 1.2 is the establishment of decision services as an important and useful feature of the standard. Decision services existed previously but offered little practical utility other than demarking units of execution within a DRD. Today that is just one of five distinct usage patterns for DMN decision services. Usage Pattern 1: As a unit of deployment Perhaps the most important use of decision services is not even mentioned in the spec, but it is implicit in DMN's architecture and a major theme of DMN Cookbook.
Here we go again. We saw this eight years ago with BPMN 2.0. A revision of the standard allows tools to work 99% the same as in the previous version, but adds some new features around the edges. This causes the proprietary tool vendors to howl in unison: Not business friendly! Why can't it work like the earlier version? (Of course their tools are not compliant with the earlier version, either.
The Decision Model and Notation (DMN) standard is changing the practice of decision modeling and management. Up to now, it has primarily been used to define model-based decision requirements handed off to developers for implementation in some other rule language. DMN is good for that, and actually most tools that claim to support DMN cannot do any more than that. But DMN is much more than a language for defining business requirements.
The analysts have mostly missed what's happening with DMN and its potentially disruptive impact on Digital Transformation, but Derek Miers of MWD Advisors gets it right in his latest report, "Decision Management Drives Disruption." What's fundamentally different about the DMN standard is that the standardization and accessibility of the notation is enabling a new wave of innovation... that has managed to overcome many of the limitations of previous attempts to move toward model-driven applications.
By:
Bruce Silver
September 11, 2017
dmn
Read More
The DMCommunity website regularly posts "challenges" through which decision management practitioners and vendors may compare their tools and solutions. The September challenge shows off DMN and FEEL particularly well. Here is the challenge, as stated: A human resource office has information about all employees in every department including: salary, marital status, age, etc. Help the office to create a decision model that for each department calculates minimal, maximal, and average salaries along with a number of high-paid employees using rules like “Salary > 85000”.
By:
Bruce Silver
September 7, 2017
dmn
Read More
In July I discussed the features and benefits of the DMN Technology Compatibility Kit (TCK), which provides an ever-enlarging suite of DMN models, including test input values and expected outputs. The TCK website https://dmn-tck.github.io/tck/ then had 4 DMN tools listed. Now it has 6, as shown below: This is significant because the TCK is the true measure of support for "real" DMN. While OMG allows any tool vendor that can draw something approximating a DRD to claim DMN conformance, that is hardly the criterion for a modeling language standard.
By:
Bruce Silver
September 7, 2017
dmn
Read More
DMN promises something truly revolutionary to the practice of decision management: a tool-independent, directly executable decision language for business users. Vendor implementations that fulfill that promise are emerging, albeit slowly. Unfortunately, many proprietary decision modeling tools have appropriated the DMN name as a marketing decal without conforming to the spirit, much less the letter, of this promise. Officially, DMN Conformance Level 1 requires a tool only to be able to draw a Decision Requirements Diagram and something that looks like a decision table, but does not require these diagrams to be executable or even valid.
An often repeated charge against DMN is that it makes iteration - a key feature of real-world decision logic - too difficult for business users. "It's programming!" they wail. "Business users can never understand this!" But actually, it's not so hard. To iterate a decision in DMN you must start with a list. Iteration simply means performing some bit of decision logic on each item in the list. For example, if you are a bank classifying assets for regulatory compliance, you iterate the classification decision over each asset in the list.
Earlier this year I launched my DMN Method and Style Basics training and certification, based on the Trisotech DMN Modeler with RedHat Drools 7.0 execution built in. That class covers decomposition of the Decision Requirements Diagram and modeling of decision tables, which form the heart of end-to-end decision modeling. But real-world decisions often involve logic that you cannot model with decision tables alone. You need value expressions including functions to handle text, numbers, dates and times, lists and tables.
Newcomers to the Decision Model and Notation (DMN) standard may be put off by the notion of a decision table's "hit policy." What the heck is that? It sounds technical. Add to that the idea that the modeler is supposed to select the "best" one. Too complicated! Well, it's actually not. Here is what's going on. Each row in a decision table is a rule. The columns represent inputs and, at the end, one (or occasionally more than one) output.
