Recently I was asked to provide a brief comparison between Data Flow Diagrams (DFDs) and BPMN and I thought it could be also useful for other people who are wondering which one to use.
As you probably noticed from other posts I work with BPMN a lot and had a chance to see many areas where it can be helpful, while I rarely see DFDs being currently used (of course except education).
Both BPMN and DFD are mature notations. DFD notation was created in the 1970s and popularized by few legends of software engineering including Edward Yourdon and Tom DeMarco. BPMN 1.0 was published in 2004, while current version 2.0 has slightly over 10 years (counting from beta release). While BPMN is still being extended and improved (e.g. by BPMN MIWG), I am not aware of any ongoing activities regarding DFD notation.
There are some differences regarding goals of those notations. BPMN charter (taken from BPMN.org) is as follows: “A standard Business Process Model and Notation (BPMN) will provide businesses with the capability of understanding their internal business procedures in a graphical notation and will give organizations the ability to communicate these procedures in a standard manner. Furthermore, the graphical notation will facilitate the understanding of the performance collaborations and business transactions between the organizations. This will ensure that businesses will understand themselves and participants in their business and will enable organizations to adjust to new internal and B2B business circumstances quickly.”
For DFD focus is different. As the name suggests data flows are of utmost importance. BABOK v3 states the purpose of DFD in a following way: “Data flow diagrams show where data comes from, which activities process the data, and if the output results are stored or utilized by another activity or external entity.” It’s interesting to compare it to Yourdon’s statements from “Just Enough Structured Analysis”: “This is important to keep in mind: DFDs cannot only be used to model information-processing systems, but also as a way of modeling whole organizations, that is, as a tool for business planning and strategic planning.”
Both notations have strong theoretical background meaning they are not just pretty pictures. DFDs are based on a graph theory. BPMN can also be analyzed using formal methods.
As for the symbols, situation is more interesting. BPMN is a standard, so you can easily see which icons should be used for which object types. However, for DFD notation there are several variations, so icons proposed by Yourdon and DeMarco differ from those proposed by Gane and Sarson. Needless to say – while you can easily interchange BPMN diagrams between various tools it is not the case for DFD since there is no standard interchange mechanism.
An additional difference relating to symbols is their availability. In DFDs you have 4 elements (Process, Flow, Store, and Terminator/External entity). In BPMN you have many more symbols. On the one hand, it means that DFDs may be easier to read (especially by people with no training). However, on the other hand, it also means that BPMN allows you to show more aspects in your diagrams (e.g. process flow versus data flow).
It might be more interesting to compare DFDs with DRDs in DMN. The information requirements of a DRD define a dataflow: from the input data elements, though intermediate decisions, to the top level decisions. As with DFDs, the arrows denote information flow, not sequence. The knowledge requirements in the DRD (showing how decisions depend on business knowledge models) cannot be seen in this way; they are more similar to functional dependencies.
Thanks for this explanation and discussion of the differences between DFD & BPMN. I have an intermediate BPMN-level of knowledge and am new to DFD, despite it being older. Decision Management Notation (DMN) is also new to me (and I see a relatively new notation developed by the Object Management Group (OMG) org). I see the benefits of them all. And definitely, DFD and DMN would be very of much use for me in the business of consulting and assisting organizations in various areas of compliance to norms, laws, and other projects needing to look at data flow and helping them better arrive at creating better processes for decision making within their organizations. Much appreciate this!