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.
Hi Grzegorz,
this is good stuff and I see that there are more and more BPMN tutorials here on this site (e.g. my "Learning BPMN" series [which BTW is not dead, but I am just swamped] or the EPC/BPMN comparisons by Ivo). Maybe we should coordinate this or create a tutorial start page somewhere *hint hint, Sebastian*.
One thing I was wondering when implementing the conversations is a convention/structure to name those. As you mention these -the hexagons- can be a collection of multiple messages and not only a different visual representation of single message flow. Therefore the name of a conversation has to be different than the message that is contained in the conversation IMHO.
Do you have a suggestion how one can build up a conversation structure/conversation-message hierarchy and name those to make sure that if you search for conversations in Explorer you find the correct one? Unfortunately I don't have any real life project experience with conversation diagrams but I can imagine that you will have to do this similar to the program flow charts that you create as assigned models on the connection between two application system types in IT Architect. There ARIS automatically creates a naming scheme like this: "first AST - second AST".
Best
Roland
Hi Roland,
it is a pleasure to receive a comment from you. Indeed, conversation diagrams do not receive enough attention by experts and I suspect they are rarely used in practice.
As of now, I do not intend to create some sort of ARIS standard for BPMN 2.0 modeling. If it emerges over time, it will be a by-product, so to speak. My overriding goal is to suggest a BPMN-oriented EPC modeling style. However, you are absolutely right, there should be a way to relate conversation links to the messages/message flows they represent. I will try to find a suitable technique and mention it in Part 3 of my blog, devoted to collaboration diagrams.
GG
"BPMN-oriented EPC modeling style": this is interesting. You might want to have a look at what we did for Deloitte's Industry Print, where we implemented a "lean EPC" with a ton of assigned FADs. This is not my preferred way of doing this, but it might give you an impression.
Keep me posted once your conventions/method have evolved please.
The diagram is a helpful high level overview of what a business does as well, even for new hires/contractors. I'm doing webmethods integration projects (ie I implement the hexagonal part) and at my current client I have to look at existing messages in Trading Networks to figure out what is being exchanged as nothing is documented.
In reply to Hi Abhijit, we work actually by VladoB
Thank you for your comment. I think you will find a Collaboration Diagram more useful. However, for B2B situations, Choreography Diagrams are the best. They cannot be developed using ARIS for the time being though, as they are not included in the existing BPMN 2.0 implementation.
BR, Grzegorz
