ADL vs BPMN & DMN
Orchestrating Systems vs. Being One
TL;DR: This is the one comparison in the series where the other side genuinely executes. A Camunda-class engine doesn’t treat a BPMN diagram as documentation. It runs it, and a DMN decision table evaluates. So the axis of this series (description vs. execution) doesn’t separate us here. Scope does. A process engine owns the process layer and assumes everything else (the data models, the APIs, the auth, the persistence) already exists as systems it orchestrates. In ADL, workflows and rules are two subsystems out of forty, and the engine assumes nothing, because it owns the rest. If you have twelve existing systems and need a process across them, buy a BPMN engine. If you’re building the system itself, the process layer comes included — and it’s fed by the data layer, guarded by the permission layer, and recorded by the history layer, because they’re all one model.
The executable-spec veterans
Give the process world full credit: it reached the “spec that runs” conclusion before almost anyone else, and shipped it at enterprise scale.
BPMN 2.0 is not a drawing convention. It has defined execution semantics (token flow, gateways, events, boundary timers, compensation), and engines like Camunda, Flowable, and their kin execute the XML directly. The diagram the business analyst approves is, to a first approximation, the artifact the engine runs. DMN goes further in its niche: a decision table with hit policies is a genuinely declarative, genuinely analyst-readable specification of decision logic, evaluated directly, testable in isolation. And the operational maturity around these engines (versioned process definitions, migration of in-flight instances, cockpit tooling for stuck tokens) reflects two decades of production hardening.
So there’s no drift lecture to deliver here. Within its layer, the BPMN/DMN world solved the two-artifact problem the same way ADL does: interpret the specification. The question is what’s inside the layer — and what the layer stands on.
What a process engine assumes
Look at what a BPMN service task actually is: a call to something. An external worker, a connector, a service endpoint. The engine advances tokens, manages timers, correlates messages, persists instance state, and delegates every unit of real work to systems that exist outside it.
Which means a process engine presupposes the application layer this series has been about. The order data model with its constraints; the API that mutates it; the auth system that knows who’s who; the permission logic that decides who may do what; the validation that keeps writes sane — all of that must already exist, built conventionally, before the first token moves. The engine is a conductor. Someone still built the orchestra, by hand, section by section, and every instrument carries the usual drift between its documentation and its behavior.
There’s a second, subtler assumption: that the interesting invariants live in the process. Often they don’t. “Total effort commitments may not exceed 100%” isn’t a process step. It’s a data invariant that must hold no matter which process, user, or import script touches the record. Enforcing invariants in the process layer protects only the paths that go through the process. Every enterprise with a workflow engine also has the backdoor script, the admin console, the bulk import that quietly bypasses the diagram.
Where process and rules live in ADL
In ADL, the workflow subsystem is one chapter of the model, not the model. A workflow declares a trigger (a resource event: a creation, a transition), then steps: actions against resources, waits for matching events with timeouts, conditional routing, parallel branches. Instances persist after every step and survive restarts; a waiting instance resumes when its event arrives. Structurally, this is a process engine, deliberately a smaller one than Camunda, with no pretense otherwise.
The difference is what the steps stand on. When an ADL workflow step creates an inspection record, it isn’t calling out to an external system somebody built. It’s dispatching into the same model, where the inspection’s fields are typed, its state machine is enforced, its permissions apply, and its history is recorded. The process layer and the application layer are the same document. There is no integration seam between the conductor and the orchestra, because the specification defines both.
And the invariants live where invariants belong: on the data. ADL’s rules engine evaluates cross-record policy before any write commits (from a workflow, from the API, from a scheduled task, from anywhere) and rejects atomically, with a human-readable message, a regulation citation if you’ve declared one, and a log entry that serves as compliance evidence. The 100% effort cap holds on every path, including the paths no process diagram anticipated. DMN answers “what does this decision evaluate to?”; the ADL rules engine answers a different question (“is this write permissible at all?”) and answers it universally.
The remaining pieces of the process picture are similarly absorbed: state machines cover the single-resource lifecycles that teams routinely over-model as BPMN (an approval flow on one document is a state machine, not a process); scheduled tasks cover the timer-driven work; history and notifications cover the “who did what, and who needs to know” that surrounds every process. Most of what mid-sized applications actually use a workflow engine for decomposes into these parts: each declared, each enforced, each on the same model.
Where BPMN/DMN are simply better
Three concessions, stated plainly.
Cross-system orchestration is their home game and not ADL’s. If the process spans SAP, Salesforce, a legacy mainframe, and two partner APIs, you need an engine whose entire design center is coordinating external systems: connectors, external task workers, message correlation across foreign event streams. An ADL workflow orchestrates within its domain; it is not an enterprise service bus and shouldn’t pretend to be.
DMN decision tables are more expressive and more analyst-friendly than ADL rules. A DMN table with hit policies, FEEL expressions, and side-by-side test cases is a better artifact for complex, frequently-revised decision logic that business analysts own directly. ADL’s rules engine is deliberately a write-guardrail (boolean conditions over the data with defined consequences), not a general decision service. If your organization’s core asset is a thousand-row pricing decision table maintained by analysts, DMN is the right home for it.
Human-task management is deeper in the BPMN world. Task lists, candidate groups, claiming, delegation, four-eyes patterns: Camunda-class tasklist infrastructure is a product category of its own. ADL expresses human steps as state transitions with role guards and notifications, which covers the common cases and stops there.
The sorting question
One question sorts the two cleanly: does the system the process runs across already exist?
If yes (you’re coordinating an estate of existing systems), a process engine is the right purchase, and ADL is irrelevant to that decision. If no (you’re building the system, and the process is one aspect of it alongside data, access, validation, and lifecycle), then buying a process engine buys you the conductor and leaves you hand-building the orchestra. ADL’s proposition is the orchestra with the conductor included, all from one score.
The one-line version
BPMN and DMN execute the process across systems you already built. ADL builds the system — and the process, the rules, the lifecycles, and the audit trail come off the same page.
Next in the series: ADL vs UML, the technology whose failure taught us the most, and why the lesson was “stop generating,” not “stop modeling.”