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

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.

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

8 thoughts on “Time to rethink the classification of DAMA’s data management functions?”

I would say that Data architecture is about structure and Data Management is, well, about management (a multi-disciplinary set op ongoing actions). I would agree with DMBOK that Data Architecture is one of the supporting disciplines or structures needed to be in control of (or manage) data. These are nog subfunctions of each other, but complementary parts.

The same discussion is about Data Management vs. Data Goverance. Is DM a function of DG, or vice versa.To go a bit further, perhaps Metadata Management is the ‘mother of’ Data Management: once metadata is properly managed, data management becomes very easy. Unless one assumes that metadata is just a subset of all data, and is thus only a part of Data Management in general.

Thank you for your comment. I would, personally, agree that Data Architecture is a supporting function. However, what the article highlights is the complexity of trying to deliver solutions in any one of the pillars with out thinking about the others

Strong agreement, the individual parts of DMBOK together provide complete coverage. The overall effectiveness of data management is strongly dependent on the weakest (of the most critical) pillars, and some of them (data governance, data archtecture, metadata management) have integrating functions that span the entire DMBOK wheel.

I nearly responded to your first comment – without reading through the thread – lesson learnt.

I am glad we agree that some of the DMBOK functions cannot be performed in isolation.

However, from your first comment, in reducing data architecture to ‘structure’ many will read that as data models or more precisely data entity models. If that is true then where does that leave data modelling as understood currently? Should we start calling data modellers data architects?

I would like to proffer that in as much as, say, you can have a master data architect, who must not confine himself to ‘structure’ but to the entire MDM solution from how the data hubs will be integrated to source and consumer systems and deal with ETL fallouts, a data architect must move beyond being simply concerned with ‘structure’ and play a key role in how master data, data governance, data integration, data warehousing, business intelligence, analytics etc. work together to manage data in an enterprise.

I oversimplified by stating that data architecture (DA) is only structure, to show the contrast with data management. While I believe that data modelling is the foundation of DA, DA does indeed go much further. It covers the entire data landscape: not just the logical data models, but also technical/physical models and metadata architecture. This includes (controlled) redundancy/replication, integration, archiving and data flows i.e. both ‘data at rest’ AND ‘data in motion’.

Interesting that you mention ‘data in motion’ because I always recommend the book ‘Managing Data in Motion’ by April Reeve as a primer to Data Architecture rather than DAMA’s DMBOK. It is well written and covers all the pertinent issues – except modelling data at rest – that a data architect should concern themselves with.
The icing on the cake for me is that the author does not dwell on “architecture” as a separate topic the way DAMA would like us believe. However, in fusing all the topics together, you get an overwhelming sense that this requires planning at both a global and detailed level and that encapsulates data architecture for me.