Comment 7 on "Anti-pattern: End-to-End Process Orchestration" comment 6

Anatoly,

I think that just having more than one pool within a BPMN diagram is not enough to consider it as choreography. My feeling: the difference between orchestration-dominant and choreography-dominant processes is in their behaviour. The former have “globally predictable” behaviour. The logic of templates (one pool implies one instance) is enough to implement such processes.

Diagram below (process for “selection of the best offer”, optimistic case) I would consider as choreography – its behaviour is less predictable. The logic of instances is required, because pool “VENDOR” actually implies many instances (one per each vendor involved in a bid).

Of course, in BPMN all vendors operate in the same way and that is perfect from the point of view of the company (i.e. pool “COOR”), because the company has to prove that all vendors are treated equally. In some sense, pool “VENDOR” acts as vendor’s proxy (or insulation layer). This allows us to make such coordination more explicit (easier to validate, control, monitor, certify, etc.)

Thanks,

AS

Comment 4 on "Anti-pattern: End-to-End Process Orchestration" comment 3

Anatoly,

I think, that diagramm is "process orchestration". 

Yes, I should use BPMN instead of English next time.

Thanks,

AS 

Comment 2 on "Anti-pattern: End-to-End Process Orchestration" comment 2

Anatoly,

More comments, please.

4) My point is that novice BPM desingers tend to use former model but the latter is more realistic.

My interpretation: they (novice BPM desingers) model the process from the point of view of one of the participants – “customer”; after they have to model from the points of view of other participants, e.g. “dealer”, “production”, etc., and finally, a common view should be synthesised. So, I would say that this is just uncompleted work.


5) Branches from a parallel gateway may go over other pools? I seriously doubt this. Not in BPMN. But you are right: parallel gateways do produce asynchronous threads.

Is illustration below “process orchestration” or “process choreography”?





6) My favourite analogy to process choreography is threads programming in java.
I would treat “process choreography” as coordination between threads from different java programs -- System.exit() at one pool should not stop a particular choreography.

Thanks,
AS