A Standard for Low-Code Business Logic

Here’s a thought:
What if the greatest opportunity for DMN is not decision management?

Over the past year, I have come to this conclusion, and that greener pastures lie in the direction of Low-Code Business Logic. Its addressable market is far larger, and there is less organized resistance among incumbent vendors than DMN faces in its home territory. In fact, I will assert that DMN should be considered the standard for Low-Code Business Logic. Allow me to explain.

Decisions, obviously, are a category of business logic. Both exist exclusively within the domain of data. Data in, data out: Decisions directly perform no actions, which are handled instead by process activities. In fact, DMN technically requires that decisions have no “side effects”, meaning they leave no persistent mark upon the world. The output of a DMN decision, given the same set of input values, is always the same.

Decisions are burdened with an additional connotation, however, as a question whose answer is some enumerated value. This is an explicit attribute of a DMN decision, and it figures largely in the methodologies of some practitioners. It is expressed visually in DMN’s most familiar construct, the decision table, representing if-then, or rule-based, logic. But rule-based logic is not fundamental to DMN, just a historical bias. It is an artifact of the evolution from expert systems to business rule engines to what we now know as decision management. Not so long ago, business users were exhorted to go forth and “harvest” the knowledge hidden in spreadsheets, legacy COBOL, and the heads of subject matter experts, and turn that into business rules that could be centrally managed, maintained, and ultimately automated on business rule engines. But it turned out that managing isolated business rules collected from disparate sources required a vast infrastructure of structured business vocabularies and was not very efficient. Moreover, rule engine technology dealing with rules that create other rules required complex algorithms such as Rete to give acceptable performance.

That led to the “decisions first” rebellion, led by James Taylor, Larry Goldberg, and others, who proposed new methodologies in which decision models – not rules – were primary, necessitating discovery of only the rules those decisions require. The concept of a decision requirements diagram (DRD), decomposing the logic of a complex decision into a cascade of simpler decisions, business knowledge models (BKMs), and input data, became the starting point, and DRDs together with decision tables became the centerpiece of a new standard, DMN. But executable decision logic, it turned out, needs more than DRDs and decision tables. Although the top-level decision in a DRD, when conceived as a question with an enumerated set of possible answers, often takes the form of a decision table, that is not the case for the supporting decisions. Their job is to “refine” the raw input data into the variables tested by the top-level decision table. The logic of those supporting decisions is typically not based on rules. Instead it performs things like mathematical calculations, data validation, data aggregation and formatting.

When the DMN standard was created, the question of how to handle such non-rule-based decision logic was controversial. Many vendors in the task force had business rule languages that handled that logic perfectly well already. Adding DRDs to the platform was easy, so that is all they wanted DMN to do. But this posed two problems:

In the traditional arrangement where business creates requirements handed off to programmers for implementation, neither issue was seen as a problem, just business as usual. But for the majority of the DMN task force, it was not enough. They wanted all of the decision logic to be definable by non-programmers, what today we call Low-Code. And that is what emerged in the DMN standard, although it permitted traditional rule vendors to claim DMN Level 1 conformance simply by supporting DRDs and decision tables.

Low-Code means model-driven.

Instead of programming statements, the variables used in the executable logic are created graphically, in the form of diagrams and tables. In addition, the value expression (internal logic) of each decision or BKM is also defined graphically in the form of standard tabular formats called boxed expressions. Decision tables are one type of boxed expression, but DMN provides others: context, invocation, relation, etc. In each boxed expression type, certain cells define variable namesand others a formula for their value. But no matter how finely you decompose the logic into diagrams and tables, ultimately you need some kind of expression language to compute the value of a table cell. An expression language does not define variables; it merely computes their value based on formulas. Here, DMN found the need to invent its own, called FEEL. The combination of DRDs, boxed expressions, and FEEL make almost any decision logic accessible to non-programmers. FEEL is both business-friendly – much friendlier, for example, than Microsoft’s Power FX, the expression language of Excel and PowerApps, as I have demonstrated previously – and powerful, with an impressive array of built-in functions and operators and user-defined functions.

