I’m always prattling on about “method and style” in BPMN modeling, and most folks probably don’t know what I’m talking about. My goal is maximizing shared understanding of the BPMN diagram, so it is clear and complete to anyone looking at it, even if the reader is unfamiliar with the process or the modeler’s terminology. That requires going beyond the requirements spelled out in the BPMN spec to a set of modeling conventions aimed at reducing the need for prior familiarity with the process in order to understand the diagram. “Completeness” also implies (to me) understanding at a glance how the process starts, what the instance represents, the possible end states of the process, and the interactions between the process and external entities, such as the requester, service providers, and other internal processes. Not a lot to ask.
Part of the backlash against BPMN 2.0, and I am very aware of it, is related to the fact that the narrative of the specification, all 500+ pages of it, utterly fails as a “teaching” document. There are only a couple examples of process diagrams in it, and one of them I maintain contains serious violations of the specification itself (more on that in a subsequent post). Figure 10.1 – An Example of a Process, on p. 145, is “valid” BPMN but not the best BPMN “style”. It might be helpful to show how a diagram as basic and innocuous as this would look after applying Method and Style principles. Here is the diagram from the spec, modeling a library book lending process:
One of the basic principles is that how the process starts and its possible end states should be obvious from the diagram itself. There are three primary ways a process starts: upon external request (Message start event), manual start by a process task performer (None start), and a scheduled process (Timer start). You can also have Conditional or Signal start, but these three are the main ones. Now it is true that you can set an “instantiate” attribute of a Receive task to mean it acts like a Message start event, but the value of that attribute is invisible in the diagram. So technically this diagram is ambiguous whether it means manual start followed by wait for a book request, or the book request message instantiates the process. The latter is almost certainly what the modeler intended, so better to use Message start event to indicate that unambiguously.
How does the process end? Another important M&S principle is that each distinct end state of the process should be represented by a separate end event, labeled to indicate the end state. You should not mix success and failure end states in the same end event, and you should not have two end events in a process level (i.e. top-level or subprocess) with the same name. If they are the same end state, share the end event; otherwise give them different names. In this diagram success and failure end states are mixed in a single unlabeled end event. It’s legal, but not as informative as the model might be.
I also ask students to show message flows in the diagram wherever message events or Send/Receive tasks are used, since they clarify the name of the message (label on message flow) as well as the external entity, shown as a black box pool at the other end of the message flow. This help eliminate spurious “sends” within a process (illegal in BPMN) and helps place the process in the global business environment. In this diagram there are two external entities, the Borrower and a database that holds the status of the book. The Borrower is clearly a pool, but the database – actually the book status record in that database – is probably better represented as a data store. The diagram is confused on whether the book status record is a data store or a pool; it updates the status with a message but queries the status with a service task, which I think is better modeled using data store and data association rather than a message.
More important than all this technical mumbo jumbo is the fact that the diagram only makes sense to someone who already knows how a lending library works. Explicit representation in the diagram of the Borrower (as a pool) and the book status (as a data store) would make the process logic much clearer to anyone, regardless of prior understanding of the process or terminology.
One could criticize the model’s business logic as well – the requested book may not be in the collection at all, there is no allowance for that – and there is no time limit on the task Checkout Book, which depends on the Borrower, so this process could hang at that point.
In M&S, there are really two distinct end states of this process: the book is checked out, or the request is canceled. So there should be two end events, appropriately labeled, and the process logic should cover all possibilities. If I were to redraw this model according to M&S principles, it would look something like this:
The message start indicates it starts on request from Borrower, and the two end events indicate we want to distinguish two end states, called Checkout complete and Canceled, with appropriate final status messages returned to the requester The Book status is a data store, with data associations indicating queries and updates from service tasks. Since the flow logic depends on this data element, this detail in the model clarifies the logic. In a process this trivial, you might say adding this detail is a waste of effort. But if you are going to the trouble of modeling the actual processes in your company, and you would like someone else to understand it just from the diagram itself, following principles of style like this are a big help.
Bruce,
Certainly the M&S style adds more information, but even I, who spends time looking at process diagrams, find it confusing. What is the difference between decision box after “Get book status” and “Send offer to hold” as they have different symbols; why is there no “Cancellation” process step
So what chance does an end user have who *doesnt* want to look at a process, but just wants to get the job done – or a customer (in this case a book borrower) who is using a self service portal. The confused mind says “No”. And No means no adoption.
But this level of process information is requried for the Business Analyst to brief the IT team. So what is the answer? Multiple views – BPMN view plus with simpler end user oriented views based on user and keep them in sync?
Thoughts?
Great post – I’m all for clarity. It’s important we can all understand this stuff. Just to make sure I’m clear – I think there are 3 line styles and 3 arrow head styles used in the enriched diagram. Can you help me understand when to use each? Can I use each of the different arrow heads on each line style? The differences are probably quite subtle. Perhaps this is covered in your training classes? Thanks. H
Hilary,
The 3 connector types are defined by BPMN. The solid arrow (“sequence flow”) is flow of execution within a process. The dashed connector with the triangle arrow (“message flow”) is communication between a process and entities outside the process, here the Borrower. The dotted connector with a V arrow (“data association”) represents data flow; technically it is a mapping between a process variable (“data object”) or persisted data (“data store”) and a process activity input or output. That’s all in the spec, nothing to do with method and style.
Ian,
Like my answer to Hilary, this is straight BPMN, nothing to do with M&S. Regular gateway routing is based on process data conditions, in this case the Book Status retrieved in the task Get Book Status. The gateway with the double-ring inside is called event gateway, with routing based on which future event occurs first, here either receiving the response or the 1-week timeout. Event gateway lets you wait for a response, but take some exception path if the response does not arrive. Some say business people cannot use BPMN because they don’t know things like this already, but I reject that. The number of new shapes and symbols to learn is small and manageable… nothing close to the full BPMN palette.
[…] BPMN and Business People – Bruce Silver Some say business people cannot use BPMN because they don’t know things like […]
Hello,
I know it’s not the subject of this post, but I want to share with you my problem.
I am asking a question if there is a way to identify an asynchronous communication in BPMN 2.0 model by parsing the BPMN 2.0 XML file.
Comparing Intefaces, InMessageRef and OutMessageRef… or just the use of an intermediate events message shows that’s an asynchronous interaction.
Thanks for your reply
Excellent post.
What are the best resource to learn BPMN 2.0? Could you recommend some books to me.
Also if you have executable BPMN examples with its XML BPMN, I will be so glad if you can share it with me.
I think my book BPMN Method and Style (www.bpmnstyle.com) is the best for learning proper use of the notation. For the executable XML, I recommend the document “BPMN By Example” on the OMG website.
Hello
I have worked with EPC modelling based on ARIS7.1 software here i have a question if it’s possible guide me
in epc modeling we have an object it’s name is “process interface” that link processes together based on events but i don’t know how can i do this based on BPMN modeling
best regards and thanks for your examples
bahram najedy
I am not familiar with the details of EPC. BPMN allows you to define the process interface (process/ioSpecification/inputSet, etc.) but it is just in the XML, not in the diagram. I refer you to the BPMN 2.0 spec (or my book).