Prologue
The previous installment, devoted to BPMN 2.0 positioning and status, was a mere warm-upi. Now comes some hard stuff, that is, how one can really use BPMN 2.0 - herein referred to simply as BPMN - for business-oriented modeling in practice.
To appreciate the new standard and get some hands-on experience in ARIS BPMN modeling, I armed myself with several books, not to mention the OMG specifications. Unfortunately, I got lost very quickly and could not see the forest from the trees. I have yet to find a public material explaining the basic concepts with the help of a consistent case study, i.e. a set of related BPMN diagrams, illustrating the essential concepts in a top-down fashionii.
Actually, experts usually begin exploration of BPMN topics with details on process-related notation and syntax, using a bottom-up approach. Therefore, I decided to develop a small case study from the scratch, a simplified one, yet as realistic as possible.
The BPMN 2.0 World
The BPMN business world consists of participants, who collaborate by means of message exchanges and execute business processes to achieve their objectives.
A Participant is defined in OMG specifications as a "business entity (e.g., a company, company division, or a customer) or a business role (e.g., a buyer or a seller) that controls or is responsible for a business process."iii One can immediately notice a B2B flavor in the above definition and indeed, BPMN is equally good at modeling B2B processes (or B2C, G2G, G2C etc.) as in case of internal processes.
A Collaboration "…depicts the interactions between two or more business entities. Collaboration is the act of sending messages between any two Participants in a BPMN model." A Message in turn is "…an object that depicts the contents of communication between two Participants. A Message is transmitted through a Message Flow." It is worth to note that the definition of Message is very flexible and does not constrain its nature in any way. Usually, BPMN diagrams depict message flows as transmissions of information, from a simple status indicator to complex information sets, such as documents. Usually as well, the physical transmission medium does not matter too much in case of process modeling for business purposes. Thus, the information can be transmitted using paper, fax, telephone or strictly electronic means. Message definition apparently allows also portraying goods transfer between Participants, as the official OMG examples of BPMN diagrams include pizza as a message.
Finally, a Process is a "sequence or flow of Activities in an organization, with the objective of carrying out work." In general, a process (or processes) performed by one participant are orchestrated. As a conductor conducts the players in a symphonic orchestra, the CEO or a Business Process Management Systems (BPMS) controls all activities within scope. On the other hand, exchanges of messages between Participants - and indirectly, between their processes - are choreographed. A dance troupe does not have a conductor. The movements of each dancer are designed before the performance and synchronized with what the others do via choreography, thus BPMN uses this term.
Private and Public
BPMN provides a simple process definition, generally consistent with most of other ones, but it provides also a more sophisticated classification of processes. Essentially, two types of processes are distinguished - private and public ones.
A Private Process contains all internal activities within its flow and is not revealed to other collaboration participants. Such processes, of course, have been the subject of modeling for tens of years. Private processes are either non-executable or executable. This is clearly a bow towards a dual nature of BPMN specifications. A non-executable private process is modeled during analysis and design, usually by business (process) analysts. The model portrays existing or intended process behavior, but it cannot be executed by a BPMS, due to relaxed BPMN syntax and lack of all the required technical details. Conversely, a model of an executable process has all the technical details and observes all BPMN formal rulesiv.
A Public Process in turn "…represents the interactions between a private Business Process and another Process or Participant. Only those Activities that are used to communicate to the other Participant(s) are included in the public Process." A public process model is therefore a simplified view, or subset, of the private one. Activities dealing exclusively with internal process flow are excluded from the view. In short, the public process model reveals to the world whatever happens inside the company, without a request to sign a Non-Disclosure Agreement.
Let us talk
Enlightened by the knowledge of basic concepts, let us turn now to the announced case study. I sought and obtained permission from ACME Products Company, to illustrate some parts of their operations using core BPMN concepts. ACME is famous worldwide for its great variety of high-quality gadgets it produces and offers. It is also a very innovative company and is renowned for speedy deliveries. ACME is fully owned by Roadrunner Corporation, but this is generally not known, as its parent company prefers to stay in the shadows.
To begin the top-down BPMN tour, please have a look at the screenshot above (click to enlarge it). It shows neither a Gordian Knot nor a space station. The screenshot portrays the so-called BPMN Conversation Diagram, an overview of partner network and communications. In particular, it allows us to see who communicates with whom and about what.
The participants of ACME conversations are represented by pools, denoted by boxes. A Pool is probably the most important generic concept in BPMN. It is formally defined as a "…graphical representation of a Participant in a Collaboration. It also acts as a swimlane and a graphical container for partitioning a set of Activities from other pools." As a matter of convention, if a pool reveals its activities inside, it is called a white-box pool. Otherwise, it is a black-box pool.
Conversations
On the presented conversation diagram, ACME and most of the other participants are business entities. That goes to Bank XYZ and Courier Services Company, their real names not revealed due to confidentiality reasons. This goes also to Wholesaler, Retailer and Carrier. Supplier and Consumer are business roles. Please note the latter is not a business entity, but a person. Please note also the triple fangs at the bottom of most of the boxes. No need to fear them, they simply indicate there are many Wholesalers, Retailers, Consumers etc., having conversations with ACME. This triple fang symbol is called a multi-instance marker and is used if there are many participants hidden behind the pool symbol.
The other symbols used on a Conversation Diagram are Conversation Nodes, the hexagons, as well as Conversation Links. A Conversation is "…a logical grouping of Message exchanges (Message Flows). […] Message exchanges are related to each other and reflect distinct business scenarios. The relation is sometimes simple, e.g., a request followed by a response. […] However, for commercial business transactions managed through Business Processes, the relation can be complex, involving long-running, reciprocal Message exchanges."
As for the ACME diagram, we can see there are three conversations going on with various types of Customers. There are conversations on:
- Sales Orders, between ACME and Retailers
- Framework Contracts, between ACME and Wholesalers
- Internet Orders, between ACME and Consumers
This reflects distinct distribution channels ACME has and each of them is handled in a different way. Please note Bank XYZ is involved in all the conversations above, whereas Courier Services Company is not involved in Framework Contract conversations. Please note also Suppliers are involved directly in conversations on Sales Orders and Purchase Orders, while Carriers are directly involved in conversations on Framework Contracts and Purchase Orders.
Epilogue
Each conversation between collaborating participants is realized by a series of coordinated and related message flows. It means each conversation node has to be expanded somewhere to show its component message flows.
This can be done using a Collaboration Diagram. In fact, BPMN specification names Conversation Diagram as a simplified, informal description of collaborations taking place between the mother company and its business environment. We will dive into collaborations in the next installment of my Fire and Ice Blog, coming soon.
Installments of Fire and Ice Blog:
References
- i - See Fire and Ice. The road to BPMN 2.0 for ARIS Process Analyst. Part 1. The Overture.
- ii - Many thanks to Sebastian Stein, who reviewed the case study and provided valuable comments.
- iii - All definitions in italics are quotations from Business Process Model and Notation (BPMN), OMG, January 2011, Version 2.0
- iv - Using the terms of BPMN conformance classes, non-executable process models use the Descriptive or Analytic Class, while executable process models use the full power of BPMN 2.0 Common Executable Class.
