How to represent expanded subprocess with pools and swimlanes?

[Gil Lee]

Hello all:

 

I hope this finds you well.

I ran into a BPMN question and wonder if any of you have experience with this and might be so kind as to provide your thoughts on the matter.

 

My question is as follows:

Our BPMN is developed at a high level. However, sometimes, we run into situations that call for representing lower levels of detail.

 

To show those lower levels, we use the inline hierarchical expansion to represent a drill down of the process/activity without violating the integrity of the model or having to draw another diagram. In the Bruce Silver documentation "BPMN Methods and Style", he shows inline expansions to do just such a job. However, there is little guidance to show inline expansion of processes where there are more than one swimlanes or the presence of a pool.

 

How would this expanded subprocess be represented with a pool/multiple swimlane setup?

[tom gallagher]

Hi Gil,

Can't you find a tutorial on this bpmn software (http://tinycc.me/B29WE6) resource?

[Massimo Coletti]

Gill, hi. A sub process is not intended to enclose more than one lane. It is called within a Lane, and it would be confusing to find different lanes inside it.

If the called element that you are modeling has a complex structure, and several Performers, that may differ from the set of Performers in the calling process, I can suggest to use a Call Activity. This element will allow you to model the invocation of a different process, referenced by the Call Activity.

Be aware that the called process should be executed by the same Participant that owns the calling process. If this is not true, you should rather use a Collaboration or Choreography.

Ciao

[Joshua F]

I agree with Massimo, a Call Activity object calling a Global Task or Call Activity object calling a Process will allow you to invocate another task or process.  BPMN v2.0.2 p. 182-187.  

Using this concept has enabled our organization to map out low level decompositions of processes and through reconstructing to the top-level process diagram show how they are all connected.

Josh

[Neal McWhorter]

Gil,

I'm afraid we're tripping over the communication model vs execution model problem again. Because every BPMN process (read... top-level process) has either an explicit or an implicit pool you cannot have pools within subprocesses because those would be nested execution contexts. You could use lanes since they have no defined semantics. However, I'd also suggest you consider that your top-level processes might not really be processes at all.

Let's start with the assumption that when we say "process" we mean 

"an ordered to set of steps and paths which define and constrain how work is performed" 

This is a summary I typically use which fits well with what BPMN means and fits well with what most people think they mean when they say processes. However, top-level processes typically violate this definition. They don't truly constrain the work because they typically aren't really "correct". That's not a mistake that's a decision to not focus on the details. However, that means that a direct decomposition into lower levels will always run into problems because the top level must always be a proper composition of the lower levels or something is wrong somewhere.  I've run into this problem at organizations I've worked with for many years. 

This problem is one of the reasons that there has been a strong movement towards using value streams to do this kind of abstract analysis. Value streams communicate an intent to work at an abstract level and are tied to a series of related abstractions that support work at that level (e.g. value items, capabilities, strategies, etc.) as defined by the Business Architecture Guild's BIZBOK (fair disclosure... I'm a founding board member) which has formalized the elements of Business Architecture that these are defined within. I actually co-wrote a whitepaper about this whole topic a year or two ago and I think there might still be a link from my link-in public profile. It's called "Business Architecture and BPM - Differentiation and Reconciliation". It's not the easiest read but if you're interested it's a detailed review of this issue. 

 

	Experience + Leadership
Neal McWhorter | Connect with me on Linkedin Business Architecture Guild Board Member neal.mc...@strategicvaluepartners.com www.strategicvaluepartners.com	Strategic Value Partners, Inc. Chicago, Illinois Tel: 773-570-0020

--
--
You received this message because you are subscribed to the Google
Groups "BPMN Forum" group.
Public website: http://www.bpmnforum.com
To post to this group, send email to BPMN...@googlegroups.com
To unsubscribe from this group, send email to
BPMNforum+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/BPMNforum?hl=en_US?hl=en

---
You received this message because you are subscribed to the Google Groups "BPMN Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to BPMNforum+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brian P]

Hi Gil, 

Chapter 5 in the Bruce Silver's book deals with child level subprocesses and he states that you can use lanes within a child level. 

A pool would be an entirely different thing from what I can gather as a pool is something which contains and follows each instance within a process as it goes from start to end and traverses the activities. It sounds like you don't want to create a new instance of a different process so I wouldn't image you could use a pool here. 

