Why I am looking at these MDA papers?
It is inevitable in big organizations, that there are central processes that are supported by every part of the organization. But at the same time it is desirable, to support individual processes, that respect local specialties. In this case the local units must be given the possibility to plug into the global processes. This can only be done, if the behavior of the local and the central processes is known – and by this the interaction – the choreography between them – can be defined and described. Therefore it is important to have behavior modeling languages for processes of units and of the choreography. Furthermore sometimes it is necessary to allow a local unit to describe their own processes or aspects of their own processes in their own language – a DSL – and plug them into the central processes.
If this is achieved it is a controlled powerful local flexibility with the integration into centrally controlled processes.
All of these articles and also BPMN 2.0 can help to strife towards this goal.
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.
Social Links