I had a blast from the past at Enterprise Data World a few weeks back. Casey Gwozdz of CA Technologies held up an IBM flowcharting template and said it was his first data modeling tool. That is true for many of us mature data architects. If you are unfamiliar with this template, take a look at the image in this blog post and this IBM Data Processing Techniques: Flowcharting Techniques instruction sheet.
As a junior programmer fresh out of college, I had the job of maintaining program flows, job processing flows, and system process and data flows. Computer Aided Software Engineering (CASE) tools were yet to make an appearance. These flowchart diagrams were the means by which IT graphically depicted and discussed applications with many audiences.
This template reminds me how flowcharts have remained part of our world through the years. The technology has evolved from pencil and paper to web-based applications, but the benefits achieved from this simple tool are notable. Here is some good justification why data architects should keep flowcharting in their toolkits.
Breaking down barriers
Data architects create data models to visualize the complexity of data in a graphical manner. Flowcharts similarly simplify objects and their relationships by organizing and connecting them in a flow. Technical jargon is translated into simple objects that are commonly understood. Complex processes and relationships are easier portrayed when graphically presented. People are more apt to work together when uncovering a business process jointly in a flowchart. All of the above benefits the data architect in understanding and modeling data.
Telling the story
The effectiveness of data architects is related directly to their skill in storytelling. Data models tell the story of data. A skilled data architect must know how to successfully convey a story through an ERD. Flowcharts are very versatile storytellers. Just like relationship lines, flows in a flowchart show how objects are shared, moved and transformed. Flows and decision points draw people into verifying and exploring the subject at hand. There is simplicity of how flowcharts can be decomposed into deeper detail with child flowcharts.
There is something refreshing about the simplicity of a flowchart. When you find yourself in a pinch, it’s easy to draw a flowchart on a whiteboard to get consensus and solve a problem. Data architects should not solely rely on the data model to tell the story of data. Keep flowchart techniques in your back pocket when you need to take an alternate path to solving a problem. Flowcharts make good bridges between the technical and non-technical worlds. Each of us uses flowcharts differently in our own worlds. That translates well for the work we must do together. When we commit a flowchart to a whiteboard, paper or Visio diagram, the process of building the flowchart makes us think deeper and visualize alternatives.
A flowchart is not a data model. A flowchart will never be a data architect’s main tool of choice. It does offer us the chance to look at data and processes differently. It brings us closer to our customers in a platform that is common to all of us. Next time you find yourself unable to convey a message or appear to be mired in indecision, the ideal solution may be as simple as getting to work on a whiteboard with a dry erase pen. Sometimes the simplest tool can give us a big bang for the buck.