What is BPMN?
You’re about to learn a new language for describing business processes, the Business Process Modeling Notation, or BPMN. If you have done any process flowcharting, you will find it comfortably familiar at first. But as you learn more about it, it will occasionally seem strange and, to make things worse, strict and unbending. Because unlike traditional flowcharting, the shapes and symbols don’t mean whatever you define them to mean. Their meaning is defined already in a specification. So before we get started creating BPMN diagrams, I’d like to prepare you for the battle ahead by explaining why learning BPMN, and learning to use it correctly, is worth the effort.
- BPMN stands for Business Process Modeling Notation, and it is first and foremost a graphical notation, meaning a set of shapes and symbols used to create business process diagrams. For each shape and symbol, BPMN also defines many attributes that do not show up in the diagram. They are in the model but not in the diagram. Most of them are details required to automate the model flow in a process engine. Most BPMN users, however, are not interested in creating executable models. Nor is this training. In this class, what counts is just what you can see in the diagram, that is, the notation.
- What makes BPMN important is it is a standard, created and maintained by the Object Management Group, or OMG. This marks a huge step forward from the era of proprietary diagrams. Before BPMN, every process modeling tool defined its own palette, and individual modelers made up their own meanings for the shapes. Imagine trying to communicate in a world where each tribe made up their own language. Primitive societies have to live with that but it doesn’t work today. As a standard, the meaning of the diagram is – in theory – independent of the tool that created it. The precise meaning of each shape and symbol is defined in a specification, which is supported by many tools, today almost all of them. That not only lowers the cost of the tools but it promises something more valuable… that the diagram your team creates can be understood by other groups across your company, even if they use a different tool.
- Third, BPMN is flowchart-based, meaning it describes processes as a flow of activities, or actions, arranged in swimlanes representing activity performers. That’s not the only way to describe a process – you could model it in terms of states or use cases – but swimlane flowcharts have been around since the 1980s and are, by far, the style of process modeling most familiar to business people. Adopting the outward look and feel of traditional swimlane flowcharts was a conscious choice when BPMN was first created, and it is a major reason for its wide adoption today. But it is a mixed blessing, because it sometimes leads people to use it incorrectly.
- Conceptually the notation is very simple. BPMN has just 3 primary shapes, or flow objects- activity, gateway, and event. The solid arrow, called sequence flow, can only connect to a flow object. Well, you’ll see that actually it’s a bit more complicated than that.
- BPMN really stands out in its expressiveness. That means it can describe very compactly subtle process behaviors, particularly how exceptions are handled. Even though exceptions are often the root cause of problems – the process takes too long, or costs too much, or has too many errors – exception handling patterns have no place in traditional flowcharts. How can you improve a process when the factors most affecting performance and customer satisfaction are omitted from the diagram? BPMN provides a visual language for defining how exceptions in the process – the order gets changed or cancelled while you are processing it, or an expected response does not arrive by the deadline – should be handled.
- Finally, BPMN is flexible enough to support a broad spectrum of stakeholders needing different levels of detail in the model. Business process analysts, developers, and business users use the same visual process language. In this class we’re aiming for something even more rare: individual process diagrams that can be shared between the business analyst and the IT architect or developer. It’s not an easy thing, but BPMN makes it possible. This is much better than having to maintain separate models for business and technical users, and trying to keep them synchronized over the long term.
Earlier, I said BPMN is flowchart-based and for that reason familiar to business, but it differs from traditional flowcharts in a variety of ways. Starting with this: unlike with flowcharts, the meaning of each shape in BPMN is defined precisely in a specification. You can’t just make up your own meaning for it, and there are rules about what can connect to what. You can validate a BPMN diagram against those rules. A valid diagram isn’t necessarily “good BPMN”, but an invalid diagram is definitely bad BPMN.
- Second, BPMN is inherently hierarchical, and the notation enables a hierarchical diagram structure. Instead of putting all the process steps, no matter how granular, in a flat, single-level model, too large to visually consume all at once, BPMN allows you to collapse big chunks of the process into single activities called subprocesses, and arrange them in a top-level process diagram that not only fits neatly on an ordinary page but shows the essential high-level features of the process at a glance: how it starts, its possible end states, what the instance represents. The details of each subprocess are expressed as mini-processes – activity flows – in separate hyperlinked diagrams. These are not separate models, just separate views of a single model. That single model is visualized as a hierarchical collection of diagrams, so you zoom in and out to see as much detail as you need, while retaining the integrity and maintainability of a single model end to end.
- Third, BPMN lets you show how your process fits into a broader business context through what it calls “collaboration”, meaning communications with entities outside the process, like the customer, service providers, or other internal processes. Those entities are represented in the diagram as pools, and the communications with them as another type of connector called message flows. Sequence flows, the solid arrows, represent activity flow within a process. Message flows, the dashed connectors, represent communications between the process and things outside the process. They let your model show how your process fits in the global business environment.
- Fourth, BPMN differs from flowcharts by putting event-triggered behavior in the diagram. An event is a signal that something happened. Technically that signal is the event trigger, the icon inside the circle. The event shape itself, the circle, describes how the process responds to that trigger. That could be by starting a new process, resuming a paused process, aborting a running activity and redirecting the subsequent flow, or starting a new parallel path within the process. Here we see all 4 of those behaviors just for the message trigger, meaning if a particular message flow is received by the process. Events are important because they describe important process behaviors in the real world. Exceptions happen, and your process has to respond. BPMN lets you describe that response in the diagram itself.
- Besides its outward similarity to flowcharts, the other key reason for BPMN’s popularity is its nearly universal adoption by BPM Suite vendors. BPM Suites are technology platforms sold by most major middleware vendors – IBM, Oracle, SAP, as well as dedicated BPM vendors – that automate the process flow and monitor performance in real time. They all contain the boxes shown in blue here, starting with the BPMN process model, which is actually part of the executable implementation. Developers add details underneath each shape in the diagram, defining data and the implementation of each process activity, using little or no programming code. It’s all visual point-click design, what’s called model-driven, so it’s easy to change. The executable design is deployed to the process engine. In operation, receipt of the start message triggers creation of a new process instance, and the engine actually routes the instance through the steps of the diagram. Human tasks are delegated to user inboxes, business rules are executed at the proper time, and queries and updates of business systems are automatically executed through the middleware. As each step is completed, a timestamp plus selected business data is logged for Business Activity Monitoring or BAM, which displays actual performance versus defined key performance indicators in real time. Because it’s model-driven, the process design can be changed to improve performance or when business requirements change. Because the same language – BPMN – is used to specify the business requirements for the process flow and the actual implementation, it enables a closer collaboration between business and IT and a more agile iterative implementation style.