Here are the responses I gave on Jordi Cabot blog (www.modeling-languages.com) on the issue of business process modeling and of the new CFP for a UML profile for BPMN.
Mixed feelings – but clear understanding Submitted on Thu, 09/16/2010.
I have mixed feelings about this issue: first, about the objective of the move; second, about the advantages it will bring; and third, about the relevance of the discussion.
1) Objective:
If the target is to flatten all the modeling to just one notation and role(the software engineer), then this is definitely a wrong direction.
BPMN and UML have two different focuses (business and software) and are used by different roles (analysts and softengs). We should not forget this… even more: bpmn itself is now perceived as not fully understandable by its target users.
2) Advantages:
Supposing we keep in mind the two focuses, the advantages
of the proposal above could be to allow the orthogonal design of different aspects of the applications by different roles, also granting integrated design of the different orthogonal aspects in a unified design vision (old story on separation of concerns).
3) Relevance:
Well, to be honest I don’t see the discussion as so relevant. In the bpm field the notation issues are more and more seen as marginal aspects (someone is already wondering what will be the fate of BPMN 2.0). I don’t see why we shouldn’t start doing the same in the softeng community.
In term of acceptance and utility of modeling notations, you can see the some lessons learned from our on the field activities here:
http://www.slideshare.net/mbrambil/web-ratio-bpmindustrialcasesbpm2010
1) Objective:
If the target is to flatten all the modeling to just one notation and role(the software engineer), then this is definitely a wrong direction.
BPMN and UML have two different focuses (business and software) and are used by different roles (analysts and softengs). We should not forget this… even more: bpmn itself is now perceived as not fully understandable by its target users.
2) Advantages:
Supposing we keep in mind the two focuses, the advantages
of the proposal above could be to allow the orthogonal design of different aspects of the applications by different roles, also granting integrated design of the different orthogonal aspects in a unified design vision (old story on separation of concerns).
3) Relevance:
Well, to be honest I don’t see the discussion as so relevant. In the bpm field the notation issues are more and more seen as marginal aspects (someone is already wondering what will be the fate of BPMN 2.0). I don’t see why we shouldn’t start doing the same in the softeng community.
In term of acceptance and utility of modeling notations, you can see the some lessons learned from our on the field activities here:
http://www.slideshare.net/mbrambil/web-ratio-bpmindustrialcasesbpm2010
Rules for BPM(N) modeling Submitted on Mon, 11/08/2010
For methodological guidelines see also the online decalogue by Bruce Silver Associates:
http://www.brsilver.com/2010/09/28/the-rules-of-bpmn/
And also this paper by Michael Zur Muehlen on empirical analysis on the usage of BPM modeling languages (basically more or less a Pareto Rule for moveling languages concepts: less than 20% of the notation and patterns covers more than 80% of cases, or even more):
http://www.springerlink.com/content/670848258183m652/
This is in line with our experience too.
http://www.brsilver.com/2010/09/28/the-rules-of-bpmn/
And also this paper by Michael Zur Muehlen on empirical analysis on the usage of BPM modeling languages (basically more or less a Pareto Rule for moveling languages concepts: less than 20% of the notation and patterns covers more than 80% of cases, or even more):
http://www.springerlink.com/content/670848258183m652/
This is in line with our experience too.
