It is entertaining to be in a room filled with people all claiming that they love data. What becomes more entertaining is discovering how each one views data uniquely and enjoys doing different things with or to that data. The data community has become one that is far more diverse than many realize.
Some individuals are focused on establishing a data governance practice, and long to spend hours defining taxonomies. Others want to spend efforts building up the many processes shipping metadata from one tool into another tool. And there may be any number of people who are experts in installing and configuring the tools persisting or virtualizing data, metadata, or the artifacts used by all the other people in the room. Still others in this room may be business analysts defining mapping documents, or data flow diagrams.
There will likely be some database administrators in the crowd, both those tending to the software and hardware elements that is the DBMS, and those DBAs overseeing specific applications and those applications’ data content. Add in dashboard designers who may have deep skills in one tool or another, and the room is becoming mighty crowded. And each one may say in answer to why they like their jobs, “I love data.”
For many years now anyone attempting to hire a “data architect” has had to approach the task gingerly, as some people claiming data architect chops come from an ETL background and see creating data pipelines as the main data architect task. These ETLers may be experts deep in a single tool, or across many tools.
Other data architects arose from a data modeling background and see Entity-Relationship diagramming, and defining structures using normalization or dimensionalization or Data Vault as their most important skills. Or the previously mentioned DBAs, once they reach a certain level of seniority may be re-branded as a data architect. The “data architect” umbrella has become quite wide.
The rise of the data scientist has added even more confusion, in that going through formal statistical analysis to find the proper regression coefficients and predictors of future results is often called “data modeling.” Any number of job seekers newly out of college with degrees in the Behavioral Sciences see “data modeling” in a job description and become thrilled over being able to play with data and discover new insights, only to be a little crestfallen over someone trying to explain the analysis of functional dependencies that is data modeling versus creating statistical models of data.
Across many organizations one can often see acronyms and terms defined multiple ways. Language is actually much more fluid than it is ever acknowledged as being. It is not very shocking that the terms “data architect” and even “data modeling” have multiple contexts applied to them.
In the information technology arena, even architect is only meaningful in that those having a title containing that word are to be considered an expert in some not-overly-defined something. Data architect, business intelligence architect, information architect, solution architect, infrastructure architect, and enterprise architect are all titles conveying a not-so-fully-identified prestige. And highly likely, many of those architects have a fondness for data, if asked. The beloved data may be in an operational store, data warehouse, data lake, or data mart; the data may be physically moved from here to there or virtualized. The individual may help get the data into whatever structures, manage it while it is in those structures, help get it out, analyze the heck out of it while it is there, or simply help document what that data means for everyone else. But each individual may have an intimate data calling, and in that sense he, she, or they become a data-comrade to everyone else loving data.