Within the information technology sector, the term architect gets thrown around quite a lot. There are software architects, infrastructure architects, application architects, business intelligence architects, data architects, information architects, and more. It seems as if any area may include someone with an “architect”status. Certainly when laying out plans for a physical building, an architect has a specific meaning and role. But within IT “architect” is used in a much fuzzier manner.
Generally the term “architect” brings thoughts of design to the forefront; and in IT, when “architect” is incorporated as a title then design certainly plays a role. However, in IT the design intended is a higher level of expression than one might normally think. Even the lowliest of software developers design processes, but those of architect status focus on the design of all the processes in a composite fashion including how they interplay and flow among themselves. But, back to the fuzziness; even a high-level software architect may still be involved in the design of a single process, should that process be considered extremely complex or critical. Lacking any specific IT industry standard, all an architect-level title implies is retaining someone with “very strong” skills, able to help establish a more global picture and set direction for others, regardless of the qualification area before the architect, i.e., software, application, etc.
Data architect, in particular, is a title that has even more uncertainty surrounding it than most other categories of architect in IT. When “data architect” is the title, a close review of the job description is necessary in order to determine what is even being requested. Some of this added ambiguity arises from the data warehousing community.
There are times and places where a “data architect” is being requested and the desire is to have someone who has very strong skills with one or another of the ETL tools used in business intelligence. At other times, a business wants to hire a data architect who is very expert at data modeling techniques. Other occasions might be searching for someone very skilled at data warehousing practices with techniques dabbling into both ETL and data modeling. In addition they may desire someone who may also be a super business analyst but specifically deep in data warehouse and data mart knowledge. And yet other times, the data architect desired may need to be an enterprise data administrator and data modeler. For a single title, that is quite a large amount of variation.
Ideally, a data architect should have skills that touch on data as it is persisted and as it moves, particularly as it relates to integration. This set of data skills means being an expert at both defining data structures and at data integration practices—be they for business intelligence or for operational uses.
Although there would likely be usefulness in having both “business intelligence” and “enterprise” variations of data architect roles. There are many disparities in practices between operational uses of data and analytics uses of data, so that having one individual architect responsible across all areas might be too much territory to cover. It would water down the architect’s effectiveness, and leave employers with a very small pool of individuals who can be found with such a breadth of knowledge. A data architect should be involved in data governance practices, in data administration, in data integration, and in data modeling. Each organization must establish for themselves where to draw the line in having the data architect be the one establishing policies and goals for those areas or in having the data architect actually executing the governance, administration, integration, and modeling tasks.