BPMN vs UML: differences and how to choose

You open an editor at the start of a project — and trip over the very first question: should you draw the process in BPMN or in UML? There is always someone on the team who is sure that “UML is for programmers,” and someone else who replies just as firmly: “BPMN is just pretty flowcharts.” Both are half right.

The difference between the notations is not which one is more professional. It is in the subject. BPMN describes the work: which participants do what, in what order, and what triggers the next step. With UML, the focus moves to the system. What parts does it have? How are they connected? How do they behave over time? One language answers “how does the process run,” the other — “how is the thing that runs it built.”

They overlap in one place — on the UML activity diagram. That is also where people most often get confused.

Next — what each notation is made of, where the boundary runs, three questions for choosing, and how the same process looks in two models.

Two languages for two different questions

A notation is an agreement about symbols and the rules for connecting them. Without it, two diagrams of the same process drawn by two people cannot be compared: for one, a diamond is a decision; for the other, it is just an accent.

BPMN and UML are two such agreements, and both are supported by one consortium, OMG. But they were created for different readers. BPMN is designed so that a process owner, an analyst, and the developer who later automates that process can all read the diagram. UML grew out of software design, and its main reader is the one who builds the system.

This gives a simple rule that rarely fails. People, departments, and companies passing work to each other? That is BPMN. Classes, components, messages between services, and object states belong to UML.

The choice of notation starts not with the editor but with the question: who will read the diagram and what will they do with it.

BPMN: who, what, and in what order

BPMN stands for Business Process Model and Notation. Its vocabulary is small and tailored to one task. A pool is a process participant, usually an organization. A lane inside a pool is a role or department. A task is a step of work. An event is something that happens: a request arrived, a deadline expired, a payment was received. A gateway is a fork. A message flow is the transfer of information between participants who have no common boss.

As an international standard, the notation is fixed in ISO/IEC 19510

, and this standard is identical to OMG BPMN 2.0.1. It defines three types of diagrams: process, collaboration, and choreography — the exchange of messages between parties without revealing their internal workings. In 2022, ISO reviewed the standard and confirmed it, so it is current. OMG’s latest version is 2.0.2 from January 2014.

In practice, the analyst works almost all the time with the first two types. A process diagram covers work inside one organization. Collaboration is about messages between organizations: the client sends a request, the bank returns a decision.

BPMN’s strength is events and boundaries of responsibility. You can see where the process waits for an external signal. You can see where work passes from hand to hand. And you can see where it can get stuck because a step has no owner. Processes usually break at these seams.

UML: what the system is made of and how it behaves

UML is the Unified Modeling Language. It is not one diagram but a family, and it is divided into two groups. Structural diagrams show what the system consists of: classes, components, deployment across servers. Behavioral diagrams show how it works: use cases, message sequences, object states, activities.

As an international standard, UML is fixed in two parts of ISO/IEC 19505:2012: the first describes the language infrastructure, the second — the superstructure, that is, the diagrams themselves. ISO confirmed both in 2025. OMG’s current version is UML 2.5.1 from December 2017.

An interesting detail: the description of the second part of the standard says that UML is also needed for modeling business processes, not only software. So the claim “UML does not describe processes” is wrong. It does. The real question is how convenient that is, and for whom.

Out of the whole family, the analyst in practice needs four or five diagrams: use case, sequence, state, activity, and, less often, class — when it is necessary to agree on domain concepts. A use case diagram shows actors and their goals, but not the steps. The steps are written as text — see User Story vs Use Case: the difference and which one to write.

Where they overlap: the activity diagram

The UML activity diagram can do almost the same as a BPMN process: actions, forks, parallel branches, start and end. It even has lanes — in the specification they are called activity partitions and group actions by performer.

So a simple process can be drawn either way. The diagrams will look similar. The difference shows up once the process goes beyond one team.

BPMN is richer in events: timers, messages, errors, escalations, and interruptions have their own symbols and strict meaning. It has pools and message flows for work between organizations. A BPMN diagram is easier for a person who does not design systems to read: the symbols are closer to business language.

The activity diagram is stronger when the process runs inside a system. It fits naturally into the rest of the UML model: an action can reference a class operation, an object flow can reference an entity from the class diagram. For an algorithm inside a service, this is more convenient than BPMN.

How to choose: three questions

Who will read the diagram. If the readers include a process owner, a lawyer, or a department head — BPMN. They will read pools and lanes without preparation. If only an architect and developers read the diagram — UML is more familiar to them.

What is on the diagram: people or system parts. Work that passes between people, departments, and companies — BPMN. Interaction of services, the life cycle of an object, data structure — UML. If one diagram ends up with both the accounting department and a database table, that is a signal that there should be two diagrams.

What will happen to the model next. Agree on a procedure, find a bottleneck, automate the process in a BPM system — BPMN. Design an integration, describe the behavior of a screen or service, hand the task to development — UML.

If the answers diverge, that is not a mistake. It means the project needs both models.

I would start with the first question. A diagram that the person approving it cannot read has to be redrawn, and that is the most expensive mistake in choosing a notation.

One process, two models

Let us take a refund for an order. In BPMN, this is a client pool and a company pool with lanes for “support,” “warehouse,” and “finance.” The client submits a request. A message goes into the company. Support checks the order, and a gateway splits the flow: do the goods need to come back or not? Waiting for the parcel has a timer. If it does not arrive within 14 days, the request is closed. Finance processes the refund. The client gets a notification. Now it is clear where the process waits and who owns each step.

In UML, the same refund raises other questions. A state diagram of the request: created, under review, waiting for goods, approved, rejected, paid — and which transitions between them are allowed. A sequence diagram: the refund service requests the order, calls the payment gateway, gets a response, writes to the log. Here it is visible what the system must be able to do and in what order to exchange data.

Both models describe one process and do not contradict each other. Requirements connect them: the step “finance processes the refund” in BPMN is expanded by functional requirements, and they are expanded by the service behavior in UML. So that this connection is not lost during changes, it is captured through traceability — how this is done is covered in the article about the requirements traceability matrix. And about where the boundary runs between a business goal and system behavior — in the breakdown of how business requirements differ from functional ones.

How this sounds in an interview

The question about BPMN and UML is asked often, and a weak answer is a string of labels: “BPMN is for processes, UML is for systems, UML has many diagrams.” True, but anyone who has read one article answers that way.

A strong answer starts with the subject and ends with an example. BPMN is about the work of participants and passing it between them; UML is about the structure and behavior of a system. They overlap on the activity diagram, and a simple process can be drawn in either. Then — one case from your own work: which process, which notation you chose and why, and which diagram the developers needed later.

If the interviewer digs deeper, explain how you choose: who will read the diagram and what they will do with it next. This distinguishes a person who has drawn diagrams for people from one who knows the names of the diagrams.