---
title: "Fundamentals of BPM (2018) — Ch. 3: Essential Process Modeling"
type: source
tags: [bpm, bpmn, modelling, semantics, gateways, naming-conventions, tokens]
authors: [Dumas, Marlon; La Rosa, Marcello; Mendling, Jan; Reijers, Hajo A.]
year: 2018
venue: "Springer (2nd ed.), Chapter 3"
kind: chapter
raw_path: "raw/Process Frameworks & BPM/Fundamentals_of_BPM 2018.pdf"
sources: ["[[sources/2018-dumas-fundamentals-of-bpm]]"]
key_claims:
  - "BPMN's three most basic concepts: events (circles), activities (rounded rectangles), arcs (sequence flows). Most modelling needs are covered by a small subset of BPMN's 100+ symbols."
  - "Process semantics is defined via tokens: token created at start event, flows through model along sequence flows, destroyed at end event. State of a process instance = distribution of its tokens (its marking)."
  - "Multiple instances of the same process model run independently — visualised as different-coloured tokens. Tokens reify Petri-net markings inside BPMN."
  - "Naming conventions: activities use verb-object (imperative + business object, e.g. 'Approve order'); events use noun + past-participle ('Invoice emitted'); processes use noun ('order fulfillment'); gateways avoided as labels — use explicit conditions on outgoing arcs of (X)OR-splits."
  - "Activity labels max 5 words excluding prepositions and conjunctions; capitalise first word; replace generic verbs (to make, do, perform, conduct) with specific verbs; avoid words like 'process' or 'order' as both verb and noun in the same model."
  - "Models have three properties: Mapping (correspondence to a real-world phenomenon), Abstraction (omitting details), Purpose (determining what to omit). 'All models are wrong, but some are useful' (George Box)."
  - "Two distinct modelling purposes: (1) organisational design — conceptual models for understanding/communication, no IT details; (2) application system design — executable models for IT engineers, with data types, mappings, system interfaces."
  - "XOR-split routes one token to one outgoing branch based on conditions. Branches must be mutually exclusive; provide a default flow (oblique cut) for the otherwise case. XOR-join is a passthrough — first arrival forwards immediately."
  - "AND-split generates N tokens, one per outgoing branch; AND-join synchronises — waits for one token on every incoming arc, merges into one outgoing token. Standard parallel-execution pattern."
  - "OR-split generates k tokens (1 ≤ k ≤ N) per branches with true conditions; OR-join is a synchronising merge — waits for tokens from all *active* incoming branches. The 'active branch' concept requires non-trivial reasoning."
  - "BPMN allows multiple start events (each captures a different trigger; instance triggered by whichever fires first) and multiple end events (each captures a distinct outcome). Implicit termination semantics: instance completes only when *every* token reaches an end event."
  - "Gateway-type selection heuristic when not obvious: try XOR-join first; if model misbehaves, try AND-join; only use OR-join if both fail. OR-joins are confusing and should be reserved for genuine inclusive synchronisation."
  - "Two BPMN shorthands: XOR-join can be omitted before an activity (incoming arcs go directly to the activity); AND-split can be omitted after an activity (outgoing arcs emanate directly)."
  - "Tooling spectrum: pen & paper (sketch only), haptic (sticky notes/tactile), single-user (Visio drawing-only · Bizagi/ARIS Express/Camunda BPMN-native), multi-tenant (ADONIS NP, IBM BlueWorks Live, ARIS, Signavio, open-source Apromore)."
created: 2026-05-04
updated: 2026-05-04
---

# Fundamentals of BPM (2018) — Ch. 3: Essential Process Modeling

Chapter deep-dive into [[sources/2018-dumas-fundamentals-of-bpm]] §3, the canonical introduction to **BPMN** in the context of conceptual process modelling. Sets the foundation for Ch. 4 (Advanced) and Ch. 5 (Discovery). Back-links to the meta source page.

## 3.1 First Steps with BPMN

### Three basic concepts (§3.1)

| Concept | BPMN visual | Meaning |
|---|---|---|
| **Event** | Circle (thin border = start, thick = end, double = intermediate) | Something that *happens instantaneously* (e.g., invoice received) |
| **Activity** | Rounded rectangle | Unit of *work with duration* (e.g., pay invoice) |
| **Arc / Sequence flow** | Solid arrow with full arrow-head | Logical relation: A is followed by B |

Most modelling needs covered by a small subset of BPMN's 100+ symbols. The chapter introduces symbols gradually by example.

### Token semantics (§3.1, see also [[concepts/token-semantics]])

Tokens reify the [[concepts/workflow-net|Petri-net marking]] inside BPMN:

- A **token** is created at a start event when an instance begins.
- It flows along sequence flows.
- It's destroyed at an end event.
- The **state** of a process instance = distribution of its tokens (its *marking*).
- Multiple instances run independently — visualised as different-coloured tokens.

