Listen to this article:
The Data Management Association (DAMA) first published its Data Management Body of Knowledge (DMBOK) in 2009. In it was the now-familiar DMBOK wheel diagram. It has undergone some minor revisions since then, but nearly two decades later, it remains the best-known framework for data management. If you haven’t seen it, here it is:
The DMBOK Wheel defines the specific disciplines required to handle, protect, and use data. The focus is on the “what.” Each organization figures out its own “how.” I’ve seen the DMBOK Wheel used dozens, maybe hundreds of times as the outline for corporate Information Management and Data Governance proposals. Slice One: Data Quality. This is what it means and this is how we propose to do it. Slice Two: Data Modeling. This is what it means and this is how we propose to do it. And so on, through all eleven slices.
The DMBOK Wheel is organized around activities and artifacts. This made sense because activities and artifacts were expensive and that’s where we needed to focus. Today, AI is disrupting all of Information Management and Data Governance, commoditizing activities and artifacts. Practitioners and thought leaders are already cataloging the use of AI in each of the eleven areas: what AI can do, can’t do, will do, won’t do, should do, and shouldn’t do.
Now, this doesn’t mean that the activities and artifacts disappear. The responsibilities actually become more important as AI lowers the cost of performing the underlying activities. What changes is where human expertise is required.
We need to rethink the DMBOK Wheel, what it contains, and how we use it…and who uses it.
Let’s face it. The DMBOK Wheel is intended for data professionals. A developer would probably never use it. Neither would a businessperson. And for goodness sake, please don’t take it to your executives. We lament that developers, businesspeople, and executives don’t understand or care about Information Management and Data Governance, but when this is our number one visualization we really shouldn’t be surprised.
So, what can we do to make the DMBOK Wheel relevant to those who aren’t data professionals?
In my previous article, I argued that accountability is the fundamental purpose of Information Management. If people and organizations are going to be accountable for decisions, they need to know what information those decisions depend on, what that information means, where it came from, how trustworthy it is, and what limitations it has.
That gives us a different way to look at the DMBOK Wheel.
Consider Data Quality. This wedge includes activities such as defining expected content, monitoring, profiling, cleansing, and exception handling. In this case, AI will automate almost all of it. So, instead of asking, “How does AI change Data Quality?” I propose a different question:
What is the purpose of Data Quality?
The function of Data Quality is to identify problems with data content and fix them. We can list the dimensions of Data Quality, whether you subscribe to the six, twenty, or one hundred and twenty dimension model. We can develop plans and metrics. We can implement inspection processes. None of that explains why Data Quality exists.
Data Quality exists to ensure that organizations can trust their data sufficiently to be accountable for the decisions made with it.
It characterizes the trustworthiness of data so that decision makers understand what conclusions they can accountably draw from it. What decisions can an organization responsibly make using this data, and with what level of confidence? The objective isn’t high quality data for its own sake, “trusted data,” or even “fit for purpose.” The objective is to be able to confidently stand behind your decisions. In other words:
Activities answer “how.” Capabilities answer “what.” Responsibilities answer “why.”
Each DMBOK wedge or knowledge area represents a responsibility that existed before AI and will continue to exist after AI. The responsibility exists whether the work is performed by a data engineer, a business analyst, an AI system, an automated process, or some combination of all of them. It remains necessary even when the technologies, processes, organizational structures, and methods change. The underlying responsibility is invariant.
If we stop looking at the DMBOK knowledge areas as collections of activities and instead ask what enduring responsibility each one serves, the picture changes.
Invariant Responsibility | DMBOK Knowledge Area |
Preserve what the organization needs to remember. | Document & Content Management |
Protect information while enabling legitimate use. | Data Security |
Document meaning, context, and provenance. | Metadata |
Represent the things the organization cares about and their relationships. | Data Modeling & Design |
Connect information across systems and contexts. | Data Integration & Interoperability |
Reveal meaning in information. | Data Warehousing & Business Intelligence |
Assure the reliability of information used for decisions. | Data Quality |
Sustain the availability, reliability, and resilience of information. | Data Storage & Operations |
Organize how information is created, managed, connected, and used across the enterprise. | Data Architecture |
Agree on what things are and what they mean. | Reference & Master Data |
Ensure accountability for the information and what happens with it. | Data Governance |
That same thought process I described earlier for Data Quality can be applied to the others. I won’t go through all of them in detail here. Furthermore, I don’t claim these are the final eleven responsibilities, or even that every responsibility maps neatly to a single DMBOK knowledge area. The point is the change in perspective.
In each case, we are transforming the organizing principle from activities to responsibilities.
Instead of focusing on producing artifacts, we are identifying the obligations an organization has with respect to its information. Organizations need to know what their information means, where it came from, whether it can be trusted, who can use it, and how it relates to other information because they are accountable for what they do with it. The particular activities used to accomplish these things may change. The responsibilities do not.
The question, then, isn’t whether we need Data Quality, Data Architecture, Metadata, Governance, or the other disciplines represented by the Wheel. We do. The question is whether those disciplines, and the activities and artifacts associated with them, are still the right way to explain why they matter.
Perhaps the future of Information Management isn’t defined by the things we do with data, but by the responsibilities.
Notice that the verbs describing the responsibilities are not all the same kind of verb, and they shouldn’t be. Some describe an information action (preserve, protect, document, model, connect, reveal), some describe a capability action (assure, sustain, organize), and some describe an organizational obligation (agree, ensure accountability). Not all eleven wedges represent the same conceptual kind of thing. The DMBOK Wheel organizes the Information Management profession around eleven domains of practice, but the organization itself doesn’t experience eleven domains. It experiences a smaller number of enduring obligations that don’t respect the boundaries of the wedges.
Next time I will develop this idea further, and propose a companion for the DMBOK Wheel that is organized around organizational obligations. I can hear you thinking already: Not another one. I don’t blame you. I’d be thinking the same thing. I do think the same thing. It seems that a new framework or visualization or infographic is introduced every couple of days.
I’m not suggesting that the DMBOK Wheel be abandoned entirely. Quite the opposite. It is extraordinarily valuable for data professionals and will continue to be the foundation of our profession. The problem is that we haven’t done a very good job explaining its value to anyone else, or at least not in a way that has been successful. We need to try something radically different. Perhaps this will be it. Stay tuned!
