ebBP 5/15/2005: BPMN Next Version and Next Steps

[Monica J Martin <Monica.Martin@Sun.COM>]

In Tuesday's call, we discussed upcoming BPMI Think Tank that includes 
BPMN session. Below is the interchange between Stephen White and I 
regarding the addition of a collaboration activity to support our 
business requirements. [1]  If any team member has any comments or 
questions, please let me know. I'll bring any questions to the meeting 
Tuesday and Wednesday (17-18 May 2005). Thank you.

Regards and thanks to Layna for keeing our team informed.

[1] Public BPMN minutes found at: 
http://www.bpmn.org/Meeting%20Minutes/NWG-2005-04-01%20Conference%20Call%204-14-05.htm
Think Tank event: 
http://www.bpmi.org/events_pr.htm#BPM_Think_Tank_Task_Group_Meetings

> Monica,
> Thanks for the input, and see some responses inline.
>
> We have made some progress, but I admit we have been slow. Partly 
> because my time is being divided up between other projects and I can't 
> spend as much time as I would like.
>
> I think we don't have a problem with the shapes outside the Pools any 
> more, since BPMN already allows a "central"  Pool that doesn't require 
> a solid boundary. Having a Pools that are placed in between shapes of 
> the central Pool is a bit of stretch maybe, but I think it is 
> allowable. We just have to look at the properties of a Pool and make 
> sure we are covering this situation properly. Thus, all the issues 
> around shapes outside the Pools just go away.
>
> The key issue, then, is the inclusion of a new type of activity--the 
> collaboration or joint activity. Some of the discussion below relates 
> to this. The new type of activity is probably required because of the 
> way Message Flow connects to these types of activities. Message Flow 
> (MF) must act in pairs where there is one incoming MF matched with an 
> outgoing MF, each carrying the exact same Message. This type of 
> behavior does not apply to activities within an internal, managed 
> process.
>
> There is also ongoing work within the OMG for BPDM, which is looking 
> closely at choreographies and orchestrations. This work should also 
> influence where BPMN will go with this.
>
> *Monica J Martin <Monica.Martin@Sun.COM>*
>
> 05/09/2005 01:42 PM
>
> 	
> To
> 	rob.bartel@igrafx.com, Stephen A White/Irvine/IBM@IBMUS
> cc
> 	Jean-Jacques Dubray <jeanjadu@Attachmate.com>, Dale Moberg 
> <dmoberg@cyclonecommerce.com>
> Subject
> 	Bartel/White 5.9.2005: BPMN Next Version and Next Steps
>
>
>
> 	
>
>
>
>
>
> Rob and Stephen,
> In preparation for the meetings next week (as a followup to the Think
> Tank), I'd like to get an update on BPMN progress.  I've extracted the
> public meeting snippet from April 2005 and added a few comments. Perhaps
> you can give me some additional detail so I can think about before next
> week's meeting. Dale may also be attending. Thanks.
>
> ==========
> We did discuss the topics regarding the addition of
> collaboration/choreography modeling within BPMN. When looking at an
> example, such as this
> <http://www.bpmn.org/Samples/ebXML_Business_Process/ebXML%20Example2.jpg>, 
>
> it becomes clear (to us) that the current BPMN specification does not
> provide the capabilities to create the example. Conceptually, the
> diagram is creating a conceptual one rather than an actual process--that
> is, the actual activities are being performed within the confines of the
> seperate participants.
>
> [mm1] Actually there is an actual shared business collaboration process
> that includes shared expectations. They have a collaborative view of
> activities, the state, etc.
>
> We discussed that the diagram is defining a series of states that the
> participants expect to occur. The states are conceptual in that they can
> never really be tested or verified. There are actually separate states
> being held individually by the participants.
>
> [mm1] There is a shared state that is understood and states (potentially
> many state machines) held individually by the parties.
>
> <saw>Yes the process is shared and each participant would have its own 
> view of the state of the process, or an activity within the process, 
> but it is possible that the participants may have different views of 
> the states. The general idea is that there is no specific (or 
> centralized) holder of the state of the process.
>
> Both choreographies and orchestrations are business processes, but we 
> were trying to illustrate that they have different characteristics 
> (which need to be dealt with graphically and/or semantically).</saw>
>
>
> One change would be to add a new type of activity, a "collaboration
> activity." This activity would exist in between the Pools (and not
> within the Pools). Because the activity is between the Pools, other
> elements will also have been exist within the Pools also, e.g.,
> Gateways, Sequence Flow, etc. We discussed whether these other elements
> are actually the same as their internal process counterparts, and
> whether they should be named or shown differently (e.g., with a
> different line style). If they are different, then this creates a whole
> new set of shapes to describe. If they are the same, then it becomes
> more complicated to describe how they behave. We haven't resolved this 
> yet.
>
> [mm1] Requires more discussion. I'd interject that not all visualization
> or design of processes realizes itself in an executable process.
>
> <saw>As mentioned above, most of this goes away except the new type of 
> activity.</saw>
>
> Relatedly, we discussed whether or not any changes should be defined in
> a new diagram or as part of the current BPD. We seem to be leaning
> towards extending the current diagram, since looking at the example
> <http://www.bpmn.org/Samples/ebXML_Business_Process/ebXML%20Example2.jpg>, 
>
> it seems very likely that one of the participants may want to see their
> internal or abstract process within their Pool, making it all in one
> diagram.
>
> The usage of BPMN, with the proper documentation, for the purposes of
> choreography or internal processes, should be clear (at least we think 
> so).
>
> [mm1] This is inline with our discussion thus far.