Frank Michael Kraft's Blog

If process parts are loosely coupled, then it is possible to discern between a Public Process and a Private Process. A Public Process contains all process parts and dependencies of the process of a Participant, that are relevant for the interaction to the other Participant. For example in a buyer – seller relationship it is not relevant if the seller has an internal approval process of of what form it is. It is only relevant if the order request is to be confirmed or not and in which time.

Therefore designing public processes gives flexibility within Participants to change processes as necessary – often without or with reduced side effects to the interation to the other Participant. This reduces cost in Process adaptations.

BPMN 2.0 has been submitted to the OMG. How to leverage success using BPMN 2.0?

Integration of Software Systems is the realization of the underlying Business Processes. Realizing As-Is Processes often leads to suboptimal results. No doubt – As-Is processes Analysis needs to be done. But Process Design is ImhO the decisive part.

It must be absolutely clear, which parts of a process are tightly coupled and which parts are loosely coupled. Tightly coupled means for example: A Customer Order can not be created unless the price determination is done. Loosely coupled means: A Customer Order can be created independent from the creation of the Delivery. The delivery creation is a loosely coupled followon process.

However, of course there are interaction between loosely coupled process parts. These need to be defined – i.e. designed. BPMN 2.0 gives the possibility to model them in a way never possible before.

In BPMN 2.0 tightly coupled process parts are those within a pool. Loosely coupled process parts are those that are modeled cross pools in Collaborations or in Choreographies.

The cut of the process – thightly or loosely coupled – is decisive for success. It is not only a system modeling or implementation question. It is also a business process question. Or why do companies outsource parts of their operations? Because they want to loosely couple, what was tightly coupled earlier. This principle makes sense within companies as well, because of enhanced flexibility.

In A scenario is a behavioral view – Orchestrating services by scenario integration it is proposed to capture service behavior in the form of a certain petri net class, especially oclets (which is an acyclic Petri net with a local precondition) and by this to model individual scenarios. A scenario is a partial execution of the service. The behavior of a service is defined by the set of scenarios for this service.

In my personal opinion the use of preconditions is a good thing in general. However in my opinion the splitting up of the whole behavior into different scenarios has also disadvantages. For example that it is not so clear, if one scenario is changed, which side effects this has on other scenarios. Also one transition for example can occur in different scenarios. Thereby probably many scenarios need to be changed, if the behavior of one transition needs to be changed. Also a problem is, that it is not so clear how to model differen alternative behaviors. If the union set of all scenarios describes the behavior of the service, it is all one. So for example if there is one big service, but the behavior can be different – for example in one case with confirmation, in another without confirmation – this is not possible to be modeled. It is just a “confirmation” scenario in the set, but it is not modeled, that is sometimes must be used, sometimes not.

Good is that in the end of the paper it is proposed to integrate the scenarios into one view. This I agree upon. My personal opinion is, that I would rather start with the integrated view. Because all the mentioned disadvantages are not there in this case.

But I admit, that the use case proposed in the paper may still be valid in a consulting experince, where the client already has described the behavior of his services in the form of scenarios. Then, the method proposed is a good way to unify them into the desired integrated view. This may also be supported by tools, which gives an additional value add.

Also notbody should be distracted by the notion of the modeling language. This is just the underlying logic. The same method can as well be transferred to industrial languages, as is proposed in the paper and as I believe. For example I see no reason why this should not be useable in a BPMN 2.0 orchestration model environment.