BPMN 2.0

BPMN 2.0 turns business processes into diagrams that are simultaneously a communication tool and an executable contract. I use it where process logic must be explicit, versioned, and understandable to people who never read code.

Modelting is the easy half — the same BPMN drives orchestration engines like Camunda, so the diagram is the source of truth for routing, timers, events, and human tasks, not just documentation that drifts from reality.

Paired with DDD it becomes the executable map of the domain: each process instance is a workflow lifecycle, monitored and instrumented through the engine rather than scattered across hidden service calls.

BPMN gives a shared notation that crosses the analyst/developer line. A swimlane diagram of a loan or a claim is readable by the people who define the rules and the people who implement the system, which collapses the translation layer that ruins most process projects.

The notation covers the hard cases explicitly: parallel splits, exclusive and event-based gateways, timers and escalation events, compensations and boundary events. Instead of burying process decisions in code comments, the flow structure makes them visible and reviewable.

Executability is what separates BPMN from a drawing. The same model that stakeholders sign off runs in the engine — service tasks call application code, user tasks hand work to people, and events trigger on real messages or timers. The diagram is the running system.

I keep the models human-sized. Over-fragmented diagrams are as unreadable as spaghetti code, so I decompose large processes into reusable sub-processes and call activities, keeping each diagram scoped to a readable slice of the domain.

Versioning and monitoring come free with the engine: every deployed model version is tracked, every instance is observable, and incidents surface as explicit states. That traceability is the operational guarantee a hand-rolled state machine would take months to build.

BPMN is not for everything. For simple linear glue, plain code or n8n is leaner. BPMN earns its weight when a process is long-running, multi-party, timer-driven, or human-in-the-loop — which is precisely where most enterprise value actually lives.

I model the process before the system. The BPMN starts as a faithful map of how the business actually works today, agreed with stakeholders, before any engine or code is introduced.

The diagram is the running contract. Because the same model drives execution, I keep the BPMN as the single source of truth and wire service tasks and events to the real system rather than letting docs drift.

I keep diagrams readable by decomposing. Long processes become sub-processes and call activities, so each model stays a comprehensible slice of the domain instead of a wall of spaghetti.

Gateways name the decisions. Exclusive, parallel, and event-based routing make the branch logic explicit and reviewable — no business rule hiding in code comments.

Human tasks get form data, assignment, and a deadline. I model who must act and what happens when they do not, which turns SLA-driven flows into explicit, monitored workflows.

Timers and boundary events handle the real world. Escalations, retries, and compensation are modelled visibly rather than buried, so exceptional paths are first-class citizens.

DMN tables carry the decision rules. Pricing, thresholds, and eligibility live as analyst-maintainable tables, keeping policy changes out of the deploy cycle.

Monitoring is configured alongside the model. Process KPIs, stuck-instance alerts, and dashboards are set up early so the flow improves by evidence, not anecdote.

I am honest about scope — BPMN is the tool for long-running, stateful, multi-party processes. For short linear glue, plainer automation wins.