Read what they have to say about BPMN Method and Style.

BPMN is a language for constructing business process models. It’s not the only one in existence, but it is far and away the most widely adopted, by modelers and tool vendors alike. BPMN is a multi-vendor standard controlled by the Object Management Group. Using it requires no license or fee, and BPMN tools are generally low-cost. Some are free.

The N in BPMN stands for notation, because BPMN is at heart a diagramming standard. A BPMN model contains information that does not show in the diagram, but - for the majority of process modelers, at least - it’s the diagram that counts most. Process modelers are a diverse lot, spanning a broad range of technical skill, business knowledge, and modeling objectives. BPMN’s unique value is that it can be used by all of them and facilitates communication among them. Because it is based on notions familiar from traditional flowcharting, BPMN is considered business-friendly. At the same time, the notation is linked to a precisely defined semantic model. That means each shape used in the notation has a specific meaning, with defined rules about what is allowed to connect to what, and what each diagram element or pattern signifies. This makes BPMN useful and appealing to IT.

These aspects can be critical to enabling something even more powerful and rare: business-IT collaboration. They allow a diagram understandable by business - perhaps even created by business - to be incorporated directly within an automated implementation of a core business process. We’ve never had that before.

However, there is an inevitable tension between these aspects, familiarity and simplicity for business, expressiveness and semantic precision for IT. While BPMN has only three shapes - activity (rounded rectangle), gateway (diamond), and event (circle) - expressiveness and precision demand a myriad of subtypes of each, distinguished by border style, the symbols inside, and placement in the diagram. Thus what looks simple on the surface is in reality complex.

The BPMN specification and most books and training about BPMN focus on classifying the various shapes and symbols, defining what each one means. But, as John Ciardi wrote in his classic, How Does a Poem Mean?, “the language of experience is not the language of classification.” Describing how a process really works, or should work, and communicating that effectively in a diagram require more than a dictionary definitions of the shapes and symbols. They also demand a consistent method and style, and that is what this book tries to present. In BPMN as in ordinary prose, clarity of expression is essential for effective communication, and it is a learnable skill.

Unlocking BPMN’s Secrets

While BPMN is widely adopted, few process modelers know how to use it correctly or effectively to achieve its promises of shared understanding and business-IT alignment. One reason is the specification itself.

Here is the great irony of BPMN. Most modelers today are using it for process description and analysis, not executable process design. Whether in IT or line of business, most BPMN users are non-technical, and they are rarely even considering the possibility of an automated implementation. However, BPMN’s conceptual foundations assume “executable” processes. Automated execution is the hidden subtext of the BPMN spec, and it continues to shape OMG’s vision for BPMN. While most modelers simply want their BPMN models to describe their processes, the authors of the BPMN specification are actually thinking about models that control process execution.

To be clear, BPMN does not insist process models be executable, but the technical meaning it assigns to the notation’s shapes and symbols assume the perspective of a central execution engine. This unstated conceptual frame is one reason why many business users find BPMN’s semantic distinctions so befuddling.

BPMN in practice can be used for both types of modeling. In fact, documentation and analysis of non-executable processes benefit greatly from BPMN’s semantic precision and expressiveness. But that means finding common ground.

First, BPMN’s core concepts and secret assumptions must be decoded.

Beyond its hidden “executable” orientation, BPMN is confusing to business users because the spec never explains its most basic concepts. For example, what exactly is a process? What does it mean for a participant to be inside vs. outside the process? What does it mean to start or complete an activity, and what does it mean for an activity to complete normally? Why does sending occur immediately but receiving implies a wait? What is the difference between making a decision and taking this path or that based on a decision, or a related question, what is the difference between a business rule and a routing rule? What does it mean for two activities to be concurrent versus sequential? What is the difference between performing some automated function like Check Credit and requesting it? What is the difference between branching based on data vs. branching based on an event?

The answers to these questions are critical to correct use of the notation. In fact, BPMN has answers to all of them, but you won’t easily find them in the spec. Using the notation effectively depends on understanding and even accepting, BPMN’s hidden assumptions, its conceptual framework. In other words, to really understand what a BPMN model means you first need to come to grips with the question, how does a model mean?

In BPMN, a process really means an orchestration. That is a sequence of activities in which the flow is centrally controlled. When an activity completes, the central controller - the process “engine” - commands or “enables” the next activity in the flow to start. The process model describes all the possible paths from creation of an instance of the process to its eventual completion, along with the logic that determines which path is taken. Software that actually does that in fact exists: It’s called a BPM Suite, or BPMS, and there are dozens of them available. Even though most process modelers do not have a BPMS, or any other form of centralized orchestration engine, that figment or metaphor is baked deeply into BPMN.

The Questions BPMN Asks

