Data modeling brings together a diverse cast of characters into a dysfunctional family. Database design efforts share moments of dysfunction similar to large holiday family gatherings. Like a family, our ability to work together depends on the quality of the relationships we build with fellow team members.
Let’s walk through a Venn diagram of the primary roles involved in database design. For discussion, we are looking at the interactions between data administration, database administration and application development; the players on the critical path to database delivery.
I will start by briefly describing these roles to get us on the same page. Database designers, data architects and data modelers; the designers and managers of data models; are the main data administration players. DBAs; the managers of DBMS environments and databases; play the role of database administration. Programmers and analysts; the builders of computer applications; are the core members of application development.
Intersections of Dysfunction
We need to look at the outer intersections on the Venn diagram to understand our dysfunction. Optimally, an organization strives to have little to no involvement of these dysfunctions in their database design lifecycle.
Missed connections live in the world where data modeling involves application development and data administration without the active involvement of database administration. This alignment typically creates beautiful data models. The physical data model is either anemic or missing in action.
The primary dysfunction is the missing connection of the logical model to the physical database. The modeler creates the first cut of DDL and throws it over the wall to the DBA. The model becomes out of date as the DBA changes the design without data modeler involvement. The model is seen as documentation and does not reflect the real DBMS. It is seen as having no to little value.
Missed opportunities exist where the data modeler is removed from the picture, and the application developer and DBA assume responsibility for the database design. The application developer sketches up the database design, perhaps in Visio, and gives it to the DBA to create the database.
The most prominent dysfunction is the absence of enterprise data analysis and design that result in reuse and standardization of design. It is unlikely that application developers and DBAs perform enterprise data analysis and fully attribute metadata. The data modeler assumed a passive role that undermines the integrity of the enterprise’s data designs.
Reversed reality is where the data modeler and DBA reverse engineer databases into data models. Models are most certainly physical representations of the databases. If a logical model exists, the data modeler creates the business names and definitions.
This dysfunction involves no one outside of the data world in the data modeling practice. Modeling is more a documentation process with no data analysis or design performed. The value of data modeling is most likely questioned in this situation. Application developers may use the data model as their visualization of the database. The linkage to the business is definitely broken.
The Promised Land
Moving to the center of the diagram, the Promised Land is where it all falls into place. Data administration, database administration and application development participate in the data modeling function. This is where an enterprise ideally wants to find itself in the data modeling world.
Dysfunction can live in the Promised Land and most likely does in most organizations. It is possible for all parties to participate in data modeling and the process still is broken. Good modeling needs cross-functional participation and all parties actively engaged in sound data modeling practices. In other words: engaged rather than participating.
Most enterprises coexist in different parts of this diagram. Being in the center is ideal. It is quite realistic that data modeling falls in the other intersections as well. That may not be perfect but at least data modeling is alive and functioning in different degrees. Opportunites exist to move to the Promised Land.
This diagram is not meant to pigeon hole or judge data modeling practices. It is meant to demonstrate the dysfunction that exists when data modeling is not approached in a cross-functional team environment. Each of the roles highlighted perform a critical function. When you eliminate one, you subtract value from the practice of data modeling.