When DMN 1. 0 came out, many rule engine vendors welcomed DRDs but had no interest in boxed expressions and FEEL, and that remains the case today. Their runtime engines still require their own proprietary rule language, and their business models remain IT-centric. Moreover, implementing boxed expressions and FEEL is not easy. The labels of the various shapes in the DRD – decisions, input data, and BKMs – become the names of the FEEL variables used in the executable logic. These typically contain spaces, so just parsing FEEL is non-trivial (although Red Hat’s FEEL parser has been open source for years). And boxed expressions are no less a challenge, since they require the ability to nest boxed expressions inside other boxed expressions, tables inside tables. These implementation challenges explain much of the resistance to DMN within the incumbent vendor community.

So let’s talk about the greater opportunity, Low-Code Business Logic, which together with service orchestration underpins the move to Low-Code Business Automation. Interest in Low-Code Business Automation is exploding, driven by digital transformation, moving business online, and rapidly escalating customer expectations. Technologies such as the cloud and proliferating public APIs are further stoking the pace of change. Gartner projects the Low-Code market to more than triple between 2021 and 2023, and that by 2024, 65% of all development will be Low-Code!

Low-Code’s key benefit is time-to-value.

It simply is much faster to develop applications and services using models than with code. In addition, it reduces the demand for scarce programming resources. Technical business users can create solutions themselves, or at least the part of those solutions that involves business logic, giving IT the responsibility of ensuring performance, security, and the like.

It turns out DMN is a perfect language for the business logic portion of Low-Code Business Automation. There is nothing in DMN that presupposes business rules or questions with enumerated answers. DMN provides decomposition of complex logic using DRDs. It provides graphical logic definition using boxed expressions, and a powerful business-friendly expression language in FEEL, allowing users outside of IT – what Microsoft now calls “makers” of software – to define and build applications and services themselves. In addition to business logic, Low-Code Business Automation also requires Low-Code process logic. But BPMN can be made Low-Code as well by borrowing boxed expressions and FEEL from DMN, as Trisotech has done. This is the greater opportunity.

We must not lose sight of the fact that DMN is a standard. The DMN spec is not owned or controlled by a single vendor, and the intellectual property is free to use. The standard is managed by a proper standards body according to strict procedures and protocols. Membership in the DMN task force is open, and updates to the specification are based on majority vote. The spec defines:

• The names, semantics, and operational behavior of each model element, including the DRD elements, boxed expression types, and FEEL elements. The semantics are enforced by conformance to the DMN metamodel and schema, supplemented by language and tables in the spec
• The graphical shapes and symbols used in the diagrams and tables, and their binding to the semantic elements
• A formal grammar for FEEL, supporting generation of compilers for the language
• Formal definition of FEEL datatypes, including their mapping to types in other languages
• A large set of built-in FEEL functions and operators, with examples and usage patterns
• A model interchange format based on XML Schema generated from the metamodel. The format supports vendor-specific extensions, defined explicitly as extension elements.

This is what a real standard must provide. Based on this, users enjoy a number of benefits:

• Avoidance of vendor lock-in. Valid DMN models (without vendor extensions) have the same meaning and operational behavior in any conformant tool. In other words, they return the same answer.
• Interoperability between tools. Business users and developers can use different tools and share models between them.
• Vendor-independent experience and expertise. Information and training about DMN is available from multiple sources; users are not dependent on their vendor for this.

Hopefully I have convinced you that DMN is a standard for Low-Code Business Logic generally, not just rule-based decision management. Remember, DMN is more than FEEL. It is the combination of DRD (logic decomposition), boxed expressions (graphical logic definition), and FEEL (a powerful but business-friendly expression language). But I am further asserting that it should be considered the standard. Some have suggested Excel and its expression language Power FX is a better candidate. It’s pervasive, of course, has many built-in functions, and for very simple models is easy to use. But it lacks almost everything else you need. It has no logic decomposition. It has no formal specification, metamodel, or tool-independent interchange format. The syntax of PowerFX in Excel is not the same as for PowerApps, and for handling the kind of data used in complex decision models, it is far inferior to DMN.

Do you have another candidate? If so, let me know. I’d like to find out more about it.

While DMN came from the decision management world, I still believe that Low-Code is the greater opportunity. There are a good number of Low-Code application development platforms today, mostly focused on CRM and HR apps. Almost none of them are standards-based; there is not yet a demand for that. DMN, in combination with Low-Code BPMN, opens up Low-Code Business Automation beyond CRM/HR to complex, event-driven, high-volume processes used in loan origination and servicing, investment management, accounting, insurance, and healthcare. I believe the latent demand for standards-based platforms is higher there. Let’s make it happen!