The purpose of any model is to focus people’s attention on specific dimensions of the depicted situation that the model makes visible. This visibility is critical because when people can see what they are discussing, it helps keep their discussion on topic. Just pointing to a specific element in the model draws everyone’s attention to that element and encourages them to discuss that element as opposed to others.
Online Course: Data Flow Diagrams — Simply Put!
Learn how to implement process modeling techniques for Requirements Elicitation and Workflow Analysis
Of course, there are two major disadvantages to using any type of model:
- Any model highlights specific components and ignores other, potentially equally important, aspects of the situation. That means selecting the type of diagram that will help you achieve your goal becomes a critical decision. The wider your repertoire of diagramming techniques, the more difficult the choice becomes but it also increases the odds that the one you choose will actually deliver what you expect of it.
- The people viewing the model have to agree on what the symbols on the model mean. That requires at least some training and/or at least a brief overview of the technique to level the field for all users. In the context of modeling business processes, the challenge becomes making sure that the business and IT communities both share that common understanding. Because of the diverse backgrounds of those two audiences, that can be a significant challenge.
There are currently two major modeling techniques in widespread use for depicting business processes and to some extent workflow: Activity diagrams (often called “Swimlane Diagrams”) and Dataflow Diagrams (DFDs). Disclaimer: There is also a relative newcomer in the form of Business Process Modeling Notation (BPMN). In our experience, the shear volume of available symbols and the resultant complexity of this phenomenally versatile diagram tend to limit its use to those few who are willing to invest sufficient time to overcome the learning curve. As a result, we limit our comparison to the more commonly used Activity Diagrams and DFDs.
So what is the difference? Fundamentally, a DFD shows the transformation (processes), transportation (data flows), and storage (data stores) of data through the business process. There is a perception of sequence but it is important to note that the sequence of the processes on a DFD are entirely data-dependent. In this example, the process “Validate Item #’s and Descriptions” follows the process “Determine Credit Status”, implying a sequence. An analysis of the data flows, however, reveals that the “Validate …” process does not need any data created by the “Determine …” process. In DFD-speak, that means there is no data dependency between the two processes, meaning there is no necessity for the sequence. In optimizing the process, you could consider removing the flow between them to allow for simultaneous execution of both. This information is not as obvious on the Activity Diagram.
On the other hand, the DFD does not allow for conditional flows and execution. That is a major strength of the Activity Diagram. By adding the guard conditions “Prepaid” and “No Payment Attached”, the logic of the flow becomes much more obvious. In addition, Activity Diagrams are closely related to old-fashioned System Flow Charts and as a result are much more widely understood in the non-IT universe.
You need a good understanding of whichever type of diagram you select, what it says, what it hides, what the individual symbols really mean to make the most efficient use of visualization. In addition, you should be capable of presenting the differences to your audience to ensure that everyone viewing the end result is really on the same page.
Upon completion of this course, you can:
- Document existing business processes and workflows in Data Flow Diagrams (DFD) to initiate business process analysis
- Defend the need for Data Flow Diagrams, Context Diagrams, and Rigorous Physical Process Models
- Explode a high level Data Flow Diagram to its lower level details to reveal underlying processes and procedures
- Balance DFD’s to identify missing processes
- Use Horizontal Balancing to discover missing data and minimize redundancies
- Document process specifications for functional primitives to guide the solution providers
- Express metadata to reveal informational details that developers need to build the solution
