As a data modeler, I find that some of my fellow IT team members don’t exactly know what I do in my profession. Some think of me as a documentation specialist. Others see me as a DBA. A good percent believe I spend my days drawing pretty pictures. Some are aware what the pictures are and others are clueless.
This pattern has been pretty consistent across the various enterprises I have worked at over the years. I must admit that in recent years with data taking a more front and center position in the IT space with data warehousing, master data management and big data that people are more aware of data models.
Recently I was asked to teach an introductory class on data modeling to business systems analysts. I have taught variations of this class over the years to a wide variety of audiences. I knew that this class had to be more about data models for non-data modelers and not data modeling.
There is quite a bit of difference in training staff on data models rather than training them in data modeling. So often data professionals feel the best approach to helping the IT department understand what data modelers do is to teach them data modeling. I felt that way for most of my career. Class after class went by where I extolled the benefit of normalization and the process of physicalizing a logical data model that started in a conceptual data model.
When I teach about data models, I spend a brief amount of time, generally 10-15 minutes on a data model primer concentrating on entities, attributes and relationships. The most important foundation you can give non-data modelers is a how to read a data model. From that point on, I look at the audience’s role in the organization and structure the class accordingly.
Business systems analysts need to understand their interfaces with data models and data modelers. I covered the data model lifecycle and how business requirements are transformed into entities and attributes that become the database. I also walked the students through a student database data model emphasizing how business rules become relationships and the importance of them accurately capturing the business rule.
This method of data model training customized to the students’ roles works well. It demonstrates the importance of the student’s’ deliverables on the creation of the data model. They also see the value the data model and related metadata bring to their current and future business analysis efforts. Walking their business requirements through the data model is very important in bringing relevancy to the data model and data modeler.
Educating team members on data models and data modeling shows the importance of data modelers to being more conversational. Good communication and forming strong partnerships with fellow IT team members is critical in the success of a data modeler’s work and being engaged in application development efforts. The subtle change from teaching data modeling to helping team members understand models is a good start in forming that partnership and linkage of work efforts.
Modeling Global User Community President