When a company decides to “do” business process management, the first step is usually to model the current state process. The people doing it don’t even call it modeling, but process “mapping” or “discovery”. The map, model, or diagram - whatever you want to call it - is a kind of flowchart. It is organized into swimlanes representing roles or organizational units, with boxes representing activities linked to other boxes with lines and arrows. That’s a flowchart, and BPMN is at heart just that.

The mapper might be inclined to describe the process like this: First X happens, and then it typically goes to Y, and then finally we do Z. That’s fine. It describes what usually happens, leading to a successful end state. Let’s call it the happy path. But companies don’t decide to “do” BPM because of work that follows the happy path. Work that follows the happy path is rarely the reason why the process takes so long, costs so much, or has so many errors. So BPMN asks us to dig deeper.

It starts with really basic questions:

How does the process actually start? What event triggers it? Is there more than one possible way it could start?

What determines when the process is complete? Are there different end states for the process, such as one signifying successful completion and others signifying failed or abandoned attempts?

How does the process get from X to Y? Does the person doing Y somehow just “know” it’s supposed to happen? You said it “typically” goes to Y, but where else might it go? And why?

How do you know when X is done? Does X always end in the same way? Or besides the normal end states are there exception end states where you don’t go on to Y? Are there rules that govern this?

These are questions BPMN requires you to answer, because they relate to the inner logic of that imaginary “process engine.” The mapper’s first reaction might be, “Nothing is making the process go from X to Y. That’s just what happens.” But, of course, something is always making it go. The logic is just hidden, probably inside the head of whoever happens to be doing X for that particular instance. And there is tremendous value in surfacing that logic, making it explicit in a diagram that all stakeholders in the process can understand. Without that you can’t really manage the process or improve its performance.

In my BPMessentials training, a student once asked me how to show in the diagram that a certain activity was expected to complete in five hours. I replied that that was not a question that BPMN asks. Instead, BPMN wants you to say what happens if the activity is not completed in five hours. Do you send a reminder? Notify the manager? Escalate the task? Cancel and abandon the process as a whole? Those are things that belong in the BPMN diagram.

In BPMN, a business process diagram just reveals the order of activities, when they happen, and under what conditions, including the exceptions. It does not describe, for example, how an activity is performed or where or why. In fact, BPMN barely touches on what the activity is or who performs it. Those are simply suggested by labels on activities and swimlanes in the diagram. That stands in stark contrast to Professor Scheer’s famous ARIS “house,” the complex framework of interlinked models describing the full gamut of who-where-what-when-how-why that has long defined “serious” business process modeling. It’s not that those other questions are not important - for enterprise-level process governance or even for an ordinary process improvement project, they certainly are - but they are external to the orchestration, and thus outside the domain of BPMN. In fact, they are described by other models, linked to the BPMN model through a repository. BPMN’s strength lies in not trying to do too much.

Levels of BPMN Use

In their BPMN reference guide [1], Stephen White and Derek Miers quote the epigram, All models are wrong, some are useful. By “wrong” they mean that a model is inherently an idealization, a simplification that leaves out inessential detail. Even restricting the information to the orchestration logic described by BPMN, what is essential or inessential depends on the modeler’s purpose. And the purpose of a modeler trying to capture how the as-is process works is not the same as that of another modeler designing an executable process.

This is more than a question of detail. Process modeling for description and process modeling for execution may employ different interpretations of what the shapes and lines in the diagram actually signify. BPMN’s strength comes from the fact that it can be used as both an idealized description of the sequence of activities in a process and a blueprint for automating that sequence of activities with an execution engine.

I find it helpful to classify use of BPMN in the real world at three levels, based on how the model is used. These levels reflect different interpretations of what - or how - the model means, to three distinct classes of BPMN users. These levels are not part of the BPMN specification, just part of my pedagogical approach. (Despite that disclaimer, OMG now includes my three-levels concept as “reference material” for its OCEB BPM certification exam!)

Level 1

BPMN Level 1, or descriptive modeling, is what business-oriented process mapping is all about: simply documenting the process flow. BPMN Level 1 modeling uses a basic working set of BPMN elements, most familiar from traditional flowcharting, to describe the typical order of activities and what role or organizational unit performs, or is responsible for, each one. It may omit some exception paths, and may ignore some of the rules prescribed by the BPMN specification. The Level 1 modeler is also free to ignore BPMN’s fiction of a controlling orchestration engine. Nevertheless, it is possible to apply a method and style to Level 1 modeling so that extending it to Levels 2 and 3 requires only refinement, not major structural change.

Level 2

BPMN Level 2, or analytical modeling, leverages the expressive power of the complete notation to describe the activity flow precisely, including the exception paths significant to key performance indicators. Level 2 models obey BPMN’s defined semantics and are subject to its validation rules. However, Level 2 models are non-executable.  They omit technical details - specification of data structures and expressions, for example - that would be required to execute the model on a process engine.

