Some old school data modeling thoughts

I like a challenge. I particularly like a challenge when it comes to data modeling. Recently, I was assigned to lead the database design effort on a project team that other data team members warned me as being not-so-data-friendly. The database design effort turned out to be quite successful.

There is an important skill that is necessary for a data architect to be productive and successful. The skill is understanding the team that you are working with and aligning database design methods, processes and deliverables with the team’s methods, processes and deliverables.

Early in my assignment I recognized that the team was a cohesive unit that has worked together for many years. They had proven development methods with well-defined roles. Unfortunately their database design experience was “Throw it over the wall and wait for the data model to come back.” The database designer was not part of the cohesive team.

The assignment became an exercise in building a team tightly integrated the data architect. I chose to use some old school data modeling techniques. The challenge was not technology. It was a challenge in building relationships. The solution to that challenge has largely remained the same over the years. There were five pieces of the puzzle I used to integrate the data architect and data model with the team.

  1. Collaborate
    The data architect became involved early in project. Frequent collaborative data design sessions resulted in a database design that met the business requirements and technical development needs. A stake in game came along with collaboration. All team members owned that data model and could speak to how it worked.
  2. Educate
    A common cause in the misalignment of development and data team members is not knowing what the other team members need. Each team member owns the job of making their teammates aware of their needs and why they need what they need. It isn’t formal education. It is on-the-job data modeling and mentoring that brings that data knowledge to the team. If you are data architect, you need to be an educator.
  3. Communicate
    Poor and no communication is the culprit of misalignment in just about any role or team. Data architects need to make an extra effort to communicate often and regularly. That means publishing data models, data dictionaries, and design review meeting agendas and minutes.
  4. Use pencil, paper, markers
    There is a lot to be said about picking up a dry erase marker and modeling on a whiteboard. Numerous studies show that keeping the laptop shut and using pen, paper and markers instead yields better results. I experience much more interaction and personally give what I am drawing on a whiteboard more thought than when I click on an icon in ERwin. The same applies to sketching the flow of data or documenting metadata.
  5. Walk the data
    Data architects like to create beautiful well documented data models. The data architect role in data modeling is more than that of a designer. The data architect needs to be a tour guide. When given the chance to explain an ERD, give the team members a stop by stop tour through the data model. That means walking a piece of data from inception to final consumption. Assume you are the end user and explain how the business requirements are met by the entities and relationships.

Tom Bilcze

Leave a Reply

Your email address will not be published. Required fields are marked *