Ask a business-unit manager what they hate about their workflow platform and you will rarely hear “the BPMN semantics are wrong.” You will hear something much more mundane: it takes six weeks to add a field.
That sentence is the whole problem. Somewhere between the manager who understands the process and the system that runs it sits a deployment pipeline, and every change — however trivial — has to travel through it. A new approval step is a development ticket. A changed threshold is a development ticket. A reordered pair of tasks is a development ticket, an integration test cycle, and a release window.
The instinct is to blame process maturity or team capacity. Usually the real cause is architectural: the workflow has been compiled rather than interpreted.
Compiled workflows and their tax
In the conventional IBM BAW pattern, each business process becomes an artefact inside a process application. You model a BPD or a BPMN diagram, bind activities to implementations, snapshot it, and deploy it to a Process Server. The diagram is the deployable unit.
This is a perfectly reasonable design, and for a stable, high-volume, heavily-governed process it is arguably the right one. But it carries a tax that compounds with variety:
- Every variant is a new artefact. Twelve business units with twelve slightly different approval chains means twelve things to model, deploy, version and support — or one heavily-branched monster that nobody wants to touch.
- Change requires the toolchain. Process Designer or Business Automation Studio, authoring entitlement, a snapshot, an environment to deploy into, and someone who knows how to do all four.
- Versioning is coupled to release. The lifecycle of the business rule is welded to the lifecycle of the deployment.
None of this is a defect in BAW. It is what happens when the process definition lives on the server side of the deployment boundary.
The alternative: flows as data
The other option is to move the process definition to the other side of that boundary. Instead of the graph being a deployable artefact, the graph becomes an ordinary record in your application — a serializable, versioned, human-readable JSON document describing nodes, edges, the task each node is bound to, and its configuration.
The workflow engine then no longer runs “your process.” It runs a small, fixed set of generic set pieces, and an in-app router walks the graph, deciding at each step which set piece to invoke and with what payload. Routing becomes a pure function: (graph, current node, event, run data) → next nodes.
The consequence is the part that matters to the business: creating or changing a flow requires zero deployments. A new approval step is a row in a JSON document. Twelve business-unit variants are twelve records, not twelve artefacts.
What makes this work on BAW specifically
The pattern is not a workaround; BAW ships the primitives that make it viable.
External implementations
A user task does not have to be fulfilled by a coach. BAW supports external implementations, where the task exists in the engine — with all of the assignment, teams, escalation and audit machinery that implies — while the interface a human actually sees lives in your application. This is what lets a single generic human-task set piece serve every human step of every flow.
Message events and UCAs
Undercover agents attached to message events give you event-driven entry points and correlation without modelling a bespoke start for each process. The router raises an event; the engine correlates it to the right instance.
The REST surface
Both the newer /bpm/* Workflow REST API and the legacy /rest/bpm/wle/v1/* family expose enough to drive this from outside: start a process with JSON business data, query ready user tasks, claim and complete them, and fire message events. The adapter is small precisely because the surface is generic.
The discipline this demands
Moving the graph into data does not make the hard problems disappear. It relocates them, and if you are not deliberate the result is worse than what you replaced.
A registry, not one-off nodes
The moment you allow “just this once, special-case this node type in the router,” you have reinvented the compiled workflow with none of the tooling. Every node kind a business user can place must be a registered task type with a schema’d configuration contract. New capability means a new registry entry. The builder can only ever offer what the registry declares.
A publish gate that cannot be skipped
A drawing is not a process. Before a flow becomes runnable it must pass validation: a single start, no orphan nodes, no unbound tasks, every node’s configuration satisfying its task type’s schema, every loop guarded by a decision so it can terminate. Warnings may be accepted — but the acceptance is recorded on the version, visible to whoever looks at it later.
Immutable published snapshots
Production must never execute the draft that someone is currently editing. Publishing freezes the graph, the bindings and the configuration into a snapshot, and runs execute snapshots only. This is what makes “flows are data” compatible with audit: the version that ran is still exactly recoverable, months later, regardless of what the draft has become.
Provenance on every write
Each run accumulates a document of outputs. Every write to it should record which node produced it, when, and on whose behalf — enough to reconstruct the decision trail without the live system.
When not to do this
Interpreted flows are not universally correct. If you have one process, it rarely changes, it is subject to heavy external certification, and it runs at enormous volume, the compiled model gives you better performance characteristics and a simpler audit story. The interpreted model earns its keep when you have variety and churn — many similar processes, changing often, owned by people who are not developers.
That is the honest test. Count the variants and count the change requests. If both numbers are small, deploy your diagrams. If both are large and growing, the deployment pipeline is not a process problem you can fix with more discipline. It is an architectural boundary in the wrong place.
What the migration actually looks like
Nobody rewrites a working estate. The realistic path is incremental, and it has a natural order.
Start with the variant explosion. Find the process that exists in nine slightly different versions across nine business units. That is where the interpreted model pays immediately, because you are replacing nine artefacts with one interpreter and nine records. It is also the easiest business case to make, because everyone already knows those nine are a maintenance problem.
Keep the engine doing what it is good at. The temptation once flows are data is to drift toward reimplementing assignment, escalation and audit in your own application. Resist it. Those are precisely the parts BAW does well, has been hardened for, and that your auditors already accept. The interpreted model works because it moves graph semantics out of the engine, not because it moves everything out.
Leave the certified processes alone. If a process has been through external certification, the cost of re-certifying it as an interpreted flow will dwarf the maintenance saving. Compiled and interpreted processes coexist perfectly well on the same engine.
The objections worth taking seriously
“We lose the visual model as the source of truth”
This one is real, and the answer is that you do not lose it — you relocate it. The canvas in the builder is the visual model; it renders the same JSON that the router executes. What you lose is the guarantee that the diagram in Process Designer is what the server runs, which in practice was already weaker than people believed, because snapshots drift from what was last deployed.
What you gain is that the diagram is now guaranteed to match, because there is only one artefact. The picture is a rendering of the data, not a parallel description of it.
“Performance”
Interpreting a graph at run time costs more per step than executing a compiled definition. In absolute terms this is usually negligible — the work in a business process is dominated by human time, integration latency and queue depth, not by the microseconds spent deciding which node comes next.
It stops being negligible at very high volumes with very short processes. If you are running millions of instances a day through a five-step process, measure before you commit. That is exactly the case where the compiled model earns its keep.
“Governance will not accept business users changing processes”
Frequently the strongest objection, and it is not really about the architecture. Note that it applies equally to the compiled model — the difference is that there, the control is a developer exists in the loop, which is a control by accident rather than by design.
The interpreted model lets you make the control explicit: a publish gate that cannot be skipped, immutable published versions, recorded approvals, and a diff between versions that a non-developer can read. That is a better governance story than “a developer looked at it,” and it is auditable in a way that the developer’s attention was not.
What to measure before and after
If you are making this change, instrument the argument. Four numbers tell you whether it worked:
- Lead time for a process change — from request raised to live. This is the number the business feels, and it is the one that should collapse.
- Change requests per quarter — expect this to rise. That is success, not failure: demand was previously suppressed by the cost of asking.
- Deployments caused by process change — should approach zero.
- Proportion of changes made without a developer — the actual measure of self-service. If this stays near zero, the builder is too hard and you have moved the bottleneck rather than removed it.
That last metric is the honest one. It is entirely possible to build a correct interpreted architecture that no business user can operate, at which point you have all of the engineering cost and none of the benefit.
EFTEDRA builds workflow automation on IBM Business Automation Workflow and Claude — assistant tasks and coach views that install into the processes you already run. See what we build, or try the live demo.