From what I can gather, two pools are usually used to colloborate (independent processes talking to one another or different entities sending messages to one another where typically one entity/pool remains a black box as you don't really know the mechanics of their process. 

I'd be interested in your thoughts as to why you think that a collapsed subprocess would violate the integrity of your diagram any more than an inline would ? It's my understanding that an expanded or collapsed subprocess mean the same thing. However, I welcome any advice correcting this assumption ?  

You also state "without having to draw another diagram" . Don't you have to draw one anyway even if it is an expanded/inline subprocess ?  It's not difficult at all to create a subprocesses "on the fly" in Visio. Perhaps, following the method and style rules of Bruce Silver would then ensure the integrity of your document?

Expanded sub process for me just add clutter - but that's a personal preference. 

Hope this helps and look forward to some other interesting comments on this and also your feedback. 

Best Regards

Brian

[Brian P]

Hi Neal, 

I wonder if it should be "an ordered to set of steps and paths which define and constrain what work is performed"  instead of how . For example , I know in step A of my process that somebody has to review something. I don't really care how they review it as long as they review it. Then in step 2 it must be sent to somebody for approval. I don't really mind how they send ( post, mail, phone call) as long as they send it...

thoughts ?

cheers

Brian

On Tuesday, February 16, 2016 at 1:52:14 AM UTC+11, neal wrote:

Gil,

I'm afraid we're tripping over the communication model vs execution model problem again. Because every BPMN process (read... top-level process) has either an explicit or an implicit pool you cannot have pools within subprocesses because those would be nested execution contexts. You could use lanes since they have no defined semantics. However, I'd also suggest you consider that your top-level processes might not really be processes at all.

Let's start with the assumption that when we say "process" we mean 

"an ordered to set of steps and paths which define and constrain how work is performed" 

This is a summary I typically use which fits well with what BPMN means and fits well with what most people think they mean when they say processes. However, top-level processes typically violate this definition. They don't truly constrain the work because they typically aren't really "correct". That's not a mistake that's a decision to not focus on the details. However, that means that a direct decomposition into lower levels will always run into problems because the top level must always be a proper composition of the lower levels or something is wrong somewhere.  I've run into this problem at organizations I've worked with for many years. 

This problem is one of the reasons that there has been a strong movement towards using value streams to do this kind of abstract analysis. Value streams communicate an intent to work at an abstract level and are tied to a series of related abstractions that support work at that level (e.g. value items, capabilities, strategies, etc.) as defined by the Business Architecture Guild's BIZBOK (fair disclosure... I'm a founding board member) which has formalized the elements of Business Architecture that these are defined within. I actually co-wrote a whitepaper about this whole topic a year or two ago and I think there might still be a link from my link-in public profile. It's called "Business Architecture and BPM - Differentiation and Reconciliation". It's not the easiest read but if you're interested it's a detailed review of this issue. 

 

	Experience + Leadership

Neal McWhorter | Connect with me on Linkedin Business Architecture Guild Board Member

neal.mcwhorter@strategicvaluepartners.com www.strategicvaluepartners.com

[Neal McWhorter]

Brian,

I think we're probably tripping over the meaning of terms. When I use "how" vs "what" I'm speaking in the sense that the "what"s are a list of all the possible tasks that can be performed. The "how"s are constraining when these are performed. In the case you mention you have a process that is not fully decomposed (which is fine and often the most meaningful level to take things to) so you have what amounts to an implicit detailed subprocess that would further decompose your review activity into discrete activities. This might be an ad-hoc activity which would indicate that there is no constraint and then any one of the ways of reviewing is acceptable. So the "how" in that case wouldn't be interesting (thus the use of an ad-hoc) but the "what"s are still just a listing of potential pieces of work that exist w/o regard to any process context. It might be easier to think of "what"s as a decomposition of task and "how"s as putting these together to get things done.

	Experience + Leadership

Neal McWhorter | Connect with me on Linkedin Business Architecture Guild Board Member

neal.mc...@strategicvaluepartners.com www.strategicvaluepartners.com

Strategic Value Partners, Inc. Chicago, Illinois Tel: 773-570-0020

On Wed, Feb 17, 2016 at 3:11 AM, Brian P <brianp...@gmail.com> wrote:

Hi Neal, 

I wonder if it should be "an ordered to set of steps and paths which define and constrain what work is performed"  instead of how . For example , I know in step A of my process that somebody has to review something. I don't really care how they review it as long as they review it. Then in step 2 it must be sent to somebody for approval. I don't really mind how they send ( post, mail, phone call) as long as they send it...

thoughts ?

cheers

Brian

On Tuesday, February 16, 2016 at 1:52:14 AM UTC+11, neal wrote:

Gil,

I'm afraid we're tripping over the communication model vs execution model problem again. Because every BPMN process (read... top-level process) has either an explicit or an implicit pool you cannot have pools within subprocesses because those would be nested execution contexts. You could use lanes since they have no defined semantics. However, I'd also suggest you consider that your top-level processes might not really be processes at all.

Let's start with the assumption that when we say "process" we mean 

"an ordered to set of steps and paths which define and constrain how work is performed" 

