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
William Frank says
"I agree with William Bennet that there are many important things to say *about" data architecture, such as what it is for, what it depends on, ... But these are not *definitions*.
As he says: "a nice strategic description of the role of a data architecture, but doesn't tell me what it is."
And while it is true that there will be many different definitions of data architecture, saying important things about data architecture is not offering a *definition* of it.
I think data architects should understand what lexicographers and liguists and logicians and philosopers and physicists and mathematicians and chemists have used as the criteria for a defintion, since the times of Euclid, Confucius and Aristotle:
a defintion has the form:
phrase to be defined (definiendum)
<a kind of, instance of, role of, group of, part of>
more general term
that satisfies a (restriction).
For example, "an organic compound is a chemical compound that contains carbon"
This has proved useful because it obeys the rule of substitutability:
the definiendum can be replace in a sentence by the definiens without change of meaning
its what we find in a dictionary, a book on calculus, and in a coherent data model.
Of course, there will also be a place to *add* contextual information, similar phrases, provenance, examples of use, but these are not part of the definition. "