Many years ago, I contributed material on Database Development and Database Operations Management to the first edition of DAMA International’s “Data Management Body of Knowledge” (the DAMA DMBoK).i Now that work has begun on the Third Edition of the DMBoK, I’d like to share a few thoughts and critiques on the DMBoK for consideration. Some of these ideas arose out of a discussion on LinkedIn, which started when Malcolm Hawker posted a photo of himself holding the DMBoK, with the caption: “Relationship Status…It’s Complicated!”ii This post generated a number of comments about the DMBOK, many of them less than complementary, to which I contributed a few ideas of my own. Here they are:
First, when I look at the DMBoK, I see a whole lot of trees, but no forest. The DMBoK is crammed full of minutiae about every aspect of data management and data governance, but there’s no serviceable explanation, no context, about why any of this is important, or what value it contributes to an organization. The stated goal is to create better data for organizations. But, as Malcolm Hawker himself put it, “better data is not a business outcome.” The reality is that data is only useful or valuable to the extent that it empowers organizations to achieve their goals. In order to accomplish this, data must be turned into streams of content-laden information (“virtual value streams”), which then contribute to the creation of knowledge and expertise (aka “know-how”), and from there into value-producing action. Just as data has no intrinsic meaning without context (i.e., metadata), the DMBoK needs context around how organizations actually create business value, and how the proper management and governance of data contributes to this process.
A related point is that the DMBoK focuses on Data at Rest, rather than Data in Motion. As I said above, data only has value when it is in motion, fueling streams of information that create knowledge and empower action. Any satisfactory explanation of how data creates business value must focus on data in motion, not data at rest. But most of the DMBoK focuses on the creation of data artifacts: data warehouses, master data management catalogs, metadata catalogs, data governance structures, etc. The DMBOK reminds me of various horticulture books I’ve read that explain how to create a perfectly manicured English garden, but don’t explain why anybody should want one. Why create a garden if all you’re going to do is work in it?
The sense one gets in reading the DMBoK is that once you’ve created all the data artifacts and the organizational data governance structure, your work is done. You have, theoretically, perfect organizational data, so everybody can go home now, right? But the end of the DMBoK is only the beginning of the actual process of generating business value from all that perfect data, and the DMBoK doesn’t talk about any of this at all.
In the book I’m currently writing, I make the point that data cannot be considered a business asset, but that the process of data management (i.e., the process of turning data into Information, and then into knowledge, and then into action) can be.iii In other words, our focus should not be on data as an artifact, but on data management as a process. In fact, I’ve gone so far as to say that we should stop talking about data management and data governance entirely and focus our attention on the process of knowledge management (ala Thomas Davenport), because that’s where the actual business value lies. The DMBoK tells us how to create data artifacts, but doesn’t explain how to get value from the data management process!
There are other aspects of the DMBoK that also need review and consideration: One is that the DMBoK reproduces large amounts of information that are easily obtainable elsewhere. For example, there’s an entire section on how to do logical data modeling, a subject that is explained thoroughly in several excellent reference books. Just read anything written by Steve Hoberman, David Hay, Len Silverston, et. al. The DMBoK should just summarize the important points and then direct the reader to additional sources of information. And again, the DMBoK explains how to do things like logical data modeling without explaining why they are useful or important (I explain the business value of logical data modeling at great length in my book “Data Model Storytelling”).iv
A number of people have expressed the opinion that a lot of the material in the DMBoK is either out-of-date, or not current best practices in organizations. Because the DMBoK is a printed book, it takes years to bring out a new Edition, at which point a lot of the material is already obsolete (for example, the current DMBoK doesn’t mention anything about data engineering or AI). Perhaps, instead of a book, the DMBoK should be something like a Wiki, managed in the same way as Wikipedia? This would enable a larger group of industry experts to contribute more up-to-date material.
People like Malcolm Hawker have made the point that there is now a wealth of data (and we want to be data-driven, right?) to indicate that many of the “best practices” outlined in the DMBoK simply don’t work very well. As Hawker puts it, “In business we know how important adaptability and innovation are, and the DMBoK needs more of both.”
Finally, I’d like to see the People, Behavioral, and Cultural aspects of data management and data governance covered more thoroughly in the DMBoK. I talk about this at great length in my book “Data Model Storytelling,” covering aspects such as Design Theory, Behavioral Psychology, and Human-Centered Design.
In “Data Model Storytelling,” I group my recommendations into four general areas: People, Business, Technology, and Data. I think these would be useful categories for the DMBoK as well. These are all critical aspects of any data – or business — strategy. For example, people talk about data products and how to create them. But data products themselves don’t create business value. For that, you need data marketplaces, where people can quickly and easily find data they need, and are incentivized to share data they have. Organizational culture needs to incentivize this “marketplace behavior”!v
I’d be interested in hearing your comments on this. What do you think should be added or changed in the DMBoK for the third edition? I’ll put a link to this article on my LinkedIn home page, and you can comment there or DM me. Thanks!
i Incidentally, most of that material, but not all of it, was removed in the Second Edition, but I received no credit or acknowledgement for the material that was retained.
ii I’ve reposted Malcolm Hawker’s original post to my LinkedIn home page at https://www.linkedin.com/posts/larryburnsdba_cdo-datamanagement-datagovernance-activity-7325217448616480771-UumE?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAJbrQ8Blgezvz0nLuzyO1vG29jUyWQsK3c
iii I make the additional point that, in all aspects of Asset Management, what’s actually being managed is not the asset itself, but the behavior of people with regard to the asset. In Accounting, for example, we don’t actually manage money; we manage how people spend money and then report that spending. We don’t manage Inventory; rather, we manage how people add and remove stuff.
iv Burns, Larry. Data Model Storytelling (Technics Publications LLC, 2021), Chapters 1 and 2.
v See, for example, Thomas Davenport’s book Working Knowledge (Harvard Business School Press, 1998, 2000), Chapter 2.
