I often hear from my peers that no one really understands what they do. That is usually accompanied by the “no one really appreciates what I do” comment. It is something that is not so unique to data architects but something many technical people face in their work.
These statements are worthy of some deeper thought. There are certainly some real meanings buried in these off the cuff comments. Here are some of my favorite misconceptions that people have made of of me over the years.
- I am a DBA. Like most data architects, I sit in the same workgroup and work area as the DBAs. The number of DBAs outnumbers data architects. This leads to the assumption that I must be a DBA. Developers work closely with DBAs and make the assumption that my role is just another flavor of the DBA; the DBA who does the upfront work on defining the database.The root of this is the undervaluing of data design and metadata management within the system development lifecycle. Unfortunately this misconception will remain until the full lifecycle of data and database management is embraced in the enterprise.
- I am a technical writer. Data architects produce a good bit of documentation in their everyday work processes. Telling the story of data is our primary role and that means we write a lot. It is that documentation that team members remember about what I did for them and their project.
This presumption can be valid when the data architect’s work is not in sync with the development lifecycle. Models reverse engineered, definitions and dictionaries solely used as documentation, and models out of sync with the real world are signs you have become a tech writer rather than a data architect.
- I am a graphic artist. This does not need much definition. Entity Relationship diagrams (ERD) are the most visible piece of work data architects create. It is easy to understand how coworkers come to the decision that the architect creates the picture (roadmap) of the database and that is it.
I own this misconception with one caveat. An effective data architect goes beyond the graphic artist label by backing up that pretty picture with robust metadata and with deliverables that integrate across all roles the database development lifecycle.
- I am a methodologist. Maybe this is unique to me, but in most shops I have worked, I am an active player in the definition of the system development lifecycle (SDLC). That does not necessarily mean that people embrace the SDLC. It just means they know that Tom is a go-to guy for it.
This is another misconception that I own. Methodologies save the enterprise money, time and resources. Unfortunately, many times they are over complicated and burdensome to follow. I keep my eyes on the methodology and constantly look at how we can shape it to meet current development trends while respecting its integrity. It’s my voice in that effort that people remember.
The bottom line is that these misconceptions are not totally out of bounds. I perform all of these jobs in my role as a data architect. People do not understand the importance of data design. Selling data administration is hard. The most effective data architect marketing is when the individual demonstrates their value and understands and respects the values of fellow team members’ processes. Integrating processes and being a team member is the soft sell that turns misconceptions into understandings.
I am presenting at Data Modeling Zone 2014 in Portland, Oregon. I hope that you will join me in my sessions: Is your data model a work of art? and Relationship versatility and the data modeler #DMzone