One of the things I like most about data is the challenges that it presents. From my early school days, I have loved math, analyzing everyday things, and finding creative solutions. I love and thrive on my analytical side. Here are a few thoughts I have gathered over the years that speak to my analytical solutioning.
- Data is not the center of the universe.
I often hear data folk speaking as if they are the center of the universe; meaning that everyone must pass through their gates to reach the other end of the world. The data they think of are the processes, standards and people who manage data. Those players are not at the center. Data is indeed at the center. This distinction is important to understand. People can work with, manipulate and expose data with no or minimal data folk involvement. Our role as data architects is to guide and help our peers navigate, comprehend and use data efficiently to reach the other end of the world they seek. Become that tour guide.
- When developers will not come to me, then I must go to the developers.
IT development is fast, real fast in most cases. Project teams have their eye focused on the road ahead and their final destination. It’s easy to take a short cut through the grass around the data architect when no one is looking. What that means to us is that we cannot passively accept our role in a project. We must be a visible supportive player. That means attending meetings, diligently keeping current with the project status, and actively participating in development discussions. No matter what the methodology says, we must keep our eyes and ears to the road and hitch a ride to help the team reach their goals.
- A picture is not always worth a thousand words.
Many years ago when I first encountered an entity relationship diagram (ERD), my mentor told me that the data model speaks thousand words. I wish I had a $ for every time I have heard that over the years. Unfortunately, it is not completely true. A data model is a wonderful tool to visualize data requirements. It however cannot stand alone. A data model’s real value is the robust metadata that supports the picture. That is where people look to understand what the boxes and lines mean. Data architects, do NOT shortcut your modeling with trivial and non-existent metadata. The ERD is not complete without robust metadata under the covers.
- Data needs a place at the table
Most people understand the value of data. Many people do not value the cost of managing data. I see this as a major issue in the data and database management worlds. Application development delivers a visible product in web apps and customer solutions. Data does not enjoy that visibility. When project plans are built, it’s easy to gloss over the data stuff. It takes strong upper management support to acknowledge the involvement of data and other IT support resources on development teams. Data teams need management that can speak to their importance to upper IT, project and business management. The data architect’s place at the table is highly dependent on our leaders’ effective and engaged management.
- The devil is in the details.
“That data model should only take you a week to complete.” It may be a week, two weeks or a month. The issue is that people do not fully understand what data modeling is. Let’s face it, most people think it is a drawing that pretty picture. They do not see the analysis of data requirements and integration of the design in the enterprise. They do not understand the importance of documenting definitions in accurate and complete metadata. They do not see the process where business rules are transformed into relationships that will ultimately control the integrity and performance of the database. Data architects need to educate our customers that the ERD is not our only deliverable. Without these details, that pretty picture is only that, a pretty picture.
Old Data Architect Guy