BPMN originated back in 2002-2003 at the dawn of a new technology, web services. Before then, not only were there no standards for BPM tools, but human workflow and application integration required separate and distinct technologies. The startup Intalio created the Business Process Modeling Language (BPML) that used web services to combine human and automated tasks in a single process model. That was revolutionary in itself, but they went further. BPML would be created graphically by non-programmers using a standardized flowcharting notation called BPMN. Swimlane flowcharts had been in common use by the process improvement community since the 1980s, and basing BPMN on that conceptual framework was intended to attract the interest of business users. It worked! There was even a book written about it, BPM: The Third Wave by Fingar and Smith, that created a mild sensation back in 2003.

But Intalio was actually too early, as the key web service standard WSDL was not yet final, and when it came out, BPML was incompatible with it. Instead BPML was replaced by a similar process automation language called BPEL from IBM and Microsoft. Those vendors had no interest in business user empowerment and hence provided no graphical notation. But BPMN remained popular with business users, so process automation vendors continued to use it, even without BPML. Increased availability of inexpensive – sometimes free – BPMN tools made it especially popular among business users looking simply to document their processes, with no interest in automation at all.

For automation vendors, the original promise of BPMN to business – What You Draw Is What You Execute – was not really true in the BPEL era. But in 2008-2009, IBM, Oracle, and SAP needed a way to make it true in order to gain business support for large-scale IT projects based on Service Oriented Architecture (SOA). The result was BPMN 2.0, which made the BPMN notation a true standard, maintained by a real standards organization (OMG), with formal procedures, well-defined semantics and operational behavior, a metamodel and schema, the whole thing. The semantics and operational behavior had to be well-defined because now BPMN models were automatable on a runtime engine.

Now let’s turn to DMN, which came out in 2015, several years after BPMN 2.0. Like BPMN, DMN took as its conceptual framework an idea that was already popular: “Decisions First”, meaning decomposing a complex decision, top-down, into a hierarchy of supporting decisions. This approach stood in contrast to the older “Business Rules” approach based on harvesting rules from a vast array of legacy systems and subject matter experts, and later assembling the rules, bottom-up, into decision logic of some utility. What DMN calls a Decision Requirements Diagram (DRD) did not originate in DMN, but had been articulated well beforehand in James Taylor’s Decision Management Manifesto, The Decision Model by Goldberg and von Halle, and Knowledge Automation by Alan Fish. This is important, because just as swimlane diagrams do not imply BPMN compliance, not every tool supporting the DRD concept is DMN-conformant.

DMN distinguishes decision requirements from decision logic. Decision requirements, captured as DRDs, are intended to be created by business users. In that diagram, each decision is represented as a rectangle, with incoming arrows representing the inputs to its internal logic, i.e., other supporting decisions and input data. Decision logic means the expressions that transform the input values into the output values. It’s the thing that makes the decision model executable. For reasons I don’t pretend to understand, DMN took a step that BPMN dared not even suggest, which is that decision logic should be created by business users as well. I say I don’t understand it because, looking around today, I see few DMN vendors that support that notion… Trisotech being the notable exception.

To enable that, DMN defined a set of standard tabular formats called boxed expressions. One type of boxed expression, the decision table, was also a pre-existing conceptual framework, but DMN introduced several other new boxed expression types. Boxed expressions are challenging to implement, because tables may be nested inside other tables. But the real implementation challenge was FEEL, a new business-friendly expression language for the text to go in the cells of those tables. A major issue for FEEL implementation was that the variables in its expressions are the names of the decisions, input data, and other elements entered in the DRD, even though these contain spaces and punctuation absolutely forbidden as variable names in almost every other executable language. Even after Red Hat made their FEEL parser and DMN runtime open source, many vendors remained reluctant to support it.