DMN Demystified, Part 1. Retracing the Path of BPMN

This post is based on a talk I gave at the BBC conference in November.

DMN, which stands for Decision Model and Notation, is a relatively new OMG standard. By unifying business decision modeling and execution, it hopes to do for Business Decision Management what BPMN did for BPM over the past decade, which is radically transform the business. Like BPMN, it is intended for business analysts and business users, not programmers. And like BPMN before it, we can already hear the fearful warnings of proprietary tool vendors: “But it’s too hard for business users. They should just stick to creating requirements documents and leave the real decision logic to programmers.”

DMN has five key elements:

  1. Decision Requirements Diagram (DRD)
  2. Decision tables
  3. FEEL, a new expression language
  4. Boxed expressions, a visual representation of complex decision logic
  5. Metamodel and XML Schema
First-generation DMN tools offer items 1 and 2 only, so most people think that’s all there is to DMN. But for DMN to fully achieve its objectives, we need tools that support all five.DMNpath

In many respects, DMN is retracing the path of BPMN a decade ago. It’s worth reviewing that history as a guide to DMN’s future. Around 2000, process automation was based on proprietary software. There were no standards. Business requirements were created in a combination of text documents and proprietary modeling tools included in the runtime.

Five years later we had BPMN 1.x, a process modeling notation standard widely adopted by business users. BPMN 1.x was not executable; it had to be translated into some other language by programmers for execution. Since we also had an industry-standard process execution language called BPEL, the BPM vendors thought this would convince customers that BPMN was the “business face of SOA.”

OK, that didn’t work out. The need to translate models into some other language for implementation was the basic problem, and a few years later we had BPMN 2.0, which made the modeling language and the execution language one and the same.

In decision management, shift the clock ahead by a decade. Before DMN, decision requirements were – and mostly still are – formulated in unstructured text or captive proprietary modeling tools, translated by programmers into a different language for execution. DMN is trying to unify standards-based modeling and execution in one step. It’s still early, but first-generation DMN tools for now seem content with a BPMN 1.x-like approach, creating model-based requirements handed over to programmers for translation into a commercial BRE rule language. In the BPMN world, that worked for about 4-5 years, so we’ll see.