BPMN Is Brilliant, Actually

I don’t understand why people still use writing as a means to communicate their thoughts. Not only is it over 3000 years old—but, I can’t spell particularly well, and learning how would be hard. Luckily, I’ve developed an entirely new method of communicating thoughts! Best of all, this new method is proprietary and will only work on the pens and paper I sell you.

This is the thesis for anything you’ll read railing against Business Process Model & Notation (BPMN)’s long-running popularity. It’s an ISO standard designed for describing the steps, decisions and events that might occur over the course of a process. What’s interesting about arguments against the standard is the absence of a direct comparison to an alternative. I’ve been using BPMN to model and execute processes for almost ten years. I’ve also used a bunch of alternatives, and I’ve never seen any that can hold a candle to what’s possible with BPMN. I think it’s time I do what many businesses don’t do when flaunting their alternatives: I want to talk about what BPMN can really do and show you why it’s brilliant, actually.

Observability and clarity

As opposed to all current alternatives, BPMN was not initially designed to be executable. This has, strangely enough, proven to be a big part of why it’s so much better. The first version of BPMN was built to be a notation that would make it easy for people to design and share processes. The result was a notation that heavily valued visual clarity even when showing a lot of complexity. Consider how quickly someone could understand a diagram presented to them as a core design principle. The second version of BPMN added the execution semantics as well as a few missing symbols. The benefit of creating an executable model from an already well-tested and proven visual framework was key to its success. It inspired a large number of companies to start building a process engine that could take BPMN models and directly execute them.

Making it possible for process analysts and software engineers to work together on the same notation at design time was a massive step forward; nothing was lost between design and development because everything had to be in the model—or it wouldn’t happen. These days, it’s gone even further; DevOps and Support Engineers now have tools that can integrate BPMN, making it so much easier to understand the current state of a process as well as making changes to it.

This graphic demonstrates how with BPMN and good tools you can easily monitor and manipulate the state like moving from the current state of the process from “Check Details” back to a gateway so that it can be re-evaluated.

Finally, beyond just maintaining a running system, BPMN is in a unique position to help facilitate iterative improvements. If a process designer is interested in whether what they built is running as efficiently as they assumed, they just need to look. The exact process that was designed and deployed is now a key factor in helping suggest and validate improvements.

This graphic combines the real process data with the process model to give a clear and quick understanding of which part of the process is taking the longest – in this case “Check Details” is bright red so indicates there could be a problem.

Diversity of events

Fundamental to basic process modeling and automation are tasks. Running a microservice, involving a human worker, or even just running a script—all possible in BPMN and even in some alternatives. But, being able to build and execute “basic processes” is not a high bar. Businesses that want to see their core processes automated do not want to compromise on the tools provided for that automation. They want to use their preferred tools to automate document processing, customer relationship management, back office functions, and more. They also want the freedom to swap out automation tools whenever there’s a technical need or a business need to do so. 

One example worthy of a showcase is that of BPMN events. The diversity and flexibility of these events demonstrate a larger theme that runs through the whole standard.

There are many types of events in BPMN, but I want to focus on some common ones and explain why they’re an important foundation of its success.

Utilizing Message events

This is the most common way to communicate between two processes. The message throw event is always sent to an external source (i.e., leaves the scope of the current process) and always has exactly one recipient. It’s a straightforward and reliable way of communicating within a process engine because the engine itself is responsible for delivering the message. You just need to define a message name and correlation keys.

E.g., An order process can send a message to a procurement process and continue again when the procurement is completed.

Utilizing Timer events

Does your process need to wait for a future date or some duration of time? Most processes do, and the timer event just needs to be told how long. The process engine handles the waiting and the waking.  

E.g., Wait until 2 weeks before the end date before sending a renewal request.

Utilizing Signal events

Signal events are like message events but with a big difference—they’re a broadcast, potentially reaching 0 to any number of recipients. It is incredibly useful as it can span all process instances and process definitions to ensure all who are listening pick up the signal.  

E.g., Canceling all processes related to a specific client after they’ve been rejected.

Utilizing Error event

