William Burkett and I have been talking about whether what kinds of data gets collected, how it gets used, and how it gets collected are not part of a data architect's role but that of a business process architect and/or a software architect. I was taking the view point that depending on a business data strategy it could be. William thinks that a tighter definition is needed. What have others experienced? Out in the field how do organizations distinguish a data architect's role as compared with that of a software architect or business process architect?
Thanks, Michelle --
I'd like to slightly modify the description of what we've been talking about. It isn't whether or not those things are part of a data architect's role but whether they are part of a data architecture as a design artifact. Those things are certainly things that a data architect needs to consider in conjunction with software and process architects.
You're observation from the other thread is right-on: "...components associated with data architecture are more than not being muddied with that of a software architect or business process architect. "
I really do think that building architectural design practices have a lot to teach us about how we do what we're doing. Particularly the fact that there are many different kinds of design drawings that are created and used to construct a building.
In my experience, I have noticed data management thinkers and authors exhibiting what I call the "Long-pole-in-the-tent" syndrome. For example, if I was working on a Data Quality project, Data Quality is the long pole in the tent and everything else - metadata, master data, data security - hangs off of that that and is biased by it. The same goes for Data Architecture - when it's the center of the universe, everything revolves around it. Each data management topic or discipline we care to name or think about needs to be individually and holistically considered within the context of overall enterprise data management and coordinated with other topics/disciplines as "equal partners". No one discipline (other than data governance) rules them all. Stay in your lane.
Now take that up a level: Data architecture/data management takes place within the context of IT systems (mostly). How does data architecture (and other data management disciplines) relate to and integrate with other IT architectures - software, hardware, etc. Take it up one more level: IT systems exist within the context of an enterprise: How do IT system architectures relate to and integrate with Business Process Architectures, Capability Architectures, Organization architectures and Goal Architectures? When we can identify these individual viewpoints/architectures/lanes, we have different viewpoint-specific design artifacts that are directly analogous to the varieties of blueprint/design drawings created to specify the design of a building. And each expert can stay in their lane.
With this multi-viewpoint viewpoint, you can get a better picture of what a "thing" like data architecture is and less "means different things to different people" ambiguity