Question for all:

The BPMN covers ad hoc SUB-processes (by use of the tilde). But what about top-level processes? Especially for larger scale systems, processes at the top-most “big picture” level can happen in any order and/or all at the same time. How does BPMN handle such?

It would seem that just using the tilde convention at the “big-picture” level would not be nearly adequate: Some work must be done to show how the top-level processes interrelate.

Note:  Agile development, from what I have been told, requires an up-front "big picture" for things like: prioritizing what is to be built per iteration and system scoping

Tony Markos
 

Guy:

Thank you for your informative response.  Especially informative was the linked-to document that talked about top-level processes and decomposition.  Problem:  Even  at the top-most level,  BPMN shows processes arranged by sequence.  Especially at the high-level, systems (manual or automated) are characterized as having processes that can occur in any sequence, and therefore they can not be adequately documented by sequential techniques.

Now Use Case diagrams are not sequential, but, because of  how the BA proceeds in partitioning the system using Use Cases, a major decomposition problem occurs.  The warning at the end of section 9.12 of the BABOK 2.0 hints at the issue that improper partitioning causes in saying: "Decomposing a problem without fully understanding the relationships between the pieces of the problem may create an inappropriate structure that impedes analysis."  The most important of these "relationships" are the data inputs and outputs, which of course graphical Use Cases do not consider.

Tony Markos

Hi Guy:

You state:   Level 0 DFD shows the dependency between top level processes in terms of data: they answer the question "which top level processes need data from which other top level processes?"

I reply:  Minor point, but level 0 is the Context Diagram showing the whole system as a single process.   I assume this is what you mean, right?

You state:  BPMN can answer these questions as well. Top level processes can be modelled showing just the data dependency links between them. It is up to the modeller to select from the BPMN 'pallet' the notation for top level processes and information (aka data) flows.

I reply:  Ohhh, what I now understand you as saying is that BPMN can be used to create data flow diagrams.  If this was what you were saying before than I did not get it.   Sorry.  If that is true than great, such can capture the bigger picture of more complex systems.   Is creating data flow diagrams with BPMN commonly done?   

You state:  Top level processes are triggered by either an event (which is an instance of an external interacting with the solution scope expressed in terms of top level processes) or by another top level process.......

My reply:  Yes, but, but of course, how processes are triggered are not shown on data flow diagrams.

You state:   So here is the thing: BPMN is a notation for modelling business processes, not a methodolgy. It is - to a large extent - method agnostic.  It is up to the modeller to select what they want to model.

My reply:  I have only read about BPMN.  I have not used it on a project.  I have used other BPM techniques.   Having said that, I have found nothing in writing that talks about using BPMN to create the big picture.  It seems to me that if BPMN was meant to be used to create data flow diagrams, such would have been clearly highlighted in, for example, the introductory documentation readily found on-line by Scott White and others.   After all, without the ability to adequately capture the "big picture", the ability to capture the smaller picture is of limited value.  Guy:  Can you tell me where using BPMN to create data flow diagrams is discussed on-line?

You state:  And finally...as I am sure you will agree the guts of a process model (any notation you like) is the process execution logic written for each process step at the atomic level if at no other.

I reply:  I agree with you hear.   Of course the analyst needs to properly partition down the system in order to arrive at right-sized, loosely coupled, highly cohesive chunks of the system in order to then write execution logic that does not require a the reader to do a prohibative amount of skipping over text and jump around from one section of text to another in order to understand how something is to work.

You state:   In my current assignment we are only drawing level 1 process models which are functionally equivalent to cases appearing on use case diagrams and they are being documented using scenario descriptions.

My reply:  Not sure if I follow you here Guy. But if your level 1 does not show the data flows, then I say tlhat essential high-level interrelationships are missing, and this, especially if the system is complex, will ultimately significantly effective partitioning of the system at lower levels (among other issues).

You state:  do what you need to do in order to do the analysis and if that means getting the Large Hadron Collider to work on UML and BPMN particles then so be it.

My Reply:   Do you mean a large hairy collie?

Tony Markos