### Naming conventions (§3.1)

Stricter and more granular than the [[concepts/7pmg]] G6 summary:

**Activities — verb-object (imperative + business object):**
- *Approve order* ✅
- Noun may be preceded by an adjective: *Issue driver license* ✅
- Verb may be followed by an adverbial clause: *Renew driver license via offline agencies* ✅
- **Max 5 words** excluding prepositions and conjunctions, to keep labels readable.
- Replace **generic verbs** (*to make, do, perform, conduct*) with specific verbs that capture the activity's specifics.
- Avoid words like *process* or *order* used as **both verb and noun** within one model — pick one part of speech and stick to it.

**Events — noun + past-participle (state):**
- *Invoice emitted* ✅, *Urgent order sent* ✅
- Past participle indicates *something has just happened*.

**Processes — noun, optionally with adjective:**
- *Loan origination*, *order fulfillment*, *claim handling*.
- Obtain by nominalising the verb of the main process action: "fulfill order" → "order fulfillment".
- Hyphenated forms also acceptable: *order-to-cash*, *procure-to-pay*.

**Capitalisation:**
- First word of activity / event labels capitalised.
- Process names typically not capitalised (*order-to-cash*, not *Order-to-Cash*).

**Gateway labels:** see §3.2.1 — labels on (X)OR-splits should be avoided; use explicit conditions on outgoing arcs.

### Mapping, Abstraction, Purpose (§3.1, sidebar)

A model has three defining properties:

1. **Mapping** — correspondence to a real-world phenomenon.
2. **Abstraction** — what details are omitted.
3. **Purpose** — what determines which details to omit.

> *Essentially, all models are wrong, but some are useful.* — George E.P. Box

The **target audience** determines purpose. A timber model of a building serves a prospective buyer; a blueprint serves an electrical engineer. Same building, different models, different abstractions, different audiences.

### Conceptual vs executable models (§3.1, sidebar)

A foundational distinction Dumas makes explicit:

| Aspect | Conceptual model | Executable model |
|---|---|---|
| **Purpose** | Organisational design | Application system design |
| **Audience** | Process owners, business analysts, participants | System engineers, solution architects, developers |
| **Built by** | Process analysts | Technical staff |
| **Contents** | Activities, events, gateways, lanes — no IT details | Plus data types, data mappings, service tasks, system interfaces |
| **Used for** | Discovery, communication, analysis, redesign basis | Software development blueprint, BPMS deployment |

The same business process may need *both*: a conceptual model for stakeholder alignment and an executable model derived from it for automation. Chapter 10 of the Dumas book covers the conceptual → executable transition.

## 3.2 Branching and Merging

Activities/events are not necessarily sequential. BPMN models alternative and concurrent execution via **gateways** (diamond shape).

| Gateway type | Outgoing semantic |
|---|---|
| **Split** | One incoming arc, ≥2 outgoing arcs — diverges flow |
| **Join** | ≥2 incoming arcs, one outgoing arc — converges flow |

### 3.2.1 Exclusive Decisions (XOR)

Used to model **mutually exclusive** alternatives.

- **XOR-split**: routes the incoming token to **exactly one** outgoing branch based on conditions. Marker: empty diamond or "X".
- **XOR-join**: passthrough — forwards each arriving token to its output. Acts as merge for previously-XOR-split branches.

**Rules**:
- Annotate each outgoing arc with the condition that selects it.
- Conditions must be **mutually exclusive** — only one can be true at any time.
- Provide a **default flow** (oblique cut on the arrow) for the "otherwise" case in case all conditions are false.
- Always complete the model with an end event, even if "obvious".

**Example** (Fig 3.4): invoice checking yields three mutually exclusive outcomes — no mismatches (post invoice), correctable mismatches (re-send), uncorrectable mismatches (block). Three branches from XOR-split, merged at XOR-join, then *Park invoice* completes.

### 3.2.2 Parallel Execution (AND)

Used when two or more activities have **no order dependency** and can be performed concurrently.

- **AND-split**: generates **N tokens**, one for each outgoing branch — all branches execute in parallel.
- **AND-join**: synchronises — **waits for one token on every incoming arc**, then merges into a single outgoing token.

Marker: diamond with "+".

**Example** (Fig 3.5): airport security check splits into "pass personal screening" + "pass luggage screening" in parallel; AND-join waits for both before "proceed to departure".

**Multiple end events** (§3.2.2): a model can have multiple end events, each capturing a distinct outcome (*Order fulfilled* vs *Order rejected*). BPMN uses **implicit termination semantics**: an instance completes only when **every** token reaches an end event — not just the first one.

**Multiple start events**: each captures a different trigger (e.g., *Purchase order received* vs *Revised order received*). Instance is initiated by whichever start event fires first.

### 3.2.3 Inclusive Decisions (OR)

