How Does a Model Mean?
[Chapter 1 from the book]
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.
10 Responses to “How Does a Model Mean?”
Leave a Reply
BPMS Watch
- BPMN 2.0 from Visio Premium 2010I mentioned in a previous post I had created a tool that converts BPMN diagrams from Visio Premium 2010 to BPMN 2.0-compliant XML. It was an interesting project because Visio itself does not internally “understand” the structure of a BPMN model. Sure, it can test many of the rules in the BPMN spec, but that [...]
- BPMN Model InterchangeOn my summer vacation I’ve been thinking a lot about the XML side of BPMN. While we usually think of BPMN as a diagramming standard, it is also – in principle – a model interchange standard, an XML format than can be exported from tool A and imported into tool B. BPMN 2.0, XPDL 2.1 [...]
- Method and Style Workshop UpdateLast Friday I had a run-through of my upcoming BPMN Method and Style Level 1 workshop. It was a good thing. I got some helpful feedback on the content, and I learned a few tricks of Microsoft Visio 2010 (having the Visio product manager in attendance didn’t hurt). It was a little rushed to squeeze [...]
Are you selling it direct or through someone like Amazon?
Amazon and other online stores. Look for it end of June.
Looking forward to your release, Bruce.
I’ll hope that as the community of practice continues to develop, the consensus will help us drive consideration for modeling vs. execution perspectives at the OMG.
When in June this book ‘BPMN Method & Style’ will be ready for ordering.
Thanks for your interest. The proof was approved today, but it takes 2-4 weeks to be set up by the distributor. I expect it will be available on Amazon.com in ~2 weeks. I will send out a notification to everyone registered on my website BPMS Watch (www.brsilver.com/wordpress) when it is available.
–Bruce
Very interesting to learn how BPMN is promoted by leading BPM Suites which sets a standard, yet how they deviate from some of these standards keep them unique in their own way.
A 2008 research paper (“Seven Process Modeling Guidelines” by Mendling, Reijers and van der Aalst*) gives seven recommendations for building better process models, based on a variety of research findings. Some of these go beyond the style and good practice recommendations given in your book (eg they advise against the use of inclusive OR routings and for the explicit use of matching split/join connectors). I wondered what your opinion was of these seven guidelines and their applicability in BPMN?
*http://is.ieis.tue.nl/staff/hreijers/H.A.%20Reijers%20Bestanden/preist.pdf
Regards,
Lyndon Roy, London UK
Lyndon,
I was not aware of this. The paper references a very early version of the style recommendations that have been formalized in the book. I need more time to review their seven guidelines, but several right off the bat I don’t agree with, including using one end event and using block-structured diagrams. I agree OR gateways can be troublesome but, as BPMN is defined, unfortunately necessary for joins at least, and often convenient for splits. Thanks for pointing the paper out. I think I will write more about it elsewhere.
–Bruce
Is there a pdf version available? Amazon does not ship to where I live. If there is not ebook then can you please specify if there are any plans ans when?
Thank you.
Vinay,
Sorry, printed book onlyl.