Executable BPMN vs Method & Style

For many years my work has focused on non-executable BPMN using a set of conventions called Method and Style.

In the past year or two I have turned my attention to Low-Code Business Automation, based on executable BPMN. When I wrote my book BPMN Method and Style – over a decade ago! – I imagined that harmonizing executable BPMN with Method and Style would be a natural thing, but that never happened. Now, with a good bit of experience with Business Automation under my belt, I understand why. In this post we’ll look at the differences between non-executable and executable BPMN modeling.

Data

The most obvious difference between the two concerns data. Executable models explicitly define process variables (data objects) and show the data flow in the diagram. Non-executable models do neither. The reason for that is fundamental. The BPMN 2.0 spec does not specify a language for defining process data and expressions, and for years most BPMN tools have used Java. That made executable BPMN accessible to programmers only. But actually, most BPMN modelers are business users, not programmers. They are just looking to document and improve their business processes, not automate them. Method and Style was created with those users in mind.

BPM teams spend countless hours trying to document how their processes work and capture that knowledge in BPMN, but too often the resulting models are understandable only to the person that created them. The challenge for non-executable BPMN is revealing the process logic clearly and completely from the diagrams… to someone who doesn’t already know how it works. You need a bit of data to do that, and Method and Style provides it implicitly using the concept of end states. The end state of an activity or process names a possible way it could end, either successfully or in some exception state. With processes and subprocesses, we use a separate end event labeled to indicate the end state. Method and Style says that an activity – task or subprocess – with multiple end states must be followed by an XOR gateway with gates labeled to match each end state. These labels reveal, at a basic level, the conditions under which any instance follows a particular path through the diagram.Executable BPMN works differently. Here the goal of the model is executability on a BPMN engine, and this requires explicit definition of process and task variables. You can still label gates and end events as end states, but these labels are just annotations; what counts in executable routing is a boolean condition on process variables attached to each gate.

Executable BPMN distinguishes process variables from task variables. Process variables are defined by the modeler and visualized in the diagram as data objects, data inputs, and data outputs. Task variables do not appear in the diagram. They are properties of each task, and for some task types are not defined by the modeler at all but by an invoked REST API. The modeler must map process variables to and from the task variables. On the Trisotech platform, both process and task variables are converted to FEEL data, so the data mapping is Low-Code, using FEEL and boxed expressions borrowed from DMN.

A final data-related difference between Business Automation and Method and Style is the need for data validation and error handling in executable models. To avoid runtime errors, executable BPMN cannot assume data inputs are complete or valid. In Method and Style we don’t worry about that.

Task Types

A second key difference is task types. In Method and Style we pay almost no attention to task types, except to distinguish human from automated tasks. Often modelers don’t assign a task type at all. In executable BPMN, task types are essential, as each task type performs a specific function. A task without an assigned task type does nothing.

• A Service task executes an external REST API catalogued in the model’s Operation Library, as described previously.
• A Decision task (in the tool called a Business Rule task) executes modeler-defined business logic in the form of a DMN decision service.
• A Script task executes simple modeler-defined business logic – a single FEEL literal expression.
• A User task routes a task form to a human performer and returns its output to the process.
• A Call Activity executes modeler-defined process logic in the form of a BPMN process service.

Each task type has its own configuration details, but all use the same Low-Code data mapping. In a Service task, Decision task, or Call Activity, the task inputs and outputs are defined by the invoked API, not by the calling process. In a Script or User task, the task inputs and outputs are defined by the process modeler.

In executable models, Service, Script, and User tasks are extremely fine-grained. While in Method and Style an automated task (typically represented as a Service task) can be imagined to perform a complex action containing multiple discrete operations, in executable BPMN a Service task is limited to a single service operation. That means that a complex automated function is more likely implemented as a Call Activity, a process involving a sequence of Service tasks. User tasks are similar. While in Method and Style a User task is imagined to perform complex human activities involving multiple system interactions, an executable User task on the Trisotech platform is a single task form and involves no system interactions. Again, a complex human task would be modeled as a process invoked by a Call Activity.

Black-Box Pools and Messages

In Method and Style we use message flows from and back to a black-box pool to represent the process request and final status response. Executable BPMN doesn’t have a clear implementation of black-box pools. Instead we use data inputs and data outputs. On the Trisotech platform, processes are deployed as REST services, so a process request is the same as a call to the Execute operation of that service. A data input represents the data provided in that request, and a data output represents data returned to the requesting client upon completion. The identity of the requesting client – the black-box pool in Method and Style – is immaterial. Any client with the appropriate bearer token can request the service.

I have previously described a mechanism in Trisotech by which a message flow from a black-box pool to a start event may substitute for a data input and a message flow to a catching message event can trigger process behavior. Outgoing message flows to a black-box pool are more of a problem, because unlike Method and Style, where these mean any communication to the external entity, a process cannot really send a “message” to an abstract entity. Instead, a Send task or throwing message event can be configured to send an email to a user. It’s not really the same thing, and in my own processes I tend to use a Service task from the Trisotech Connectors Library to send emails.

A Common Language Nevertheless

Despite these differences, which are not insignificant, BPMN remains a common language shared by modelers documenting processes and those automating them. Below you see two versions of a Vacation Request process. The first is based on Method and Style, with black-box pools and message flows, end state labels, and simple distinction between human and automated tasks.