This is a summary I typically use which fits well with what BPMN means and fits well with what most people think they mean when they say processes. However, top-level processes typically violate this definition. They don't truly constrain the work because they typically aren't really "correct". That's not a mistake that's a decision to not focus on the details. However, that means that a direct decomposition into lower levels will always run into problems because the top level must always be a proper composition of the lower levels or something is wrong somewhere.  I've run into this problem at organizations I've worked with for many years. 

This problem is one of the reasons that there has been a strong movement towards using value streams to do this kind of abstract analysis. Value streams communicate an intent to work at an abstract level and are tied to a series of related abstractions that support work at that level (e.g. value items, capabilities, strategies, etc.) as defined by the Business Architecture Guild's BIZBOK (fair disclosure... I'm a founding board member) which has formalized the elements of Business Architecture that these are defined within. I actually co-wrote a whitepaper about this whole topic a year or two ago and I think there might still be a link from my link-in public profile. It's called "Business Architecture and BPM - Differentiation and Reconciliation". It's not the easiest read but if you're interested it's a detailed review of this issue. 

 

	Experience + Leadership

Neal McWhorter | Connect with me on Linkedin Business Architecture Guild Board Member

neal.mc...@strategicvaluepartners.com www.strategicvaluepartners.com

[Brian P]

thanks for the clarification Neal, 

cheers

Brian

On Thursday, February 18, 2016 at 8:46:57 AM UTC+11, neal wrote:

Brian,

I think we're probably tripping over the meaning of terms. When I use "how" vs "what" I'm speaking in the sense that the "what"s are a list of all the possible tasks that can be performed. The "how"s are constraining when these are performed. In the case you mention you have a process that is not fully decomposed (which is fine and often the most meaningful level to take things to) so you have what amounts to an implicit detailed subprocess that would further decompose your review activity into discrete activities. This might be an ad-hoc activity which would indicate that there is no constraint and then any one of the ways of reviewing is acceptable. So the "how" in that case wouldn't be interesting (thus the use of an ad-hoc) but the "what"s are still just a listing of potential pieces of work that exist w/o regard to any process context. It might be easier to think of "what"s as a decomposition of task and "how"s as putting these together to get things done.

	Experience + Leadership

Neal McWhorter | Connect with me on Linkedin Business Architecture Guild Board Member

neal.mcwhorter@strategicvaluepartners.com www.strategicvaluepartners.com

Strategic Value Partners, Inc. Chicago, Illinois Tel: 773-570-0020

On Wed, Feb 17, 2016 at 3:11 AM, Brian P <brianp...@gmail.com> wrote:

Hi Neal, 

I wonder if it should be "an ordered to set of steps and paths which define and constrain what work is performed"  instead of how . For example , I know in step A of my process that somebody has to review something. I don't really care how they review it as long as they review it. Then in step 2 it must be sent to somebody for approval. I don't really mind how they send ( post, mail, phone call) as long as they send it...

thoughts ?

cheers

Brian

On Tuesday, February 16, 2016 at 1:52:14 AM UTC+11, neal wrote:

Gil,

I'm afraid we're tripping over the communication model vs execution model problem again. Because every BPMN process (read... top-level process) has either an explicit or an implicit pool you cannot have pools within subprocesses because those would be nested execution contexts. You could use lanes since they have no defined semantics. However, I'd also suggest you consider that your top-level processes might not really be processes at all.

Let's start with the assumption that when we say "process" we mean 

"an ordered to set of steps and paths which define and constrain how work is performed" 

This is a summary I typically use which fits well with what BPMN means and fits well with what most people think they mean when they say processes. However, top-level processes typically violate this definition. They don't truly constrain the work because they typically aren't really "correct". That's not a mistake that's a decision to not focus on the details. However, that means that a direct decomposition into lower levels will always run into problems because the top level must always be a proper composition of the lower levels or something is wrong somewhere.  I've run into this problem at organizations I've worked with for many years. 

This problem is one of the reasons that there has been a strong movement towards using value streams to do this kind of abstract analysis. Value streams communicate an intent to work at an abstract level and are tied to a series of related abstractions that support work at that level (e.g. value items, capabilities, strategies, etc.) as defined by the Business Architecture Guild's BIZBOK (fair disclosure... I'm a founding board member) which has formalized the elements of Business Architecture that these are defined within. I actually co-wrote a whitepaper about this whole topic a year or two ago and I think there might still be a link from my link-in public profile. It's called "Business Architecture and BPM - Differentiation and Reconciliation". It's not the easiest read but if you're interested it's a detailed review of this issue. 

 

	Experience + Leadership

Neal McWhorter | Connect with me on Linkedin Business Architecture Guild Board Member

neal.mcwhorter@strategicvaluepartners.com www.strategicvaluepartners.com