In a recent thought-provoking LinkedIn post, data architect Bowie Muyutu raised a fundamental question that has sparked discussions within the data management community: Is data architecture a function of data management, or is it the other way around?

This question can be extended to other data management disciplines as well. For instance, is data quality merely a function of master data management, or does it hold a more complex relationship with it?

The Complexity of the Data Management Paradigm

Bowie’s question highlights the intricate nature of the data management paradigm. Whether we agree with his hypothesis or not, it undeniably brings to the surface some intriguing points. Let’s explore Bowie’s post to delve deeper into this subject.

Unveiling the Relationship Between Data Architecture and Data Management

Some might perceive this discussion as a mere ‘who is top dog’ debate, akin to the age-old question of whether tactics precede strategy. However, leaving this matter unresolved in enterprise architecture, particularly data architecture, can lead to childlike spats among professionals, each trying to claim their rightful space.

The issue surfaces across the entire IT community, from project managers with a limited understanding of architecture’s role on a project to agile developers who might consider architecture merely a technical debt to be repaid later. Even business architects and analysts sometimes struggle to differentiate between architecture, design, and requirements, questioning the necessity of an additional ‘design/requirements’ layer and its sequence in the process.

DAMA’s DMBOK Classification and Its Implications

One of the underlying challenges lies in the way DAMA’s Data Management Body of Knowledge (DMBOK) classifies data management functions. For instance, some have attempted to pigeonhole data architecture based on the DMBOK classifications. However, such an approach can inadvertently empower detractors or “reductionists” of data architecture.

In Bowie’s experience, he encountered instances where the DMBOK was used to limit data architecture’s scope, leading to misunderstandings. Some project managers argued that data architecture should be confined to specific data management functions, while business analysts believed it should exclude others entirely. This highlights the need for a more comprehensive understanding of the role of data architecture.

 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.

Bowie Myutu

Data Architecture: A Supporting Function

To shed light on the relationship between data architecture and data management, it’s essential to start with a description of data management. Data management encompasses various pillars or functions, as depicted in the figure below (based on DMBOK).

• Data Governance
• Data Quality
• Data Integration
• Data Warehousing and Business Intelligence
• Master Data Management
• Data Security Management
• Reference and Master Data Management
• Document and Content Management
• Meta-data Management
• Data Development (Data Modeling, Data Design, etc.)
• Data Operations (Database Operations)

Data management functions are supported by data operations, which include activities like data modeling, data design, and data development. The debate remains whether functions like data classification and data analysis should be elevated to data management status or downgraded to data operations.

The Role of Data Architecture

In light of the above, data architecture is not one of the core pillars on which data management rests. Instead, it acts as a crucial supporting function. Paraphrasing the definition of architecture from The Open Group Architecture Framework (TOGAF), data architecture defines the form and function of the components involved, their inter-relationships, and the principles and guidelines governing their design, implementation, use, and evolution over time.

This definition clarifies that data architecture should be positioned above or below data management, guiding its principles and ensuring coherence across all data management functions. In a way, data architecture, data management, and data operations are interconnected layers that influence each other while remaining distinct. This is illustrated in our enhanced data management framework below:

An apt analogy is the design of a car, where the individual components integrate seamlessly to form a coherent whole. Similarly, data architecture must oversee how all data management functions and data operations work together in harmony.  

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.

Bowie Myutu

Conclusion

In conclusion, it’s crucial to rethink the classification of DAMA’s data management functions and their relationship with data architecture. Data architecture should be regarded as a pivotal supporting function, ensuring coherence and harmonization across all data management disciplines. 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. By acknowledging the interconnectedness of these components, organizations can optimize their data management strategies and drive greater value from their enterprise information assets.