You’ll have to forgive me for spoofing the famous movie line “We don’t need no stinking badges” (Treasure of the Sierra Madre, 1948 and Blazing Saddles, 1974), it just seemed quite apropos J
I was discussing data modeling needs recently with a potential customer – and like many shops I visit, they saw no need for data modeling. They believed that their DBAs, data administrators and application architects knew “everything about everything” when it came to things that were home grown – and that the rest were third party applications over which they had no control and thus no need for a data model. That’s a very common belief these days it seems.
So my response was to try to enlighten them about why data modeling makes sense no matter what – and especially for the scenario they described. I thought it might be worthwhile to share those points with the general public in the hopes of convincing a few more people.
Five common misbeliefs that data modeling is unnecessary:
1. Our DBAs, data administrators and application architects have our databases under control.
That’s good news – you’re doing better than many shops. But what would happen if those guys or gals happened to play the Mega Millions lottery in a pool, and win some of that $360 million? What’s going to happen when they come in Monday and quit? That’s a heck of a lot of knowledge, wisdom and experience to try to backfill – and quickly. Wouldn’t it make sense to have a data model make that process a little easier? OK – so the likelihood of that happening is low. What if they all get new jobs or retire around the same time? These things happen – so like the Boy Scouts say “Be Prepared”.
2. We only use 3rd party applications like SAP or Peoplesoft, so to us the database is a black box.
That’s perfectly true – often you cannot do anything about the design of such products. But knowing the design has several advantages. Ever been on a tech support call and wished you had a little more knowledge to either communicate your issue better or firmly dismiss a poor reason they say is the problem – and you know it is not. How about when you get a new version of the 3rd party application, would knowing about some of the structural changes be useful in case the upgrade of the data runs into issues? And what if the business makes a requirements change, such as having all addresses fully qualified and verified against a validity database? Wouldn’t having some idea of all the areas impacted be helpful? I may not be able to effect changes to the US highway system, but it sure helps to have a map for long drives outside my comfort zone.
3. We only use home grown applications, so we already know everything about all the databases.
Actually, this has already been addressed by the prior two points (just exchange home grown for 3rd party application). Because all the same items hold true: you need to protect your company from unforeseen knowledge loss, and it often helps to have a “roadmap” for impact analysis no matter who built the application. In many cases the justification for data modeling is even higher when the applications are developed in house. Because if you built the highways, you better be able to best navigate them – and a picture almost always helps.
4. We contract out application development, so no need to worry about such technical issues.
Ok – so when you buy a new home, you’re comfortable with just telling the builder to make something with 2600 square feet? That you don’t need to see a floor plan that meets your requirements, and that the contractors building it don’t need any blueprints off which to work. We all know that’s not true – especially because a home is such a large investment of the most valuable kind of money – our own. Well application development is no less specialized and critical, and it costs lots of precious corporate budget. What’s more, 80% or more of the IT project failures I’ve seen could have been averted or at least lessened by having a data model up front. I’ve even been an expert witness in court cases on this issue. The data model is nothing more than a collection of the business requirements. If an application fails and there was no such document defining the business requirements – then whose fault is it? The best companies I’ve visited not only do data models for their own projects (regardless of who builds them), they even require that 3rd party vendors provide data models as part of the RFP process.
5. Data modeling is quite outdated and has been replaced by newer methodologies such as UML.
That could well be true. If your application developers have extensive UML models that fully cover the underlying “persistent” data structures, you may not need to do data models as well. But application developers tend to be programmers, and programmers tend to think (and thus model) in terms of what the data in motion needs are – which is what their programs embody. So having just UML models may in fact provide you a false sense of security that you’re fully covered. If the UML models do not cover persistent data storage, then you may well need a data model to complement your UML models. It won’t hurt to double check to be safe.