Skip to content
Menu
Lucky's Bookshelf
  • Browse
  • About
Lucky's Bookshelf

Book Summary: Real-Life BPMN by Jakob Freund and Bernd Ruecker

Posted on September 19, 2026September 19, 2026
Topics: Software Engineering

Rating: 8.4/10.

Book written by the co-founders of Camunda about BPMN (leaders of executable workflow engines for the enterprise), with the longest chapter about the semantics and mechanics of the BPMN standard. The rest of the chapters include a brief chapter about DMN; best practices for using it in an organization on strategic/operational levels for humans to communicate and executable level for machine orchestration.

Chapter 1: BPMN (business process model and notation), serves to document a business process like an insurance application, with various steps and decision nodes where humans are looped in. The first version in 2004 was modeling only, and V2 in 2011 made direct execution possible with a workflow engine, and the specification is open. DMN (decision model and notation), is a representation of decision tables. There is also CMMN (case management model and notation), but it has had relatively limited adoption.

Chapter 2: A process model is the description, and the process instance is the instance carried out in reality. A task (activity) is a rounded rectangle, and this is the work to be carried out. An event is a circle, can be a start, intermediate, or end, to indicate a state has been reached. Recommend naming tasks V+N, like “prepare meal,” and naming events with N+V, like “meal prepared.”

An exclusive gateway (XOR) is a diamond shape, optionally with an X symbol, for exclusive branching based on a condition, so only one path may be taken, and the same notation is used to merge the two paths later. A parallel gateway is a diamond with a plus symbol; it forks into multiple tokens, once per branch, to execute in parallel, and then the merge waits for all inputs before proceeding. It’s also possible to not merge and continue to have two tokens taking distinct paths in parallel. Data-based inclusive gateways are a diamond with a circle, and they can take one or multiple outgoing paths simultaneously, and this can lead to complications in the merge node, knowing how many tokens to wait for, since some paths may have already ended. A complex gateway can wait for either branch to finish before proceeding, or wait for k of them to finish and discard the rest.

You can model conditional flow like an edge with a diamond to avoid lots of gateways, but one needs to be careful that exit conditions are disjoint, or you might unintentionally generate two tokens that can’t be synchronized. Lanes indicate who is responsible for a task, like a person or department, and there can be a transition between lanes, but each task and event must be in only one lane. The convention is to proceed left to right and top to bottom, with each lane as a row.

Events are what trigger a process, or a process can emit an event to trigger another process, and this can be emitted inside a task or outside of it. A message event (denoted by an envelope symbol) is used for communication between processes by sending a message, and then there is an event that waits for the answer. Attached events drawn on a task can cancel the task and start a new one (if solid circle) or proceed in parallel without interrupting (dotted circle). Timer events trigger at a specific time or after a period of time. Errors are an intermediate event that can be thrown by a task. Signal events are similar to message events but without a specific recipient. A terminate event stops the whole process and all tokens. A compensation event when hit triggers all previous recovery paths simultaneously. An event-based gateway waits for the first of several events and ignores the later ones, and an event-based parallel gateway waits for all of the events before proceeding.

Loops can be written in multiple equivalent ways using gateways or conditional flows. Sub-processes are used to encapsulate complexity, and in the UI, one can often click to expand a node into a process, and they can be embedded and have access to all variables of the parent or global scope. Markers can specify loosely a group of tasks without precise logic. Transactions allow a step to trigger a cancellation of paths for every task in a group. When a process spans across multiple parties, it’s sometimes best to separate each into its own pool and explicitly send a message to coordinate with another pool, rather than using an ordinary sequence flow. One can use dotted arrows to connect eg a send item task in one pool with a received item task in the other pool, or one can also collapse a pool to abstract away details that one doesn’t care about.

Artifacts like annotations and groups visually add information to a diagram without changing its semantics. Some alternative process modeling notations are eEPC and UML, but the details are not described. A choreography diagram abstracts details of tasks, displaying only messages sent between participants to understand the process at a higher level.

