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.
It's hard to believe I've been doing BPMN Method and Style training for 10 years. With the introduction of a major new version from one of my tool providers, and plans to bring on another tool, I'm now at work on the 7th - and hopefully last - version of the training content. And it is causing me to reflect on how BPMN 2.0 is actually used today, as opposed to the notions of its creators back in 2009, and what that means for BPMN training.
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.
[fusion_builder_container hundred_percent="no" equal_height_columns="no" menu_anchor="" hide_on_mobile="small-visibility,medium-visibility,large-visibility" class="" id="" background_color="" background_image="" background_position="center center" background_repeat="no-repeat" fade="no" background_parallax="none" enable_mobile="no" parallax_speed="0.3" video_mp4="" video_webm="" video_ogv="" video_url="" video_aspect_ratio="16:9" video_loop="yes" video_mute="yes" video_preview_image="" border_size="" border_color="" border_style="solid" margin_top="" margin_bottom="" padding_top="" padding_right="" padding_bottom="" padding_left=""][fusion_builder_row][fusion_builder_column type="1_1" spacing="" center_content="no" hover_type="none" link="" min_height="" hide_on_mobile="small-visibility,medium-visibility,large-visibility" class="" id="" background_color="" background_image="" background_position="left top" background_repeat="no-repeat" border_size="0" border_color="" border_style="solid" border_position="all" padding="" dimension_margin="undefined" animation_type="" animation_direction="left" animation_speed="0.3" animation_offset="" last="no"][fusion_youtube id="JZp8EgKoXzg" width="1360" height="765" autoplay="false" api_params="" hide_on_mobile="small-visibility,medium-visibility,large-visibility" class="" /]
Decision logic can take many forms: constraint rules, if-then rules, decision trees, decision tables, and more. Over the years, decision management vendors have gradually allowed decision tables to nudge the other forms aside, for a number of reasons. Decision tables are easy for business people to understand. Their logic is declarative, meaning there is no prescribed order of evaluation. They can be analyzed, either by visual inspection or software, for completeness and consistency, meaning every combination of input values generates a consistent outcome regardless of the order of evaluation.
Recently I posted about the looming New Era of decision management. Some will say, "Yes, we know. You've been touting DMN for a year now." That is true. But this week something changed. What changed is the release of the first complete implementation of the standard, from Trisotech. Their crack marketing staff assigned it version number 5.1.10, like it's nothing much. But trust me, it's a big deal. Let me explain why.
Today I am launching a brand new version of DMN Method and Style Basics training. This one is based on the latest iteration of Trisotech DMN Modeler, which is the first software available to support all five of DMN's key elements: DRDs Decision tables FEEL, including all built-in functions and operators Boxed expressions, all of them: invocation, context, relation, plus of course literal expression and decision table XML interchange, per the DMN standard Oh, and did I mention execution?
Today the world of decision management finds itself in roughly the position of business process management a decade ago: A shrinking number of highly optimized tools and runtime engines, each with its own modeling notation and execution language, struggling with inefficient translation of "business requirements" into executable decision logic. The solution then for BPM vendors was to unify modeling and execution in a single tool-independent language based on a standard diagramming notation.
Every discussion of DMN these days seems to begin with some declaration of what “business users don’t like.” They don’t like FEEL. They don’t like boxed expressions. They don’t like BKMs. They don’t like contexts. They don’t like names with underscores, or, heaven forbid, camel case! They don’t like parentheses to define a numeric interval excluding the endpoints. They don’t like hipsters, Obamacare, or Hillary’s email server. What they do like about DMN, by universal agreement, is its use in classification decisions.
With the Decision Model and Notation (DMN) standard, the Object Management Group (OMG) is hoping to replicate its signature success story, BPMN. Unlike most OMG standards, both BPMN and DMN are purportedly aimed at business users rather than developers and architects. Business users are notoriously averse to standards, so BPMN’s achievement of high business user adoption is surprising. Naturally, that success has spawned legions of critics as well, who say it’s too complicated for business users, too many icons and symbols, too many rules for what’s correct and incorrect.
