by Karen Lopez
Where Should the Division of Responsibilities Lie Between Data Modeler and DBA?
In the past, data architects/modelers have been primarily responsible for preparing logical data models, then they threw models over the wall to the DBAs who said "what the heck is this?" and then did their own physical models (or reasonable facsimile of a model), generated DDL, and never used the models again. And the data modelers happily modeled on, not seeing the results of their efforts implemented in any form. Sure, we build models for reasons other than for building stuff, but I think model-driven development is one of the most valuable uses of data models -- probably by at least one order of magnitude.
I think expectations from management have shifted over the years, which is why I'm getting reports of reduced data modeling staff and less use of data models in modern development efforts.
Data Modelers and Model-Driven Development
When I help clients hire data architects, I ask them about their physical modeling experiences and skills. I want data modelers who understand enough about physical design and performance to be able to participate actively in design efforts. I want them to understand the performance trade-offs of design decisions. I want them to understand physical aspects in physical data models. I think a professional data modeler should be able to generate first cut DDL and understand the implications of PK selection, index strategies, etc.
On my projects, where we follow a model-driven design process, data modelers get their hands dirty by doing first cut physical data models. Why? Because that means the developers and DBA can see how the use of physical modeling can improve the development process. They don't have to learn a new tool. They can see why we go to the trouble of writing stuff down. Why it's *agile* to create a model instead of a series of throw away scripts. They can see how small updates take only minutes to deploy instead of hours to find all the instances of something hidden in a script. They can see the value in having a web-based clickable model for the entire team to use. They can see the value in being able to search across models for the entire enterprise. In other words, they see tons of value being delivered to their teams, directly from the data models.
I think the time of logical-only, pretty-but-unusable-by-development-teams data models is coming to an end. Not because logical-only data models are bad, but because we don't do enough to make them valuable to the architects and builders in IT. I do know of some organizations that handle logical to physical delegation very well. They have strong data governance programs and their teams collaborate well. But I'm finding this less often than I used to. I have some ideas why, but I'd love first to hear your opinions on how this is working for most IT organizations.
On my projects, the line between DA and DBA is closer to the physical end of the Zachman Framework. In other organizations, it's much higher up in the matrix. I have previously blogged about trying to force people who aren't passionate about one to do the other job, so I'm not saying that data modelers need to become DBAs. Or that DBAs need to become data modelers.
Where Do You See Data Modeling and Development?
What do you see happening on development projects now? Is there less data modeling in general? For both logical and physical data modeling? Where does the data modeler stop working and where does the DBA (or dev) start working on the physical design? What successes have you been part of?