This Is A Custom Widget

This Sliding Bar can be switched on or off in theme options, and can take any widget you throw at it or even fill it with your custom HTML Code. Its perfect for grabbing the attention of your viewers. Choose between 1, 2, 3 or 4 columns, set the background color, widget divider color, activate transparency, a top border or fully disable it on desktop and mobile.

This Is A Custom Widget

This Sliding Bar can be switched on or off in theme options, and can take any widget you throw at it or even fill it with your custom HTML Code. Its perfect for grabbing the attention of your viewers. Choose between 1, 2, 3 or 4 columns, set the background color, widget divider color, activate transparency, a top border or fully disable it on desktop and mobile.

DMN and BPMN: Common Motivation, Different Outcome?

Home/BPMN, DMN/DMN and BPMN: Common Motivation, Different Outcome?

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.

By | 2017-01-03T09:57:13-08:00 January 3rd, 2017|BPMN, DMN|4 Comments

About the Author:

4 Comments

  1. tom.debevoise@signvio.com January 7, 2017 at 6:49 am

    Hi Bruce,

    Excellent post. I think there are some additional points beyond creating a common definition of the process, understandable by all. We run into many companies that have completed ‘process mapping’ exercises in BPMN that did not yield the expected benefits. Most frequently they have used Visio or EA Tools.

    Expected benefits for these enterprise, or division-level efforts included:

    Elimination of Redundancies, Consolidation of Effort
    Impact Analysis for Shared Services
    Understanding Organizational Responsibilities
    More…

    Without some mechanism for connecting standard definitions of Activities, Roles and Systems, these basic process improvements can not be met, even if the diagram correctly depicts the process.

    DMN has a similar nature- it is critical to use shared dictionary definitions for input data.

    Obviously, Metadata is not part of the BPMN or DMN spec, but the tools for creating these diagrams, such as Signavio, can connect these to the diagram.

    Tom

  2. bruce January 7, 2017 at 8:41 am

    Tom,
    Thanks, and I agree with you. DMN does have some metadata – description, links to process, business motivation, etc. It just doesn’t define a glossary/data dictionary, which I agree is a critical component of any DMN “whole product.” It should be in the spec, but with the RTF as constituted now, I would say that has no chance of happening soon. I mentioned the lack of a unity of purpose with DMN as compared with BPMN, and this is one example. Every tool has its own notion of what this glossary should look like. Until vendors come to believe that helping to grow the overall market by standardizing things like glossary is more advantageous than using it as a product differentiator, we’ll just have to view them as proprietary “methodology” not part of the standard.

  3. jamet123 March 2, 2017 at 4:56 pm

    Hey Bruce
    Interesting as always – prompted me to respond http://jtonedm.com/2017/03/02/4-motivations-for-using-decision-models-and-dmn/
    I think there are some good use cases for executable decision models (as well as multiple ways to develop executable decision models) but I think you are undercalling the huge potential for non-executable models.As with BPMN I think many organizations will get a great ROI from DMN without executable models.

  4. jarsenau March 14, 2017 at 5:14 pm

    Bruce,

    Nice perspective on the perceived slow adoption of DMN. My view is the established BRMS vendors will only fully embrace DMN when forced to by their customers or application partners. There are signs of it showing in RFPs but its still early on. This presents opportunities for new vendors to partner with existing to provide DMN modeling capabilities for import into the vendors execution model or own modeling tools. The latter is significant in allowing the established vendor to still differentiate their system.

    Jim

Leave A Comment