Brown Jermaine

You almost have no other option but to use BPMN nowadays. The DFD techniques, although very popular once, has fallen by the way side to the more prevelant and soon to be ubiquitous BPMN/Bpel techniques. This is not to say that DFDs are bad; its just that it has had its day, as did Pascal, RPG, Cobol, PL/I, Spagetti Code, Assembler and others. Its just that "BPMN/BPEL/XML" as a business process recording and execution techniques are becoming the "lingua franca" of the business process domain.

Someone has recently asked what is the relationship between Business Process Analysts and Java? BPMN/BPEL/XML can be implemented in a J2EE (Java) architecture, hence the acceptability of BPMN/BPEL(XML) and Java. Now everything is not sunshine and roses as yet, as there is still the problem of round-trip-engineering (BPMN--> BPEL(XML) ---> BPMN); but BPMN is getting traction!

Of course you can use BPMN for large projects. A technique that I've seen that worked was the use of UML packages to partition a large project (a Borrowed technique from DFDs). These partitions are then de-composed into process diagrams etc. The combination of UML package and BPMN does have smacks of the old model T Ford design, which combined the old horse-buggie (cart) with an engine.

My point; to manage large projects you have to borrow from the old tried and tested methods such as DFDs (the old Model T Ford)

warm regards,

K

Yes it was published around the 23rd - you find it if you click here. Let me know what you think of it...

Guy

Hi:

I say that the vast majority of the the Business Analyst community is lost.  Lets break  business process analysis down into baby steps.  

1.)  Analysis is largely about discovery.  So in process analysis, we are mainly charged with discovering what the processes are.

2.)  A process is defined (some small exceptions) by its inputs and outputs.  And in IT systems (and in many manual systems), these inputs and outputs are mainly data inputs and outputs.

3.)  Therefore, for rigorous business process analysis, we need to choose a modeling technique whose PRIMARY focus is on the data flows - not on sequence, not on flow of control, not on timing, not on anything other than data flows.

4.)  BPMN is not focused first and foremost upon data flows.   Yes you can incorporate data flows within a BPMN model, but discovery of data flows is NOT given topmost priority.  As a result, data flow analysis is going to be very  incomplete.

5.)  And therefore, especially for larger scale efforts, with BPMN, process discovery is going to b every incomplete.

What is seldom realized is that one of the primary reasons data flow diagrams where  invented  was to replace techniques that focus on flow of control and sequence.  These techniques were largely the same as BPMN.   Yes, BPMN has some extra notations like timing - but the core of BPMN (i.e., flow of control and flow of sequence) is the same as techniques alot older than data flow diagrams.

Flow of control/flow of sequence diagrams have been discovered on the walls of caves inhabited by prehistoric man.  Data flow diagrams go back to the mid 60's; however, the essentials of BPMN go back to the dawn of man.  They may even predate discovery of the wheel!  :-)

Tony