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.