For example, a data modeler builds a data model that meets the requirements and is structurally sound and therefore should receive good marks from the Data Model Scorecard. Yet in the end, the model is not used or not used properly, and therefore would be penalized through this eleventh category.
Should the data modeler be held responsible if their model was not used (or not used properly)? If yes, why? If no, who should be responsible?
Most of the Design Challengers who weighed in on this challenge believe the data modeler should not be held responsible. In fact, 64 percent think the data modeler is not responsible. Thirty-six percent believe the data modeler is responsible, especially if he or she did not properly explain and market the model.
Data Modeler Is Not Responsible
The data modeler usually has no authority over database administrators and developers. To quote Bruce Baum, global data architect, "The data modeler is a contributor, not a rules/standards/methodology enforcer." Data Architect Missy Wittmann adds that factors completely outside the control of the data modeler (such as budgeting and resource constraints) can impact whether the model gets used. Jeff Dallara, data management lead, summarizes with this analogy, "If an architect creates blueprints for the proper design of a house, specifying all the load bearing and design requirements, and someone builds a house without regard to those blueprints, and the house falls down, would you hold the architect responsible? I think not, especially if it could be shown that all of the architect's specifications, if followed, would not let the house fall down. Same holds true for the data modeler. You don't use the model, you take your chances."
So who should be responsible? Trevor Hodges, information management consultant, believes that the data governance or executive group is responsible for ensuring data models are used correctly. Dan Bartoes, data architect, and Richard Leach, data specialist, believe the project manager is responsible. Developer Peter Heller believes those who implement the model should be responsible for its correct use.
Data Modeler Is Responsible - If the Model Was Not Properly Explained
Data Architect Jan Cohen says, "The data modeler is the one person who has to make the data model an important cog in the business machinery." Rich Kier, another data architect, admits this can be challenging to do: "A good modeler should be able to explain the benefits of their model to the rest of the team and increase adoption, but not all modelers are as good at pitching an idea as [they are at] normalizing a database, and not all developers are open-minded enough to listen." Mark Taylor, data strategy manager, encourages the modeler to accept this challenge: "As the person who knows the model best, the modeler is ideally placed to advocate for the model and should be expected to do that."
Professor Emeritus Gordon Everest emphasizes the data modeler's responsibility. "It is up to the data modeler to engage the users, to extract from them a description of their world and to reflect that in a data model. Then the modeler needs to document and present the data model to the users in a way that they can comprehend, and thus, validate it. This is similar to the question: Who is responsible if a student does not learn the material or skill in a course they are taking? I say, the responsibility falls mainly on the teacher, not the student." Mehmet Orun, senior manager and data architect, adds: "The modeler has a responsibility not just to produce a good model in isolation. [He must] then be proactive in presenting the information based on the needs of the audience." Data Architect Moshe Japha also supports this view: "If the reason the model wasn't used is that the developers did not understand the purpose of the columns and tables or that the modeler did not spend adequate time explaining the model, then yes, the modeler should be penalized."
Dave Wells, consultant, mentor and teacher, offers this succinct summary: "I think you have to dig deeper than the simple fact of non-use or misuse of a data model to determine responsibility. Ask first what use should have occurred: To communicate business rules? To document and verify requirements? To design a database? Once the kind of use is known, ask who should have used the data model; this person may bear some responsibility for non-use or misuse. [Consider the effect of] a renegade developer, maybe with inadequate data governance practices and processes, or perhaps a combination of the two."
Steve Hoberman is currently a data modeling consultant and instructor. He taught his first data modeling class in 1992 and has educated more than 10,000 people about data modeling and business intelligence techniques since then. Steve balances the formality and precision of data modeling with the realities of building software systems with severe time, budget, and people constraints. In his consulting and teaching, he focuses on templates, tools, and guidelines to reap the benefits of data modeling with minimal investment. Steve is the author of five books on data modeling, the founder of the Design Challenges group, and inventor of the Data Model Scorecard.
Both miss out on the opportunities provided by metadata-driven technologies. For example, in our own area we have a small team of 3 data modellers for our entire OLTP system, with over 5000 tables and 30,000 columns, and a much larger team of 18 data modellers for the Enterprise Data Warehouse, who have limited themselves to perhaps 20% of the entities in the OLTP system.
The difference between the two systems (OLTP vs DW) is that the first has extensive metadata support and automation for the whole application development lifecycle, whilst the second has almost nil. In fact the DW people are considering right now how to ensure their users actually use the data models - whereas no such question exists for the OLTP team.
The reason? The OLTP team cannot build the application without using the data model! It is inbuilt into our processes - so much automation is achieved that it would be unthinkable for a developer to bypass it, as it saves so much time.
So, the correct answer I think is that if the data models are not used then the people who put in place the SDLC process have failed.