Time to rethink the classification of DAMA’s data management functions?

In a recent LinkedIn post, data architect Bowie Muyutu asked (and answered) the following question:

Is data architecture a function of data management or is it the other way round?


We may easily ask the same question of almost any data management discipline.

Is data quality a function of master data management, or vica versa?

Bowie’s question high lights the complexity of the data management paradigm and, whether you agree with his hypothesis of not, raises some interesting points.

Here is the rest of Bowie’s post, which is re-posted with permission.


Some might relegate this to a ‘who is top dog’ discussion in the same way that some question whether or not tactics precede strategy. [ This article  makes a case in communications for the tail wagging the dog]

The trouble with leaving this matter unresolved in enterprise architecture and, specifically data architecture leads to childlike spats between resurgent architects claiming their space [I am one of those] and the rest of the IT community from project managers with little understanding of the role of architecture on a project [cue – should architecture precede a business case or is it the other way round] to dyed-in-the-wool agile developers that think architecture is, at best, a technical debt to be repaid after the fact and, dare I say, even business architects/analysts who, one would think, should know better, cannot distinguish between architecture and design (and even between architecture and requirements) and question why an additional ‘design/requirements’ layer is needed and, if it is, whether it precedes their work or not.

A lot of ink has been poured on these spats and this article is not about them but about the role DAMA’s DMBOK classification of data management functions seems to embolden detractors or “reductionists” of data architecture.

I once worked with a project manager who threw the DMBOK at me because I insisted that data architecture in fact includes all those data management functions and must not be seen as a separate line function from the rest. I also worked with a business analyst who insisted that, according to DMBOK, data architecture is not about data governance or data quality etc. and went on to reduce it to data modelling without, I suspect, the irony of realising that DAMA lists data modelling under Data Development.

So what is data architecture and how does it relate to data management?

To better understand the role of data architecture, I like to start with a description of data management. [Note that I did not say definition of data management as that would open up a whole separate discussion]

Taking a cue from DMBOK, data management rests or cuts across a number of  pillars, components or, in DMBOK-speak, functions, as shown in the figure below.

DAMA view of Data Management vs Operations

Data management is, in turn, supported by a number of data operations [what DMBOK classifies as Data Development]. The jury is still out on whether data classification and data analysis must be “promoted” to data management or whether data migration must be “demoted” to data operations.

Taken together, data management and data operations, plan, control, support and operate on data throughout its life-cycle, from data creation through to data disposal [DMBOK classifies this as Database Operations and then again restricts that to “structured” data when in fact it also applies to “unstructured” data].

That as it may be, I would like to argue that data architecture is not one of the pillars upon which data management rests.

And here’s why.

Paraphrasing the TOGAF definition of architecture, data architecture is about defining the form and function of these components, their inter-relationship, the principles and guidelines that govern their design, implementation, use and evolution over time.

From this definition it is clear that data architecture must “precede” or “hover above or below [take your pick]” or “underlay” data management and data operations. Using this paradigm, it is easy to imagine that data architecture, data management and data operations are to data what corporate strategy, tactics and operations are to corporations. It is not really about “who is top dog” or “who wags the dog” as the layers are intertwined and each influences the other – but are nonetheless distinct.

To use a different analogy, consider the design of a car. Design is not a single component you can isolate from a car. A good design is one that integrates the car’s components into a coherent whole.

So it is with data architecture and architecture in general.  You can “see” architecture, not in or of itself, but in how all the other components that make up data management and data operations are put to work together.

Of course you can point, beyond the whole, to a specific component such as the bonnet (hood) or tail lights of a car and comment on its individual design. And that is the beauty of design and architecture. Like a Russian Doll or Faberge Egg, architecture and design can occur at every level of detail – something that also seems to escape traditional adherents to the SDLC methodology.

A subject for another day.

This post was originally published by data architect, Bowie Muyutu on LinkedIn
Image sourced from https://commons.wikimedia.org/wiki/File:Matryoshka_transparent.png