The investment of time in data modeling was as topic I came across a few times this past week. Jonathon Geiger authored an excellent article on ?Why Does Data Modeling Take So Long??in an Information Management email newsletter. It?s been retweeted quite a bit. Of course, this is not a new topic and just about everyone has an opinion on the matter. I thought that I would just chime in and give you my five reasons why data modeling is perceived as time and labor intensive activity.
- It?s not just data modeling. The overly simplified ?create data model? task on a project plan includes a heck of a lot more than just creating an ERD. I often find that business requirements have not been thoroughly captured by the Business Systems Analyst (BSA). The data modeler performs much of this business analysis as part of his/her modeling exercise. Most often, business rules have been captured. Many BSAs concentrate on process and either ignore or barely touch on data. The data modeler steps in and performs business data analysis as an early task in creating a logical data model. This is usually time ?hidden? on the project plan.
- Data modeling is iterative in nature.Most data lifecycle methodologies include a conceptual, logical and physical data model. They are most often depicted in the development lifecycle in a waterfall approach. It is true that one must follow the other, and the models are very much dependent on the completion of the predecessor model. The reality is that data modeling also is iterative in nature. When the BSA hands the modeler the business requirements and says ?Go!?, the modeling process begins. Traditional project management leads us to check off the models as they are completed. Experienced data modelers know that the models are revisited often during the development process. New and changing business requirements necessitate changes in data structures. Subtle project misunderstandings may necessitate changes. To the non-data modeling team members, it appears that data modeling just lingers on forever.
- It?s all about perception. Most IT team members know just enough about data modeling to be dangerous. They may have attended training seminars where a simplistic data model was developed during the class. They may have seen industry models that claim to contain 80% – 90% of modeled components for an enterprise. Project managers may have templates that recommend timeframes for data modeling activities. Each of these scenarios tends to underestimate and play down the importance of data analysis and data modeling. The team goes into the development project with a preconceived notion on the amount of time data modeling will take. When the modeler uncovers complex data requirements that require a longer period of time, the team just does not understand the difference in time from what they perceive as ample modeling time.
- Few people really understand the importance of a good data model.I often think changing this mindset has a lot to do with us in the modeling community. Relational databases have been mainstream for many years. It seems like data modelers could have surely cemented the importance of a good data model in our coworkers? minds by now. The exercise of fully attributing a data model and accurately capturing the business rules may be perceived as an academic exercise outside of the database community. Often the data model is seen as a piece of documentation that needs to be completed before we get to the ?real? work of defining the database. The project team knows the DBA will be delivering the final database to their development environment. What they miss is the fact that the data model is the means by which the business community?s needs will be answered through the database, not the DDL. This is another example of work hidden in the data modeling timeline.
- What does metadata management have to do with data modeling? Metadata, we don?t need stinking metadata! As the data warehousing, business intelligence and master data management worlds have expanded, the role of metadata is no longer seen as the ugly red-headed stepchild. Project teams may tolerate time spent on data modeling since they know the end result is the database. This is what ?they? really need. What is often misunderstood is that good metadata is just as, if not more important. Changes in technology have opened up the technology world to the non-technical world. Metadata is a very important piece of the puzzle that enables the non-technical worker to work faster and more efficiently without out IT intervention. The definition of the word ?they? now encompasses a more global community with needs from the data modeler. The processes surrounding metadata management are time consuming. As our designs become more enterprise in nature with these new technologies, the processes related to metadata management become more complex. The data modeler is at ground zero on these efforts and expends considerable effort and time on these processes. Project management and project teams often do not see these tasks as part of data modeling. More typical is the feeling that metadata is a documentation exercise and the time invested should be minimal in contrast to the time expended to create the data model.
I would love to hear your feedback on this topic. It is a fascinating topic that is sure to elicit differing opinions. Each IT shop has a different take on data modeling and database design. I am certain that there are many flavors on why data modeling takes so long. Don?t be shy? what do you think?
Modeling Global User Community President
I’ve reached 3NF in “Why Be Normal?” How normalized are you?
Find out more about ?Why Be Normal?? at http://erwin.com/whybenormal/. Want to know what ?We Be Normal!? is all about? Visit https://communities.ca.com/web/ca-modeling-global-user-community/to get the whole story.
Follow ERwin online through Twitter, Facebook, and LinkedIn.
Twitter: @ERwinModeling and #YBNormal