One of the most common confusions I see in early modeling sessions is the belief that a choreography diagram must show internal steps. That\u2019s not the point.<\/p>\n
When someone says, \u201cI want to show how each team does their part,\u201d they\u2019re describing a process or collaboration diagram. A choreography diagram doesn\u2019t care about internal logic. It only cares about the sequence of messages exchanged.<\/p>\n
That\u2019s the core of what is a BPMN choreography diagram: a specification of expected interactions between participants, where each message is a first-class task in the flow.<\/p>\n
After two decades of modeling across industries\u2014from insurance to supply chains\u2014I\u2019ve found that choreography diagrams are most powerful when used as formal contracts between systems or organizations. They\u2019re not about how things are done internally. They\u2019re about what must happen, and in what order.<\/p>\n
By the end of this chapter, you\u2019ll know when to use a choreography diagram, how to model it clearly, and why it\u2019s the right tool for defining interoperability\u2014especially when you can\u2019t control the internal process of a partner.<\/p>\n
Let\u2019s start with a simple truth: a choreography diagram models the orchestration of interactions, not the execution of work.<\/p>\n
Unlike process diagrams, which show the internal steps of a single participant, or collaboration diagrams, which show message flows between pools, choreography diagrams place all participants on equal footing and focus exclusively on the sequence of messages.<\/p>\n
Each message is represented as a choreography task. These tasks are not internal activities. They are the only events that matter in the choreography.<\/p>\n
Think of it like a script for a play. You don\u2019t need to know how the actors prepare backstage. You only need to know when they speak, in what order, and to whom.<\/p>\n
This is the essence of the BPMN choreography definition: a global view of message exchange sequences between autonomous participants.<\/p>\n
BPMN didn\u2019t add choreography just for complexity. It exists because real-world systems often need to interoperate without full visibility into each other\u2019s internals.<\/p>\n
Consider a bank integrating with a payment gateway. The bank doesn\u2019t need to know how the gateway validates transactions. It only needs to know: \u201cI send a payment request. Then I receive an acknowledgment. Then I receive a settlement confirmation.\u201d<\/p>\n
That sequence\u2014defined by messages\u2014is the choreography.<\/p>\n
Choreography diagrams are especially useful when:<\/p>\n
Choreography diagrams use a small but precise set of elements. Mastering them means understanding that every line and shape is about message flow, not internal logic.<\/p>\n
Each choreography task represents a message exchange. It\u2019s not a process step. It\u2019s not an activity. It\u2019s a message sent or received.<\/p>\n
For example:<\/p>\n
These are not activities like \u201capprove invoice\u201d or \u201cupdate database.\u201d They are communication events.<\/p>\n
Importantly, choreography tasks can be initiated by any participant. There\u2019s no \u201cstart\u201d or \u201cend\u201d in the traditional sense. The flow is defined by the sequence of messages.<\/p>\n
Each participant in a choreography diagram is a role in the interaction. They\u2019re not pools. They\u2019re not lanes. They\u2019re autonomous entities with responsibilities.<\/p>\n
Participants can be marked as initiating or non-initiating:<\/p>\n
These roles are crucial for defining the choreography\u2019s starting point and ensuring alignment.<\/p>\n
Sequence flows in choreography diagrams connect choreography tasks. They define the order of message exchanges.<\/p>\n
Unlike in process diagrams, these flows are not internal control flows. They are the only way to show the order of communication.<\/p>\n
Each flow must connect a send task to a receive task, or vice versa. No loops, no diverging paths\u2014unless the choreography explicitly allows them (e.g., for retries).<\/p>\n
Confusion often arises because all three diagram types show interactions. But their purpose, scope, and structure differ significantly.<\/p>\n
Let\u2019s clarify the key differences with a comparison table:<\/p>\n
| Aspect<\/th>\n | BPMN Choreography Diagram<\/th>\n | BPMN Process Diagram<\/th>\n | BPMN Collaboration Diagram<\/th>\n<\/tr>\n<\/thead>\n | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Focus<\/strong><\/td>\n| Message exchange sequence between participants<\/td>\n | Internal workflow of a single participant<\/td>\n | Message flows between pools (participants)<\/td>\n<\/tr>\n | Viewpoint<\/strong><\/td>\n | Global, contract-like<\/td>\n | Internal, orchestration<\/td>\n | Interactions, coordination<\/td>\n<\/tr>\n | Participants<\/strong><\/td>\n | Equal, no hierarchy<\/td>\n | One participant (pool)<\/td>\n | Multiple pools, roles defined<\/td>\n<\/tr>\n | Internal Detail<\/strong><\/td>\n | Not shown<\/td>\n | Shown in full<\/td>\n | Partially shown (message flows only)<\/td>\n<\/tr>\n | Use Case<\/strong><\/td>\n | Contract specification, system integration<\/td>\n | Automation, documentation, internal process<\/td>\n | Cross-functional handoffs, B2B workflows<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n | This table captures the heart of the BPMN choreography vs process diagram distinction: one is about behavior, the other about execution.<\/p>\n Choreography modeling in BPMN is not about replacing process diagrams. It\u2019s about adding a layer of clarity for external interactions.<\/p>\n Real-World Examples of Choreography Modeling<\/h2>\nLet\u2019s walk through a real example from a logistics company integrating with a customs authority.<\/p>\n Scenario: Import Clearance Process<\/h3>\nThe goal: Define the sequence of messages between the logistics provider and the customs system.<\/p>\n Participants:<\/p>\n
|