As for the “collect money” messages, there’s a flaw in the model of the customer process: we have to pay for the pizza before we eat it, and that task is still missing. The pizza service may provide information or speed up its order processing in anticipation of a new order, but the baking, delivering, and collecting of money doesn’t change just because an inquiry came in. The rationale behind the first one is that our inquiry does not influence the sequence flow of the deliverer. The first one comes from the “inquire at delivery service” task the second one connects to the “collect money” task. In two cases, the message flows do not end in an activity or event, but at the participants’ respective pool boundaries. Pizza sale supplier Lieferjunge deliver pizza take the money end Pizza-Bäcker bake pizza order received pizza order customer hunger noticed choose pizza order pizza eat pizza hunger satisfied pizza received 60 minutes pizza received call pizza delivery service It shows two independent processes collaborating. BPMN calls this form of visualization a collaboration diagram. Both processes in the combined representation would look just as they did before, but now they connect through message flows. If we go with pools, the whole process looks like below. Strictly speaking, the diagram is not semantically correct because message events always refer to messages received by the process from outside, and that’s not the case here. It is impossible to differentiate the two visually.
Other tasks are carried out by roles oblivious to their partners, such as baking the pizza and eating the pizza.
Pizza- process customer hunger noticed choose pizza order pizza pizza received eat pizza call pizza delivery service 60 minutes pizza received supplier pizza baker bake pizza delivery boy deliver pizza take the moneyīut this doesn’t work well: There are tasks and events that reference interaction within the pool – waiting for the delivery, for instance, or collecting the money. Our delivery person takes it to the customer and collects the money, whereby the process completes successfully. Presumably, it looks like here: As soon as we receive an order, we bake the pizza. Now consider the broader picture, and think about how this process happens from the point of view of the pizza delivery service. We already examined the process represented below in connection with the event-based gateway: One thing to remember is that if you strive to harmonize your functional and technical process models to achieve a better alignment of business and IT, you inevitably face this type of process modeling whether you use BPMN or not. We will show the usefulness of this new thinking by example. In the medium and long terms, however, avoiding pools denies you a powerful device for increasing the significance of process models. That’s traditional, and it’s a pragmatic solution during, say, a transitional period that allows your co-workers to adapt. You can eliminate pools and work just with lanes, modeling the message exchange as normal tasks as shown before. What does that signify, however, for purely functional process modeling, in which you also describe processes not controlled by such a process engine? There’s no general answer to that question. Have you heard of service orchestration in connection with Service Oriented Architecture (SOA)? That’s almost exactly the task of a process engine, except that these services are not only fully automated web services they also can be tasks executed by human process participants as directed by the process engine. So the process engine equates to the mysterious, almighty process conductor.
In that world, the process engine controls all tasks in the process, even though different task managers may execute them. Even though BPMN lanes look very much like those of other process notations, they represent an entirely different way of thinking, which we attribute to BPMN’s origin in the world of process automation. It reveals a basic principle, however, that you must understand. That seems complicated – and you don’t have to choose this method for practical modeling. Stefan task 4 start Christian task 3 passing on to Stefan start Falko task 2 passing on to Christian start Robert start task 1 passing on to Falko