Mythbusters fascinates me. Adam Savage and Jamie Hyneman build a lot of cannons. I’ve seen ice cannons, duct tape cannons, and many more. People love to see objects spewed out a firing cannon. Perhaps the best cannon episode had the duo firing a wheel of cheese out of a cannon to shred a ship’s sail. It was impressive and confirmed the myth by destroying the sail.
I don’t claim to be a myth buster of that caliber and fame. I observe myths about data modeling that are screaming to be busted. I am sharing my three Mythbuster episode quality myths with you. Read them here. You won’t see these in the upcoming season.
Myth #1: It takes too much time.
I do not standalone in acknowledging that this is the #1 myth data architects hear. It has roots in structured analysis and design methods of the 80s that were used on projects spanning many years. For those not old enough to work in the prehistoric IT age, these projects were typically late on delivery, experienced cost overruns, and failed to deliver functionality as promised. Data modeling was branded as just another one of the culprits that contributed to these failures.
The same myth gets perpetuated today with many of our newer development methods. I am not just talking pure agile, I am talking any method that claims to be agile-like. This myth misuses the spirit of agile interpreting it to mean it’s OK to cut out steps that the person sees as unnecessary.
The truth is that data modeling can be done in an incremental manner. Today’s data architect has more advanced modeling tools and works in highly collaborative environments that shortens the data model development lifecycle. The audience for data models is expanding beyond the software development players. These new players need a data model to map their data in way they can comprehend.
Myth #2: I don’t need a data model
This myth is a good case of you don’t know what you don’t know. It’s easy to prototype an app in Access. It’s easy to create a data model in Visio. What you don’t understand is that the data model is one of the outputs of a larger data design process. Note that I used data design rather than database design. If a project is creating and manipulating data, it needs to understand how that data’s lifecycle works and how the app and end user community will interact with it. That is data design and is more than creating a database.
Dispelling this myth involves making the app development team understand that the need for a data model is more than a task on the timeline of a project plan. It’s about data quality that comes to life at deployment. It’s about optimizing performance that avoids headaches at peak usage. It’s about avoiding future rework to add or fix functionality missed when the data design process was cut or shortened.
Myth #3: Big data does not need a data model
This myth stems from big data vendors’ selling points that big data database require minimal data management. Their slide decks point to the overhead that relational database management systems require. Gone are the onerous data design and database management processes. These are overcome by new technologies and significantly more horsepower behind the scenes.
There is no doubt that these new big data database are changing the data professional’s world. That is not a bad thing. Our role is to deliver data timely to our consumers. These technologies make data retrieval and manipulation more flexible. These databases, still in their relative infancy, will continue to revolutionize the database world.
Data modeling has a place in the big data world. That place is about understanding the data just as it’s in the relational world. The audience for data modeling in the big data arena is most certainly different. Modeling may not be the same as in traditional relational development methodologies. It’s more about helping data folk farther downstream understand the data. The use is more oriented to interpreting the data in order to understand the data.