The BPMN specification does not clearly separate execution-related information elements in the model from the rest, but the distinction is straightforward. Level 2 models are essentially bounded by what you can see in the diagram. Diagram labels take the place of the missing technical details. For example, instead of using formal data expressions to specify the branching logic at a gateway, Level 2 models simply label the gateway and the paths out of it so that the business meaning is clear.

Thus BPMN Level 2 reflects a business-oriented perspective, and is understandable by business analysts and business architects, not just IT. Nevertheless, it requires disciplined thinking and attention to detail. It exploits BPMN’s power to express the events and exceptions that govern real-world process performance and quality, and thus can be used to analyze process alternatives, both qualitatively by inspection and quantitatively by simulation analysis. It really is that long-sought common process language shared by business and IT. 

Most business architects, business process analysts, and business analysts can learn to use BPMN at Level 2, but it is difficult for some business users. One reason for the difficulty is Level 2 forces the modeler to go along with BPMN’s assumption (or pretense) of a central controlling engine that “makes” the process advance from one step to the next, even when there is none in reality. That mental leap is difficult for some, but it is the key to the making models complete and self-consistent.

There are actually two distinct use cases for BPMN Level 2. One is as just described: documentation of as-is and to-be process flow for purposes of analysis but not execution in a process engine. The modeler can leverage the expressive power of BPMN’s full palette of activity, gateway, and event types to describe and analyze the operational behavior of the process, even if there is no intention to automate it.

The second use case is creating the business view of an executable process design in a BPMS. Here BPMN is used to define the process model underlying the executable design, but absent technical detail. Why is this not Level 3, executable BPMN? The reason is that the BPM Suite does not use BPMN for that executable detail.  Instead, it layers its own execution-related attributes on top of the BPMN model. The executable design is thus vendor-proprietary, but the underlying flow model, as expressed in the BPMN diagram, complies with the BPMN standard, and remains visible to business throughout the implementation cycle.

This hybrid style is in fact the way the majority of BPM Suites work today, including those from Adobe, Appian, Cordys, Fujitsu, Lombardi, Oracle, SAP, Savvion, SoftwareAG, TIBCO, and Vitria. In fact, promotion of BPMN by these vendors is a key reason for its widespread adoption as a standard. However, the BPMN tools provided by BPMS vendors frequently deviate in various ways from the BPMN specification. They may omit activity, event, and gateway types that their process engine does not support, and may include other constructs not described by BPMN.

Level 2 modeling is the main focus of this book. Mastering it requires understanding of BPMN’s hidden assumptions and the deeper meaning of its core concepts, and the book explains them. We also provide a method and style that bridges the gap between Level 1 models and the more disciplined approach required by IT, focusing on events and exception handling, using specific diagram patterns to identify distinct classes of exceptions.

Level 3

BPMN Level 3, or executable modeling, is brand new with BPMN 2.0. Whether it becomes the accepted standard for executable process design remains to be seen, although the undeniable influence of its principal backers, IBM, Oracle, and SAP, assures it will play a significant role.

BPMN Level 3 is similar to the second use case of Level 2, except that the executable detail is fully captured in BPMN standard attributes. It is part of OMG’s broader goal of Model Driven Architecture (MDA), in which executable systems are governed by graphical models rather than “code.”  BPMN at Level 3 is ostensibly targeted at developers, not business architects or analysts. However, as BPM tools mature, we can expect to see them hide much of the technical complexity of executable process design, so that business process analysts and architects will be able to create robust process implementations with little or no developer support.

BPMN Level 3 begins with a Level 2 diagram and adds detail in the XML underneath the shapes and symbols. It transforms BPMN from a diagramming notation to an XML language for executable process design. As of this writing, tools supporting that language have not yet been released. Those tools will determine the method and style appropriate to Level 3, but we provide in this book a glimpse into how that language works to specify process data, service interfaces, and human task assignment.

[1] BPMN Modeling and Reference Guide, Stephen A White, PhD and Derek Miers, Future Strategies, 2008.

Creating business process models that can be shared effectively across the business - and between business and IT - demands more than a digest of BPMN shapes and symbols. It requires a step-by-step methodology for going from zero to a complete process model. It also requires consistent application of a modeling style, so that the modeler’s meaning is clear from the diagram itself. Author Bruce Silver explains not only the meaning and proper usage of the entire BPMN 2.0 palette, but calls out the working subset that you really need to know. He also reveals the hidden assumptions of core concepts left unexplained in the spec, the key to BPMN’s deeper meaning.

