Comments on: Highlights from BPMN 2.0: Activity Types http://www.processmodeling.info/posts/highlights-from-bpmn-2-0-activity-types/ Insightful information on business process modeling from Rick Geneva Mon, 15 Aug 2011 13:07:11 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Rick Geneva http://www.processmodeling.info/posts/highlights-from-bpmn-2-0-activity-types/comment-page-1/#comment-82 Rick Geneva Thu, 26 Nov 2009 18:12:50 +0000 http://www.processmodeling.info/?p=281#comment-82 Alec, Thanks for your comments. Yes, the purpose of BPMN is to help bridge the gap between business and IT architecture/engineering. In order to eventually achieve this goal, we must communicate in way that is suitable to both crowds. At this point I'm only outlining the changes that are coming. After I write a bit about the spec I'll be posting some more about how to effectively use the shapes. Expect a new book in Q2 2010 from Tom D. and myself; an update to the Microguide to Process Modeling in BPMN (2.0). Shortly after this I'm going to release a more detailed book containing my library of process patterns and the PMF (process modeling framework). This was very difficult to write about in BPMN 1.2 because there weren't enough shapes and symbols to describe many of the concepts I was working with on a daily basis. BPMN 2.0 now clears the way for me to finish my writings. Thanks again for your comments. -Rick Geneva Alec,
Thanks for your comments. Yes, the purpose of BPMN is to help bridge the gap between business and IT architecture/engineering. In order to eventually achieve this goal, we must communicate in way that is suitable to both crowds. At this point I’m only outlining the changes that are coming. After I write a bit about the spec I’ll be posting some more about how to effectively use the shapes. Expect a new book in Q2 2010 from Tom D. and myself; an update to the Microguide to Process Modeling in BPMN (2.0). Shortly after this I’m going to release a more detailed book containing my library of process patterns and the PMF (process modeling framework). This was very difficult to write about in BPMN 1.2 because there weren’t enough shapes and symbols to describe many of the concepts I was working with on a daily basis. BPMN 2.0 now clears the way for me to finish my writings.

Thanks again for your comments.
-Rick Geneva

]]> By: Alec Sharp http://www.processmodeling.info/posts/highlights-from-bpmn-2-0-activity-types/comment-page-1/#comment-81 Alec Sharp Thu, 26 Nov 2009 01:55:12 +0000 http://www.processmodeling.info/?p=281#comment-81 Excellent post that clarified not just what the new activity types are, but also why they were needed (w.r.t. BPMN 1.2) - thanks for this! I'll add a note of caution on using the additional widgets that BPMN 2.0 now offers - when we say that they add "a lot of clarity to a diagram" we have to be sure to ask "who for?" My experience is that the people who are using the diagram as specifications to guide implementation (process engineers, app. developers, etc.) will appreciate the information provided by the additional symbols. On the other hand, the business people responsible for the process (owners, performers, SMEs, etc.) are likely to be irritated and confused by the additional symbols. For many, the additional symbols do not inform, they clutter, and therefor get in the way of understanding. A frequent result is a process model that is either inaccurate, or its implications aren't grasped, because the business folks couldn't or wouldn't validate it. I see this all the time, globally, in my consulting business, so I always encourage modelers to remember that what makes a model useful and informative for one audience won't necessarily do the same for another audience. Thanks again for an excellent post - I look forward to the rest of the series. Excellent post that clarified not just what the new activity types are, but also why they were needed (w.r.t. BPMN 1.2) – thanks for this!
I’ll add a note of caution on using the additional widgets that BPMN 2.0 now offers – when we say that they add “a lot of clarity to a diagram” we have to be sure to ask “who for?” My experience is that the people who are using the diagram as specifications to guide implementation (process engineers, app. developers, etc.) will appreciate the information provided by the additional symbols. On the other hand, the business people responsible for the process (owners, performers, SMEs, etc.) are likely to be irritated and confused by the additional symbols. For many, the additional symbols do not inform, they clutter, and therefor get in the way of understanding. A frequent result is a process model that is either inaccurate, or its implications aren’t grasped, because the business folks couldn’t or wouldn’t validate it. I see this all the time, globally, in my consulting business, so I always encourage modelers to remember that what makes a model useful and informative for one audience won’t necessarily do the same for another audience.
Thanks again for an excellent post – I look forward to the rest of the series.

]]>