Many years ago when I began blogging about data modeling I thought my focus would be on helping fellow IT professionals be a better data modeler. There was a void in the blogosphere of data architects writing about data management and the data architect profession.
If you are a blogger or wanna-be blogger, you understand that what you blog about has to be something that you are passionate about. I soon discovered that blogging about how to assign keys, normalize data models and perform other mechanics of the data modeling trade was not what I wanted to talk about.
My passion is driven from my 25+ years of observing data architects and participating in data modeling exercises. I enjoy talking about the softer side of data modeling. I have observed that people can more easily learn the technical and mechanical side of the data architect’s work. People have a more difficult time learning the softer side of the data architect’s world. Let’s explore five of the hard to learn things that I see more often than I like.
- Selling ice to an Eskimo
As much as you value your data model, most of your fellow IT and business team members do not share that love. Like the Eskimo in need of no ice, they do not see a need for an ERD. Data architects need to be marketers. We understand the value and necessity of data models. We need to be creative and persistent in getting that message out. Learn your audience and understand their needs. Those are essential in selling yourself and your artifacts. Add value to someone’s work, and they take notice of what you do. - Over and under sharing
We all have Facebook friends that share too much and others that hardly share anything. Like a good Facebook user, you need to be conscious of what you share, how you share it, and to who you share. Data modeling and metadata management tools give data architects a variety of methods to share our work. You should develop a catalog of artifacts you produce that identifies the target audience, publication media, level of detail and abstraction, and frequency of sharing. Know your audience. - Hearing what I said
Our parents and teachers worked hard to develop our communication skills early in our life. Communications has taken on new shapes and forms today. Regardless of the medium, most of us have problems with communicating. For the data architect, communications is essential. Data architects need to target their data message to their consumers. I have often seen more of a lack of communication rather than poor communications. We must communicate frequently and make our presence known to get the job done. - Knowing what to do
The data architect community is reactionary. We were leery of object modeling. Agile remains a dirty word for many. Big data and NoSQL is perplexing. We are uncertain of what do in the new IT world. Being skilled in data modeling and relational methods is not enough. We must understand new technologies and methods. I look at our community as being the explainers of data. Transform your role to help people understand the data and how it relates to their work. Let your artifacts and deliverables be driven by your transformed role. - People, people who need people
This bears repeating. It made my list of the five hard data management challenges. Data has assumed a visible and important role. Most companies’ wealth depends on the data it possesses and how it manages that data. The data architect is an important role in the management of data. I personally have experienced problems in locating skilled data architects. I am supposing that our roles are seen as somewhat old-fashioned working with relational databases. Perhaps this perception will change as the big data world matures and the need for data management becomes more visible. I fully expect that to happen with the data architect role being something I may not recognize but never the less being the explainer of data.
Tom Bilcze
Explainer of Data