Data modeling has always been a task that seems positioned in the middle of a white-water rapids with a paddle but no canoe. On one side of the data modeling rapids are the raging agilists who are demanding working software and decrying virtually all documentation. To this agilists’ group, data modeling is often seen as too simple to matter. But at the same time, their implementations will miss standardization in naming or data model patterns. And results may be so far off course that major rework is unavoidable. Sadly, far too many agile practices have been set up to place things under the technical debt umbrella, when in reality those practices never allow the re-factoring closet door to be opened. Poor data models are “overcome” by creating ever more complex logic around the data in order to get to a more proper result, as developers learn what really needs to be accomplished along the way, maybe. The results may work but can be a nightmare to maintain.
On the other side of the data modeling rapids are more swirling global concerns and initiatives, such as GDPM, data literacy, and the like, all of which start exposing a need to understand the corporate data stew pot. A demand for the results of good data modeling arises, but largely from the perspective of a young child on a long vacation car ride as executives keep exhorting, “Are we there yet?” Resources not spent when solutions were built become a whole lot larger pool to be reverse engineered into place.
No one questions the need for blueprints when constructing a building, but when constructing software many people get itchy fingers and want to start coding as quickly as possible. In actuality, most of design diagramming, including data modeling, is generally viewed as wasted time because everybody knows what to do already, right? Often data modeling is blamed for being a bottleneck when the bottlenecking issue is not modeling the data but understanding the data. If the data is not understood, one can make the argument that it is not the right time to even begin to try modeling that data. As well, if data is not understood, the unknown state of the data alone increases chances that implementing any solution will be at risk right from the start.
Fleshing out designs, means entity-relationship diagrams, data flow diagrams, state-transition diagrams, or potentially even some kind of flow chart for very complex and important business rules; it means enhancing these visuals with a little bit of documentation such as a data dictionary, descriptions of expected processes (sentences, not necessarily pages), and details about important business rules to be enforced. Establishing these basics puts the design team in the driver’s seat. The end-state vision takes a form and can be shared. Users have something to apply thought to and point out if designs zig when they were expecting a zag. Corrections can be applied before any coding has been done. Designers can help lead the business regarding what kinds of functions are reasonable based on the nature of the data, versus passively waiting to be told and then trying to figure it out later.
When data is not understood, by designers, engineers, or users, then failure is lurking soon. Not understanding the data, translates into not understanding the business. How can one be successful in solving business needs and not understand the business as well as those needs? Creating basic design diagrams such as ERDs, DFDs, and those other artifacts mentioned above are the demonstration of understanding. These design artifacts provide the information to help the entire solution team understand, row in the same direction, and accomplish good results. And these artifacts can all be done quickly if the data is understood. Please help enable success.