DMN and BPMN: Common Motivation, Different Outcome?

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. But we need to add that most of those critics are either vendors of proprietary tools made obsolete by BPMN or graybeard practitioners whose conception of a modeling tool stopped at whiteboards and yellow stickies.

The key to BPMN’s acceptance by business users is its outward similarity to traditional swimlane flowcharts: boxes representing actions, connected by arrows representing sequence in time, arranged in swimlanes indicating the actors performing the actions. That basic look was a conscious choice by BPMN’s creators, and it has worked very well.

But you have to ask, what has motivated all those business users to give up Visio or Powerpoint flowcharts in favor of the admittedly more demanding notation of BPMN? Having trained almost 5000 modelers on BPMN over the past decade, I think I can answer that.

Two things. First, the need to visually communicate the process logic, clearly and completely, to all stakeholders, not just to the immediate project team. Basic drawing tools like Visio and Powerpoint are easy to use because they place no demands on the modeler. Those tools have no idea what a process diagram means; they expect the modeler to know what it means. But different modelers mean different things, and so effectively the diagram is really a sketch, a rough idea of the detailed process logic described in some long text document. But text documents inhibit collaboration. In effect, the meaning of a traditional flowchart is clear only to those that already know how the process works. BPMN, in contrast, defines the meaning of a process diagram in a specification. Its meaning is independent of both the modeler’s imagination and the tool used to create it. So a BPMN diagram can communicate process logic on its own, clearly and in detail, to those who don’t already know it.

That’s the first thing. The second thing has to do with process models used as business requirements for automation of the process flow. Although the majority of BPMN models are not used for this purpose, a decade ago process automation vendors like IBM, Oracle, and SAP felt the need to embrace the standard and make it serve their purpose by spearheading BPMN 2.0. With BPMN 1.x, process models created by business analysts and BPM project teams were handed off to developers, who translated them for execution into a slightly different language called BPEL. This was when process automation vendors thought BPM and SOA were the same thing. Ha! No, that didn’t work, because BPEL and BPMN are not the same. Things got lost in translation, and business users felt that what they had specified in their model-based requirements was not what was implemented in BPEL. BPMN 2.0 unified the modeling language and the execution language, allowing the business to collaborate directly in the implementation.

The lesson of BPMN 2.0 was clear: What You Model Is What You Execute. Keith Swenson called it WYDIWYE. That’s what business users want, or “say” they want. But the other side of that coin is that collaboration with IT on implementation demands the business adopt a more disciplined approach to modeling. And that requires going beyond the flowcharting that the business users already know. It requires a bit of training, model validation built into the tools, things like that. That’s been my world for the past 10 years.

OK, so let’s look at DMN. It’s brand new. Honestly, tools that fully implement the standard are not yet available. It’s like BPMN was in 2005. The key to DMN’s adoption by business users is its use of decision tables. Decision tables have been around for decades, and popular with business users. DMN imposes some constraints on their format and the syntax of what goes in the table cells, but for classification decisions, the most familiar type of decision models, a business user with no training at all can mostly understand what a DMN decision table means.

The second point – model-based “business requirements” for IT – is even more compelling for DMN than it was for BPMN. With BPMN, only a small fraction of modeling projects are intended for automation in an engine, but with decision models, that fraction is closer to 100%. For years, decision management teams created text-based business requirements and handed them off to IBM or Drools programmers, with much of the same frustrations and delays that afflicted BPMN in the BPEL era. The big change came about through innovations like The Decision Model of von Halle and Goldberg, which not only advocated but conclusively demonstrated that business users can create and maintain model-based decision logic themselves, following a disciplined methodology, and thereby improve implementation speed and quality significantly.

But TDM was still about making decision models into requirements for programmers, albeit verifiable and maintainable by the business. It had no execution engine (although Sapiens now offers one), but it proved that business users can embrace a disciplined approach to decision modeling and gain great benefit from doing that. DMN picked up this ball and ran with it, creating a standards-based decision modeling language, mostly defined using diagrams and tables, and directly executable on an engine. What You Model Is What You Execute! That’s the key.

That’s kind of where we are today: The outward familiarity of decision tables, combined with the promise of WYDIWYE. But delivering on that promise is hard. It took BPMN from 2003 – remember the book BPM: The Third Wave? – until 2011 to get to BPMN 2.0. DMN is only a year or two into that cycle.

And there is an important difference in the tool vendor dynamics today with DMN than we had back in 2008 with BPMN. In 2008, process automation vendors had been marketing BPM as “business-driven,” but they could see that handing off models for translation into a different language wasn’t working with business users. Modelers wanted WYDIWYE, so the leading vendors actually drove development of a standard that would replace what they were currently selling.

With DMN, however, we don’t have that same unity of purpose. Not all vendors developing DMN tools are aiming for WYDIWYE. Some see DMN as stopping at a model-driven requirements language, a standards-based equivalent to TDM. The models would be verifiable – much better than text-based requirements – but they would still need to be translated into some other rule language for execution. As a consequence, some on the standards committee don’t see the value of making the complex parts of the DMN language more consumable by business users, such as replacing certain FEEL syntax with diagrams and tables, sub-DRDs, and so forth. Others do see the bigger picture, including WYDIWYE. This is the basic debate going on now within the DMN 1.2 task force, where forward progress has been slow. So whether DMN can achieve adoption similar to BPMN remains an open question.

Of course, the emergence of an enterprise-class DMN runtime engine would be a truly disruptive force in the market. It would change things.

We don’t have that yet. But it’s coming.