This misunderstood symbol covers a wonderfully common gray area in process design. A problem that means the process shouldn’t continue as is—but it’s not a technical error. Instead, it’s an error that you can catch, and then you can continue the process through a different route.

E.g., an incorrect email has been entered by the user, we need to contact the user and ask them to enter a different email before trying again.

These are some of the first symbols you’ll learn in BPMN, and learning how to use them can give you a nice idea about solving a lot of the basic process challenges that you’ll come across. But, the beauty of BPMN becomes most apparent when you understand the synergies these symbols have across the rest of the standard.

Synergistic Symbols

When I teach BPMN, I tell attendees early on that knowing what all the BPMN symbols do is not the same as knowing BPMN. This probably sounds like an odd thing to say, but it’s the same with writing. Knowing how each letter sounds is not going to be much use when you’re trying to make a sentence. The secret to getting the most out of BPMN is knowing how the symbols combine and work together to create amazingly powerful patterns and structures. I’ve just spoken about some basic events, but what happens when you know how to combine them into patterns?

Messages event

Sure, you can wait for a message to occur at some part of the process. But you can also attach it to a task so that the message is only triggered if the task is still active and waiting for it to be received in parallel with the task work being done.

Timer event

What if there’s a specific timeframe of the process that requires some speedy execution? You can scope the tasks in a subprocess and use a non-interrupting timer event to send a warning if you’re coming close to violating an SLA. The complexity involved in building this relatively simple pattern is worth focusing on for a moment and can help underline why this is often missing from alternatives. Here are the requirements:

1. We need to wait for a duration of time in parallel to the execution of other tasks
2. Triggering the timer should not affect the work being carried out in parallel
3. The timer needs to understand the scope so that it activates and deactivates itself in line with the task it’s scoped for

This is not a trivial task for a process engine to implement. But a BPMN engine only needs to understand the individual symbols and how they combine. The engine isn’t programmed to understand the pattern per se, It just needs to understand how BPMN works.

Error events

When combined with an event subprocess (my favorite symbol), you get a “global catch” for any errors that might occur in the process. This of course isn’t limited to error events, with BPMN’s “global catch” pattern you are given the scope of the entire process instance and you can decide which event it should wait for.

These are still just the tip of the iceberg, but what I’ve shown is that on a fundamental level BPMN has created a wide variety of building blocks that are intended to fit together to create something greater. This concept is always missed by companies trying to build their proprietary alternatives.

The community and the standard

I’m always happy to talk about the features and the concepts that make BPMN so great. But, for me, a differentiator that has kept BPMN going and will continue to do so is the community. There are a huge number of people using BPMN to model and execute their processes, and it starts because BPMN is incredibly accessible. You can learn how to model for free (through books, blogs and tutorial videos), you can choose from an impressive variety of modeling tools and even pick which engine executes your process. If you need support with building a solution, there’s a vast community there to help (you can even find me helping out on Camunda’s forum).

But it even goes beyond the end-users. The vendors who build BPMN tools also have a great community; we frequently meet up as part of the OMG’s Model Interchange Working Group, which is actually more fun than the name suggests. Here, we agree on things that move the standard forward and ensure consistency and compatibility of the standard across tools. Once a year, we even do a live demonstration showcasing each of the modeling tools as they work together to build a single BPMN model.

Conclusion

Instead of asking why people are still using BPMN, maybe it is worthwhile asking why you’re being told not to use BPMN? No one has managed to make a better notation, and it’s not like there’s a community out there asking for someone to come up with an alternative. Some process orchestrators simply don’t have any visualization (which I think is a little short-sighted and limiting, but each to their own). Some clearly want to avoid the competition inherent in offering the potential of migrating from one BPMN tool to another. Some perhaps like the idea of being the only source of consulting and training for their own notation.

I could be wrong, since these reasons don’t seem to show up when vendors themselves bring up the subject of BPMN. They tend to say, “BPMN is old, you should use our thing instead,” and hope no one asks, “Sure, but how exactly is your thing better than BPMN?”

Ready to learn BPMN?

There are many resources that can help you get started with BPMN, including our own detailed BPMN tutorial and BPMN documentation. Feel free to take a look, and if you’d like to try modeling your processes, you can sign up for Camunda and model for free.