The book addresses BPMN at three levels, with primary focus on the first two. Level 1, or descriptive BPMN, uses a restricted palette in combination with some relaxation of BPMN’s rules to meet the needs of business users doing basic process mapping. Level 2, or analytical BPMN, takes advantage of the notation’s exceptional expressiveness for detailing event and exception handling, key to analyzing and improving process performance and quality. Level 3, or executable BPMN, is brand new in BPMN 2.0. Here the XML underneath the diagram shapes can be deployed to a process engine to actually execute the model.  The method and style recommended by the book aligns these three levels, facilitating business-IT collaboration throughout the process lifecycle.

Inside the book you’ll find detailed discussions, illustrated with over 100 examples, about:

• The questions BPMN asks, and does not ask
• The meaning of basic concepts like starting and completing, sending and receiving, waiting and listening
• Subprocesses and hierarchical modeling style
• The five basic steps in creating Level 1 models
• Event and exception-handling patterns
• Branching and merging patterns
• Level 2 modeling method
• Elements of BPMN style: element usage and diagram composition

Paul Harmon, Executive Editor, BPTrends, and Author, Process Change: 

This is the first book on BPMN that I can enthusiastically recommend!

Sandy Carter, Vice President, IBM Software Group SOA, BPM, and WebSphere

Bruce’s thought leadership can help us think through the common language that brings IT and Business together …

Wolfgang Hilpert, Senior VP, NetWeaver BPM/SOA, SAP

An invaluable reference forthose using BPMN, regardless of their tool of choice. I highly recommend BPMN Method and Style.

Manoj Das, Director BPM Product Management, Oracle

Could have been aptly named BPMN Bible for Business Analysts.

Alexander Grosskopf, Author, The Process

A comprehensive method for those that take [BPMN] to the next level…

What They Said…

“The first book on BPMN that I can enthusiastically recommend… It teaches you about the elements of BPMN, but much more important, it teaches you how to use BPMN, how to approach problems, [with] guidelines for what constitutes a good BPMN style…. If you want to learn to use BPMN, this is the book to buy and study.”
Paul Harmon, Executive Editor, BPTrends and Author, Business Process Change

“Balanced, digestible guidance and insight for business people. BPMN Method and Style demystifies BPMN’s deceptively sophisticated concepts, laying the foundation for rich, meaningful collaboration between “the business” and IT. This well organized book is an invaluable reference to those using BPMN, regardless of their tool of choice. I highly recommend it.”
Wolfgang Hilpert, Senior Vice President, SAP AG NetWeaver Solution Management - SOA & BPM

“BPM is a top priority for companies in today’s economy. Bruce’s thought leadership can help us think through the common language that brings IT and Business together toward that common goal.”
Sandy Carter, IBM Vice President, Software Group SOA, BPM, and WebSphere

“A very valuable book for anyone interested in BPM modeling… The book’s pattern-based approach enables quick application of the acquired knowledge, while anti-patterns show and help protect against typical pitfalls.”
Matthias Kloppmann, IBM Distinguished Engineer, Chief Architect BPM Technology

 ”An excellent basic framework, showing which features are useful at each layer of refinement. This book could have been aptly named BPMN Bible for Business Analysts.”
Manoj Das, Director, BPM Product Management, Oracle

“Bruce Silver has logged more time teaching people BPMN than anyone else on the planet. Here he combines that experience with a unique approach to process modeling and the result is a book that shows you how to design/document processes with clarity and precision.”
Robert Shapiro, Chairman, WfMC Conformance Working Group (BPMN Portability), Manager, ProcessAnalytica LLC, and SVP Research, Global 360

“A comprehensive method for those that take [BPMN] to the next level.”
Alexander Grosskopf,  Author, The Process

 ”Provides best practices around complex aspects of BPMN such as boundary events, exception handling, message flows, and data modeling… ”
Bhagat Nainani, Senior Director BPM Engineering, Oracle

Many of the world’s top companies have sent their process modelers to this training, including:

Aetna
Argonne National Laboratory
BAE Systems
Bank of America
BearingPoint
Booz Allen Hamilton
Calpine
Charles Schwab
Citrix Systems
Cocal Cola Bottling
Cordys
Cox Communications
Deloitte & Touche
Delta Dental
DST Systems
Duke Energy
ECS
Fidelity Investments
Fifth Third Bank
First Data
Freddie Mac
Genesys Telecommunications
Harris
Intuit
Kaiser Permanente
L-3 Communications
Lombardi Software
Lufthansa
Merck
Microsoft
Mitre
Navistar
Oracle
Pricewaterhouse Coopers
QVC
Qwest
Scripps Networks
State Farm Insurance
State Street Bank Canada
Teleflora
Travelers
UBS
Unum
Valero Energy
Wells Fargo
Yum Brands