Who Owns the Data Model?
A rapidly growing organization has a team of skilleddevelopers tasked with building and maintaining operational and reporting applications. In the absence of data modelers and data architects, these developers also do the data modeling. Sadie the developer receives a request to customize an application that includes adding a new database table. In addition to coding, she updates the data model and database. Often the developer who enhances an application is not the one who built the application. A developer from this organization asks, "Who owns the data model?" How would you respond?
I received more than 100 responses to this challenge. (If you're not a Design Challenger, add your email at www.stevehoberman.com.)
Thirty-seven percent of the responses say the business should own the model, 22 percent say the development team, 15 percent say the individual developer, 11 percent say the application manager or database administrator, and 15 percent say no one owns the model.
The business is the owner. The greatest number of responses stressed the need to have the collective enterprise, a data steward or the business sponsor take ownership for the model. Jan Kamil, enterprise data architect, summarizes: "Even in an organization with a viable and robust data administration staff, the modelers don't 'own' the data model - they are only the caretakers of the model. The true owner of any data model is the business organization whose domain is described by the model." Solution architect Gary Alexander agrees: "Everyone is a custodian, maintainer or user. The developer may have a charter to make changes because of business requirements or technical design decisions - but it doesn't 'belong' to them, and neither does the application code." Patrick McMullen, data architect, explains that similar to a homeowner who owns the architect's plans, the business owns the data models.
The development team is the owner. The second largest number of responses said the collective development team should own the model. Data administrator Chris Welch adds, "The team should have a code review in place so that any changes that are done are reviewed by someone. This keeps all team members informed about changes while maintaining the ability for everyone to make changes to the model as needed by their current project assignment."
The individual developer is the owner. Fifteen percent of the respondents believe the person making the change owns the model. Data warehouse architect Tim Klein says, "Owners for any part of a system should be those who have a stake in its accuracy and completeness, and who have the skills and knowledge to manage it well. In this case, it's clear that the developers fulfill both of those criteria." Mark Steinhorst, database architect, calls this the "hot potato" ownership approach. "The developer who last modifies the data model is responsible for ensuring that all relevant application components are modified and tested." Both senior application architect Rick Karl and consultant Don McMunn refer to this as the librarian approach. Don adds, "One of the skilled developers should 'own' the data model librarian role for a month before handing it off to the next person skilled and disciplined enough to validate model and database changes. All changes should be reviewed by the librarian of the month for compliance to organization standards."
The application manager or database administrator is the owner. Eleven percent of the responses say the person that feels the pain when the application is not working properly is the data model owner. Mehmet Orun, senior manager, recommends answering this question to find the owner: "Who will the end user/business owner/IT upper management contact if the application is not doing what it is supposed to because of inconsistencies, other data quality issues or bugs?" BI data integration manager Pamela Larsen adds, "I would think that there are still database administrators who are responsible for performance and tuning the database, so they should ultimately own the data models."
No one owns the model. Fifteen percent of the respondents believe no one owns the model, primarily because no one may have the big picture in mind. Jim Cummins, senior manager, says, "Good data modelers are trained in all the nuances of data modeling and in conjunction with the data architects are taking into consideration the data needs of the corporation from a larger context than a single application or system." Quality consultant Hal Metz has a similar belief: "The nature of data modeling is compromising the local optimization for the best solution for the organization."
There were a number of other creative solutions to this challenge as well. Technology architect Phani Kumar believes ownership should be shared based upon the level of detail of the model (e.g., logical versus physical). Or perhaps Sadie the developer will shortly be Sadie the data architect, as John Harper, information quality manager, explains: "Sadie is probably out of luck getting sponsorship for real database design because of the low priority her management places on architecture. Her best bet is to take ownership herself, learn all she can about good database design and slowly begin to improve the model. Then create a subject area model of the database for communication purposes. In addition, she may set herself up for potential architectural roles."