10 Bad reasons to NOT create a data model

In my last blog post I shared my top ten reasons for creating a data model. That post was written from a data modeler’s perspective.  Today, I am looking at data modeling from a non-data modeler’s point of view. I qualify this post by disclosing that I am a data modeler attempting to assume the mindset of an application developer.

  1. No one told me I had to have one. – We carry this reasoning forward from our childhood. The assumption is that I only need to do what mom and dad told me. No one specifically mentioned a data model. I am assuming it is not needed. This is a good case in point where a methodology has no teeth and is largely a piece of paper rather than a blueprint for effective system design.
  2. Agile tells me I don’t need it. – Data modelers cringe when they hear the word agile. They have repeatedly heard developers quote a principle of agile that you only create a deliverable when it is absolutely necessary. This logic makes the data model unnecessary. The agile principle is really saying requirements should be captured at an appropriate level of detail and in a just-in-time-manner. It does not advocate the non-capture of data requirements. i.e. the data model.
  3. It doesn’t apply to this database. – Developers acknowledge large applications with complex data requirements need a data model. Thank your fellow data modelers and project managers for engraining this fact into our methods. The argument with smaller databases and applications is that a data model is unnecessary where there is less complexity, less data, and shorter development timelines. This logic misses the value the data model brings in the capture of metadata, standardization of design, enterprise reuse of data, and validation of data requirements.
  4. It’s unneeded documentation. – This is a typical response when the data model is only a checkmark on the project’s list of deliverables. It comes down to visibility of the data model. The DBA may use your model but if the developer does not, it’s just a piece of paper to them. Maybe it’s time to hold some data model reviews and walkthroughs.
  5. It just slows me down.  This statement ties in with the perception of the model as only a piece of documentation. Engage the developer in a data model walkthrough. Make sure it is printed in a readable format that hangs on their cubicle wall. Show them how the model is the roadmap for the database. Show them how much time data design saves them in development.
  6. It just means a lot of rework. – This is a telltale sign that the development methodology is broken. Developers have been coding based on their database design or made assumptions about the data before the data requirements have been captured. Data modelers need to work with project managers and the development team to make sure they are engaged in a timely manner and that the system development lifecycle is followed.
  7. No one will ever see it. – Data modelers are very detailed. They publish data models and data dictionaries as required in project folders, intranet pages or SharePoint. This happens with 100s and even 1,000s of other project documents. They get lost in the madness. Modelers are not marketers. The data modeler needs to print copies of models for developers, post a copy in the project room, engage the team in discussions, and market the model.
  8. No one understands it. – A data model distills the story of data into a collection of boxes and lines. As simple as this seems to the data modeler, it is not so easily understood by many people. People tend to dismiss things as unnecessary that they do not understand.  This argument is easily countered with simple training on data modeling notation and how to read a data model.
  9. I know what the database needs looks like. – There are developers who dabble in data design and sketch out their idea of the database. They may do this in word processors, spreadsheets and MS Visio. The design is complete in their eyes. The truth is design is not complete. Database characteristics and efficiencies need modeled. Objects must be standardized across the enterprise. The data modeler and DBA perform these and many more value adds on the design.
  10. I don’t trust the data modeler. – A brutally honest statement that tells all. This statement shows a lack of engagement and conversation in the development lifecycle. It may result from a history of unmet expectations and timelines. It could be a lack of communications and poor alignment with the methodology. Each of these deficiencies and more must be addressed to overcome this perception.
Print Friendly, PDF & Email

Leave a Reply

Your email address will not be published. Required fields are marked *