Stephen White has already blogged about it: BPMN 2.0 is finished, approved by OMG architecture board and will be published soon. For camunda it was mainly Falko Menge who represented us in the FTF, and he did a very good job (thanks Falko!). Falko and me also wrote a good part of the “BPMN 2.0 by Example”-Document (many thanks to Ivana Trockovitch, Denis Gagné and the other authors!), that should work as a tutorial for understanding the basic principles of BPMN. Because the whole package is not published officially yet, I just want to blog one of the two chapters we wrote that I consider interesting for people who want to get from “business-friendly simple diagrams” to “directly executable XML”.
At some points I will also add some comments from our project experiences that of course could not make it into the official OMG document.
Chapter 6: Incident Management
In this chapter we want to show the different perspectives you can take on the same business process, using BPMN. In the first step we will provide a rather simple, easy to read diagram that shows an incident process from a high level point of view. Later on we refine this model by moving from orchestration to collaboration and choreography. In the last step we take the organizational collaboration and imagine how a process engine could drive part of the process by user task assignments. The main purpose of this chapter is to demonstrate how you can use BPMN for creating simple and rather abstract diagrams, but also detailed views on human collaboration and finally for technical specifications for process execution.
Creating process models for both business AND it is actually one of the absolutely main topics of our consulting business. And it is a very big struggle, of course. For us it was important to show in the document that BPMN is not necessarily “too complicated for business”, because it totally depends on how you actually use the standard when process modeling. That’s why we always need a Framework around BPMN if we want to apply it in bigger modeling engagements.
6.1 High level model for quick understanding
Figure 6.1: Incident management from high level point of view
The shown incident management process of a software manufacturer is triggered by a customer requesting help from her account manager because of a problem in the purchased product. First of all, the account manager should try to handle that request on his own and explain the solution to the customer, if possible. If not, the account manager will hand over the issue to a 1st level support agent, who will hand over to 2nd level support, if necessary. The 2nd level support agent should figure out if the customer can fix the problem on her own, but if the agent is not sure about this he can also ask a software developer for his opinion. In any case, at the end the account manager will explain the solution to the customer.
This diagram is really simple and somehow a “happy path”, because we assume that we always find a solution we can finally explain to the customer. The model lacks all details of collaboration between the involved employees, and the abstract tasks indicate that we do not have any information about whether the process or parts of it are executable by a process engine. This diagram is useful, if you want to scope the process, get a basic understanding of the flow and talk about the main steps, but not if you want to dig into the details for discussing process improvements or even software driven support of the process.
In our Framework, we call that kind of diagrams “strategic process diagram”, or sometimes “logical-abstract process diagram”. You could say that this way of process modeling is according to the Process Modeling Conformance sub-class “Descriptive” defined in the BPMN 2.0 spec. We do this kind of modeling very often in As-Is-Workshops and early stages of a process improvement project. And we often do not use software tools for it, but white board drawing and sometimes our home-made BPMN magnets.
The diagrams in the examples document however are all made with Trisotech’s Visio-based BPMN Modeler, provided for this purpose by Denis Gagné. The cool thing is that we could directly serialize the diagrams into BPMN 2.0 XML with that tool 
6.2 Detailed Collaboration and Choreography
Figure 6.2: Incident Management as detailed collaboration
We can take a closer look at the ping-pong-game of account manager, support agents and software developer by switching from a single-pool-model to a collaboration diagram, as shown above. We can now see some more details about the particular processes each participant fulfills, e.g., the dialogue between the account manager and the customer for clarifying the customer’s problem, or the fact that the 2nd level support agent will insert a request for a feature in the product backlog, if the current release of the software product cannot cover the customer’s demand satisfactorily. We have also specified each task as manual, which means that we still think of the processes as completely human-driven with no process engine involved. This could hypothetically be the As-Is-state of the incident management before the introduction of a process engine. The next step could be to define whether we want to drive the complete collaboration by a process engine, or only parts of it. But before we discuss that matter, we can have a look at an other way of modeling such a ping-pong-game, the choreography diagram shown below.
Figure 6.3: Incident Management as choreography
This diagram only shows the tasks that are dedicated to the communication between the different process participants, hiding all internal steps, e.g., the task that inserts a new entry into the product backlog. Note that the diagrams shown in Figure 6.1 and 6.2 have no formal connection between each other, whereas the Figure 6.2 and 6.3 have the exact same semantic model behind them and just provide different views on it. See also Annex A for an XML serialization of the underlying semantic model.
Some BPMN experts consider collaboration diagrams, i.e. the modeling of different process participants in different pools, only as a pattern for business-to-business-collaboration. Well, you can use collaboration diagrams that way, but their use is definetely not limited to that area. In fact, especially in companies that are NOT process-orientied, it can be very enlightening to model the collaboration between departments,teams or even roles (as we did here) explicetely with pools and message flows. And it can be the first step towards engineering the requirements for a workflow management – solution, as shown in the next paragraph.
6.3 Human-driven vs. system-driven control flows
Figure 6.4: Incident Management with human-driven and system-driven pools
If we imagine we are realizing a project for automating the incident management process, we could now decide which parts of it should be actually executed in a process engine, and which parts should remain human-driven. In this scenario we decided that the account manager should not be bothered with web forms or task lists, he should just send an email if he wants to report a customer’s problem, and receive an email when the process has completed.
The same idea applies for the software developer: Let us assume the 2nd level support agent sits in the same room as the developers. Maybe it is more efficient if the support agent just walks over to the developer and talks about the issue, rather than playing some time consuming ping-pong-game with task assignments. Therefore, we want to keep this part of the incident management human driven as well: no process engine driving the collaboration between 2nd level support and software developers. But we do want the assignment of tickets to 1st and 2nd level support agents by a trouble ticket system, which now takes the role of the process engine and therefore is modeled in a dedicated pool.
That system can actually receive and parse emails sent by the account manager and opens a ticket for it. If the 1st level support agent decides that this is a 2nd level issue, he does so by documenting his decision and completing the assigned task “edit 1st level ticket”. The trouble ticket system then routes the ticket to the 2nd level support agent.
When that agent has finished, he maybe declared the issue to be fixed in the next software release. Then the trouble ticket system makes a service call on the product backlog system, a new feature we have introduced with our process engine: The entry does not have to be inserted manually any more. In the end, the trouble ticket system will send an email to the account manager, containing the results of the incident management, and close the ticket. The account manager can then explain the solution to the customer based on the information in the ticket.
Figure 6.6: This is the only part of the whole collaboration we will execute in a process engine
Separating the “human control flow” from the “engine control flow” is actually the heart of our modeling approach, when aligning the process models of business and IT. How can we consistently visualize that some routing decisions, i.e. Gateways such as XOR, AND and Event, are taken by the process engine, and others by the people working in the process? We can’t, as long as we model both of them in one pool! For a single pool, there can be only one driving force, that’s why it is totally irrelevant in what lane you put a gateway (a fact BPMN beginners often don’t know and hardly understand), the gateway will be interpreted by the single driving force behind the pool anyway. In the end, there will be only one pool in this diagram that is actually executed by a process engine, the other ones will be “executed” by the people working in the process (Account Manager, Support Agents, Developer). We have also created an executable BPMN 2.0 XML of the process engine pool for the examples document.
Figure 6.5: This rather simple diagram is all we have to show to the account manager
Of course, this way of modeling both human-driven and system-driven control flows in one diagram is just a proposal, that should give an idea of useful modeling approaches based on collaboration diagrams. It should demonstrate how BPMN could support Business-IT-Alignment in process modeling: We can hand over the modeled process engine pool to an actual process engine for execution, while we can show the other pools separately to our process participants, the support agents or the account manager, and discuss their involvement in the collaboration based on those simplified views on the same, consistent collaboration model. This gives us the opportunity to talk with both Business people and IT people about the same process model, without overburdening business people with too complex diagrams or IT people with too inaccurate process models.
Further comments (not part of the examples document)
Basically, the whole approach goes like this:
- Make a “strategic” process diagram (Figure 6.1), just a simple sketch for a quick understanding
- Make an “operational” process diagram (Figure 6.2) for analyzing the collaborational aspects
- Enrich the diagram with the aspects of a process engine, therefore adding a pool for the process engine
- Take that process engine pool into your technical environment and enrich it for execution (make a “technical” process diagram)., see also here and here.
Defining Views in Signavio
Showing just experpts of the “big” collaboration diagram to different target groups, e.g. the pool for the account manager, is of course a matter of tooling: We do not want to have redundant diagrams, one only containing a single pool, the other one the whole collaboration. That’s why our friends at
Signavio implemented a cool “view concept” for us, where we can define certain views on a collaboration diagram, and then show those views to the according process participants for discussion etc.
Furthermore, we are currently implementing the whole tool chain for Business and IT based on open source components in our project camunda fox, so it’s worth to stay tuned.
If not, here comes the core message of it: I divided BPM-Systems into the categories “pure play”, “embedded”, “saas” and “open source”. I consider that useful, although there can be overlappings such as an open source – BPMS that is embedded into a commercial product like an CRM or ERP. Then I thought about the future of commercial pure play BPMS and came to the result, that a shift of market shares is likeley, boosting the relevance of both Open Source BPM and SaaS BPM at the expense of “classical” on premise, closed source BPM products, which was also one of the reasons for our engagement in the 
. I agree. Only point is that I don’t hear much discussion on methodology for ACM.
