Where Does the Line Between Data Modeler and DBA Fall?

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?

Karen Lopez

Karen Lopez is Sr. Project Manager and Architect at InfoAdvisors. She has 20+ years of experience in project and data management on large, multi-project programs. Karen specializes in the practical application of data management principles.
She is a frequent speaker, blogger and panelist on data quality, data governance, logical and physical modeling, data compliance, development methodologies and social issues in computing.
Karen is an active user on social media and has been named one of the top 3 technology influencers by IBM Canada and one of the top 17 women in information management by Information Management Magazine.
She is a Microsoft SQL Server MVP, specializing in data modeling and database design. She’s an advisor to the DAMA, International Board and a member of the Advisory Board of Zachman, International.
She’s known for her slightly irreverent yet constructive opinions and rants on information technology topics. She wants you to love your data.
Karen is also moderator of the InfoAdvisors Discussion Groups at www.infoadvisors.com and dm-discuss on Yahoo Groups.
Follow Karen on Twitter (@datachick). View all posts by Karen Lopez →

Post navigation

Karen, an excellent topic! Until recently, I managed a group of development DBAs, and it was a struggle to get them to think in terms of modeling first, and using the models for generating DDL. Part of the problem was that all requirements gathering and documenting was done by another analysis group, and we were handed table specifications.

Unfortunately, with the exception of a project that I started, there never were documented models for us to go back and understand. This made it very difficult to bring new people up to speed on a project.

While, like you, I believe that data modelers and DBAs are different, I also believe that a good modeler has to have an understanding of DBA concerns, and the DBA really needs to understand the business rules that are incorporated in the model.

http://blog.infoadvisors.com Karen Lopez

I need to write more about this anti-pattern of having people just throw deliverables over a wall for the next team to pick up and make sense of them. The business analysis teams I work with a very good at gathering user stories and overall requirements. But they don’t have the time or skills to ask the required follow up questions that we architects and designers need to complete our deliverables. I just blogged about this, sort of, today, over on my personal blog

Perhaps I will expand upon this here on Dataversity, as I think it’s an important topic and one of the Biggest Challenges in Data Modeling.

Aniket Sao

Karen, At my organization I as a data modeler share the responsibility of developing both logical and physical data model and also generating DDL’s. This way I’m able to enforce all the established data naming standards and data domain standards. For any new data models which are being created the logical and physical models share a one to one relation. Its very rare for me that I need to something different with the physical model. I’m also responsible to deploy the DDL’s in the Build environment. Once the Build environment stabilizes I hand over the DDL’s to the infrastructure DBA’s. We have been very successful with this approach.

chris kress

Here we have a small team of dedicated data analyst/modelers. We use the business requirements specifictions and meetings with the development team to create a conceptual, logical, then physical model. Our DB2 z/OS DBAs attend all those meetings with us and are involved in the physical design. Once done, we generate the DDL out of the model and send it to the DBA. Our midrange DBA’s rarely get involved and implement whatever we send them.

What I would like to know is where the line is between our enterprise data architects and our modelers. Our EA team is fairely new, just a few years, and there is very little communication between us. Some of them want meet with the business and create the conceptual model for us and identify the data elements that are within scope. This is a major change for us. I would like to know what others do.

This is an excellent discussion. In my experience, Data Architects need to be involved in the physical design and creating DDL. They will have more business understanding of Data Access patterns used by the application. This will help in making indexing decisions. In my view Data Architecture is a combination of Business Analysis and Technical design of the DB objects to meet the business requirement while balancing techincal requiements (storage, archival and performance). So, Data Architects should be in a position to guide the DBA to think ahead in terms of scaling, archiving, purging and performance.