For situations where one *or more* branches can be taken — the conditions need not be mutually exclusive.

- **OR-split**: generates **k tokens** (1 ≤ k ≤ N), one for each branch whose condition is true.
- **OR-join**: **synchronising merge** — waits for tokens from all *active* incoming branches, then merges into one.

Marker: diamond with "O".

**Why OR is hard**: the OR-join must reason about which incoming branches will *eventually* deliver a token (the **active branches**) — those that do not require global reasoning over future model behaviour. This is the source of OR-join semantic paradoxes flagged in [[concepts/7pmg]] G5.

**Heuristic for join-type selection** (§3.2.3):

> *Start with an XOR-join, next try an AND-join, and if both gateways lead to incorrect models use the OR-join which will work for sure.*

In other words: prefer XOR (passthrough; works for mutually-exclusive branches), then AND (synchronisation; works for fully-parallel branches), and only fall back to OR when neither fits — because OR is the most expressive but also the most confusing.

**Example** (Fig 3.10): order distributed across two warehouses. Sub-orders sent to whichever warehouses contain relevant products (might be one, the other, or both). OR-split fires k branches; OR-join waits for all active branches before *Register order*.

### Shorthand notations

Two abbreviations:
- **XOR-join can be omitted** before an activity or event when the join is just a merge of mutually-exclusive branches. The incoming arcs flow directly into the next element.
- **AND-split can be omitted** after an activity or event when launching parallel branches. Outgoing arcs emanate directly from the predecessor.

## 3.3 Business objects and resources (chapter map; not deep-dived here)

Pools, lanes, data objects, message flows. See [[frameworks/bpmn]] for the element catalogue and [[syntheses/bpmn-modelling-practical-guide]] §10 for builder-level rules.

## 3.4 Process decomposition (chapter map; not deep-dived here)

Sub-processes (embedded vs reusable / call activities), decomposition criteria, naming hierarchical models. See [[syntheses/bpmn-modelling-practical-guide]] §8.

## Tooling spectrum (sidebar in §3.2)

| Mode | Examples | Notes |
|---|---|---|
| Pen & paper | — | Initial sketch only; no systematic sharing |
| Haptic | Post-its, brown paper, sticky notes, tactile BPMN tiles | For workshops; high engagement |
| Single-user general | Microsoft Visio (BPMN stencil) | Drawing tool — exports to image, not BPMN XML |
| Single-user specialised | Bizagi Modeler, BOC ADONIS:CE, ARIS Express, Camunda Modeler | BPMN-native; varies in soundness checking |
| Multi-tenant | BOC ADONIS NP, IBM BlueWorks Live, Software AG ARIS, Signavio Process Manager | Shared repository, collaborative; cloud-based often |
| Open-source platform | Apromore | Process analytics + modelling |

**Critical**: validate that your tool exports **BPMN 2.0 XML**. Visio and similar produce drawings, not models — downstream tooling integration is impossible.

## Chapter takeaways for the practitioner

1. **Master the core 5 gateways** (XOR split/join, AND split/join, OR split/join, plus event-based — covered in Ch. 4) before adventuring into the rest of BPMN's symbol set.
2. **Tokens are the right mental model** for reasoning about gateway behaviour, soundness, and runtime.
3. **Naming conventions matter empirically** — see also [[sources/2010-mendling-reijers-vanderaalst-7pmg]] G6 for the experimental evidence behind verb-object labels.
4. **Pick conceptual vs executable up front** — different audiences, different content, different tools.
5. **OR-joins are tempting and rarely worth it** — the join-type heuristic (XOR → AND → OR) is the modeller's safety net.

## Connections

**Concepts:** [[concepts/token-semantics]] · [[concepts/process-model-quality]] · [[concepts/7pmg]] · [[concepts/soundness]] · [[concepts/deadlock]] · [[concepts/lack-of-synchronization]] · [[concepts/block-structure]]
**Frameworks:** [[frameworks/bpmn]]
**Sister chapter:** [[sources/2018-dumas-fundamentals-of-bpm-ch5-discovery]] (Ch. 5 — Process Discovery, including §5.4 Quality Assurance)
**Meta source:** [[sources/2018-dumas-fundamentals-of-bpm]]
**Practical synthesis:** [[syntheses/bpmn-modelling-practical-guide]] (incorporates Ch. 3 + Ch. 5 + 7PMG into a builder's guide)

## Open follow-ups
- **Ch. 4 deep-dive** — Advanced Process Modeling (typed events, exceptions, boundary events, compensation, event sub-processes). Currently referenced-not-deep-dived.
- **Ch. 3 §3.3 + §3.4 deep-dive** — Business objects/resources + process decomposition. Currently summarised in [[frameworks/bpmn]] and [[syntheses/bpmn-modelling-practical-guide]] but not as a dedicated source page.