This is another in an ongoing series about things we can do to improve our business efficiency, privacy, and security with little effort or cost.
When I first started using data flow diagrams as a tool a number of years ago, there is no way I could have known how valuable or well-received they would be by clients across sectors and industries.
Data flow diagrams can be created relatively quickly, requiring only some quantitive and qualitative inquiry into how a business operates in general and any specific and important functions, including the usability, efficiency, and security of a Web application or site, native apps, production workflows, information sharing practices, and any other activity that important to the business. The amount of time and resources required to create these diagrams far outweighed by the fresh understanding, insights, quick-wins, and overall advantages even the simplest diagrams offer business teams.
Data flow diagrams are friendly, visual illustrations of systems that collect, process, and store information. Edward Yourdon (RIP) and Larry Constantine are credited with inventing the concept and methodology in their book Structured Design: Fundamentals of a Discipline of Computer Program and System Design.
When their book was published in 1979, their structured design concepts, which included data flow diagrams, resonated with software engineers who used diagrams to help them better understand and refine existing systems as well as to conceive and design new ones. While it’s true not all the concepts in their book caught on, which is dated now being more than 40 years old, diagrams like these are still useful across disciplines to help us understand most any process in new and often overlooked ways. Until there’s a better way, building these diagrams remains a worthwhile activity.
I make these diagrams as interactive sessions, including stakeholders in the process to help clients improve their business in many contexts from achieving more efficiency, reimagining workflows, and especially for helping them eliminate their preventable risks to fraud, cybercrime, and other predictable events. They also learn more about how their business actually works than they ever imagined. Most of them say things like, “Wow, there’s so much here that I didn’t know.”
Data flow diagrams are one of the deliverables clients value most yet almost no one has ever heard of these before I present them with the opportunity to create one. While this post isn’t intended to be a comprehensive source on them, it’s a worthwhile spread on some of the basics.
Logical and Physical Diagrams
Data flow diagrams are drawn as one of two kinds: as logical drawings or as physical drawings. Typically, logical ones are the best starting point for a few reasons, the least of which isn’t that logical diagrams map out the “what” and physical diagrams outline more detail about the “how.” They’re two different perspectives on the same data flow, each designed to visualize and improve the system.
While a logical diagram of a process describes the business events that take place and the data required for each event, the physical diagram of the same process describes the specifics, such as hardware devices, software, people, and both off and online events required to support it.
Before any of us goes too far into thinking about the advantages of one over the other, I want to be sure to transmit that logical and physical diagrams need each other. A physical diagram cannot always be done well before its logical counterpart. The logical diagram establishes the foundation of events and requirements that can be easily overlooked if looking at the physical diagram first.
Logical drawings are usually much easier to understand, too, especially for diverse and less-technical audiences. Whenever we’re trying to transmit complex information like this, it’s essential that all the people who are stakeholders in the business and/or project are able to quickly understand and synthesize it. Logical diagrams are valuable tools for communicating and collaborating well about how a system works, no matter their level of complexity. Logical diagrams can help the collective quickly understand what a system is doing well and what needs improvement without getting mired in detail.
After establishing and helping to prioritize business requirements and objectives, logical diagrams work well for translating the needs of the business into technical requirements (and a physical diagram) for design and implementation. Together, the two diagrams help elevate everyone’s mental models of how the system works, which in turn minimizes the risk of overlooking important requirements that will ensure a successful project.
After a logical diagram is drawn, refined, and finalized it becomes the basis for a physical drawing. Physical diagrams are more exacting in their detail. In this sense, the physical diagram is the method of designing a new system. The physical diagram, based off a logical one, provides the basis of an implementation plan to provide the new software, hardware, people or other physical pieces required to run the business process in a more efficient or user-friendly way.
Together, logical and physical diagrams can illustrate well what we call “current state” or how the system works presently, while also helping to model the “future state” or how to achieve a new and improved system before it is actually conceived, designed, built, and implemented.
The differences between a logical and physical diagram of the same process can appear subtle but are significant and important. Below are two common examples used to show the difference between logical and physical diagrams for something we all do – buying something at a store:
Purchase at a Store: Logical Diagram
Purchase at a Store: Physical Diagram
Notice the differences? Notice how at-a-glance they appear quite similar? Notice how upon a closer look there are significant differences between them?
Essential Components
Regardless of whether they are drawn as logical or physical diagrams, Yourdon and Constantine defined four essential components of data flow diagrams:
External Entity – Also known as actors, sources, sinks, and terminators. External entities produce and consume data that flows between an entity and the system being diagrammed. These data flows are the inputs and outputs of the diagram. They are external to the system being diagrammed so are typically placed at the boundaries of the diagram. They can represent another system entirely or a subsystem or component of the primary system.
Process – An activity or event that changes or modifies a data flow. Since these transform incoming data to outgoing data, all processes must have inputs and outputs on a diagram. This symbol is given a simple name based on its function, such as “Compute Cost of Order,” rather than being labeled “process” on a diagram. In Gane-Sarson notation, a rectangular box is used and may be labeled with a reference number or a location where the process occurs and a short but descriptive title to describe its function. Processes are typically oriented from top to bottom and left to right on a data flow diagram but often depends on the system and its complexity.
Data Store – Data stores do not generate any operations or events. They hold data for access later on in the process. Data stores may include files stored indefinitely or a temporary store of data that exists only briefly before being processed. Inputs that flow to a data store may include information or events that change data being stored. Output flows are typically data being retrieved.
Data Flow – Movement of data between external entities, processes, and data stores is represented with a line and an arrow symbol to illustrate the direction data flows to and from these components. Data can be in any format, including electronic, written, or verbal. Input and output data flows are typically labeled near their respective lines according to the type of data and/or by an associated process, protocol, or data store.
Symbols for Essential Components
There are two commonly used systems of symbols to represent these, each named after their respective inventors: Yourdon and Coad and Gane and Sarson. They are similar but different.
How can diagrams be used?
Beyond uncovering a system’s inefficiencies, data flow diagrams can be used for other purposes, too, such as to uncover missing functionality by revealing steps that can be removed, consolidated, or improved in some way. Here are just a few contexts for their value to the business:
Software engineering: data flow diagrams originated in this discipline and continue to be used today. Logical diagrams capture activities and requirements for existing process and are useful for modeling new sets of activities, requirements, and functionality. Physical diagrams illustrate current software, hardware, databases and people to required to carry out the activities and can be used to model the design, build, and implementation of a new system. Both logical and physical diagrams are useful for helping diverse audiences reach an understanding the why and what of the technical aspects that are behind the many requirements.
Business analysis: Logical diagrams can be used to reveal business requirements at the beginning of a process that are often otherwise overlooked, leading to delays/cost overages at best and gaps in the processes of a system at worst. Logical diagrams are also incredibly useful communication tools for transmitting complex information to diverse audiences, especially less-technical people on the business side, regarding both the “current state” and new and improved “future state.” Physical diagrams can then be created to help map the technical pieces, costs, and design decisions to the business requirements.
Structured analysis: In classical, top-down structured analysis, a logical diagram is drawn of a current system to describe its current state, and then an improved system is modeled in a new logical diagram. The top-down physical diagrams are then drawn to show the targeted physical solution of software, devices and other system pieces. In event-driven, bottom-up structured analysis, a context diagram (Level 0) establishes the project’s scope, and subsequent levels break it down into subprocesses. Then we specify system events that require a response, and event diagrams are drawn to depict how each event is handled. These event diagrams can then be merged in a system diagram.
Office and administrative: Logical diagrams can be used to visually illustrate activities required for an office to function and can then be used to imagine and model better functionality with the office’s use and protection of data, such as personally identifiable information (PII) or confidential client and customer data, budgets, accounts payable/receivable, etc. A well considered logical diagram is also friendly enough to make sense to the entire team for figuring out how to achieve better efficiency, which can then be iterated as a physical diagram that show how to design and implement new hardware (devices), software, and people.
Health care: Physical diagrams can illustrate the current state of a patient information system containing electronic Protected Health Information (ePHI) that can be used for assessing overall risk, resilience, and HIPAA compliance, for example. Logical diagrams can reveal the data functions to help to the team establish a clear understanding of what the system does well and requirements for how it can be improved or even replaced. That in turn drives the justification for new logical and physical diagrams that outline the value and business care for hardware (devices), software, and other physical and digital components of a new or improved system.
Summary
As I’ve said, when I first started using data flow diagrams as a tool there was no way I could have known how valuable or well-received they would be by clients across sectors and industries. They can be created relatively quickly, requiring only some quantitive and qualitative inquiry into how a business operates. The amount of time and resources required are far outweighed by the fresh understanding, insights, quick-wins, and overall advantages even the simplest diagrams offer business teams. Hopefully this has been worthwhile reading for anyone who hasn’t had much experience with them and an inspiration to learn more.
Gratitude for shared knowledge and inspiration:
Thanks to the following sites and services for sharing knowledge, assets, and inspiring this post:
https://en.wikipedia.org/wiki/Data-flow_diagram#Physical_vs._logical_DFD
https://www.lucidchart.com/pages/data-flow-diagram/logical-vs-physical-data-flow-diagram
https://www.visual-paradigm.com/guide/data-flow-diagram/logical-vs-physical-data-flow-diagrams/