Chapter 3: DMN models decisions in operations, and a decision table maps inputs to outputs, allows combining inputs in a cell, and merging cells to read compactly. FEEL gives an expression language for tables, and a comma is used for OR conditions, but an AND condition must be expressed in two columns. A hit policy can be first matching, or prioritized (exception case above others), or collect all matching and return the sum of the scores, etc. DRD (decision requirement diagram) spells out inputs and outputs of decisions without the decision rules. Nodes in DMN can be embedded in a BPMN process.

Chapter 4: when working with BPMN, it’s best to separate a strategic process model at a higher level for executives, just showing what is and isn’t part of the process, inputs and outputs. In a workshop with participants, start with a time-boxed initial version covering the main pieces without going into other details and exceptions, etc, then iterate. It’s helpful to make physical cards with BPMN symbols to arrange tangibly with participants. For strategic modeling, it’s recommended to use a smaller subset of symbols that are intuitive to explain for people who don’t know BPMN deeply. The goal of the strategic process model workshop is to align on a shared, high-level view of the existing process and which part of it needs to be improved.

The operational process model fills in a lot of the details of the strategic process model and is meant for operators (humans) to follow, and should produce collapsed models that show only the relevant lanes for each participant. An executable process model is run by a workflow engine, and therefore you must flesh out the details explicitly and can involve integrations, trigger human interfaces; the semantics are not in the standard, so vendor-defined extensions are needed for execution.

Recommendations for executable models are to keep the data in systems other than the process model, use automated testing, and work together with IT from the beginning rather than after having the operational model. Monitor process execution time and success rates, use error events appropriately to keep the happy path clean, and split large monolithic process models into microservices to invoke. Avoid business decisions embedded in BPMN; use DMN if a decision table is appropriate, or delegate to an external engine, and then keep the process model to just routing decisions only.

Chapter 5: Engines are not fully interoperable, and it is advised not to care too much about this; pick one and access its engine-specific features. BPEL (Business Process Execution Language) is a standard execution language, but it is not widely used and is basically dead on the level of tooling and best practices. The level of best practices should be highest for processes critical to the organization and relaxed for less critical processes. Items to be selected for deployment include a workflow engine, a decision engine, and any APIs that need integration or local platforms. Low-code tools are promised to be legible to business users but tend to be similar to software development for production applications.

Chapter 6: Tips for introducing BPMN in an organization, and expect some pushback from some people, but typically it’s feasible to get everybody to read BPMN if using a restricted subset of the symbols, and only a few people in the organization need to write them, and you can hire external consultants to ensure you’re using it correctly.

Share this:

  • Share on Facebook (Opens in new window) Facebook
  • Share on LinkedIn (Opens in new window) LinkedIn
  • Share on Reddit (Opens in new window) Reddit
  • Share on X (Opens in new window) X

Most similar books:

The Storm on Our Shores by Mark Obmascik Assessing Vocabulary by John Read The Culture Map by Erin Meyer Visual Studio Code for Python Programmers by April Speight

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Search

Subjects

  • Topics (383)
    • Arts and Music (20)
    • Business / Finance (44)
    • Canada (16)
    • China (20)
    • Current Events (14)
    • Data Science / ML (19)
    • Economics (18)
    • History (50)
    • Indigenous (10)
    • Linguistics (21)
    • Mathematics (12)
    • Medicine / Health (18)
    • Natural Sciences (29)
    • Philosophy (15)
    • Self-Help / Career (18)
    • Social Sciences (23)
    • Software Engineering (33)
    • Startups (17)
    • World (39)
  • Type (129)
    • Classics (21)
    • Novels / Fiction (49)
    • Textbooks (59)
  • Uncategorized (2)

Lucky’s Bookshelf is a participant of the Amazon Affiliates Program.

©2026 Lucky's Bookshelf | Powered by SuperbThemes & WordPress