On using the DMBOK vocabulary
At one point I was a consultant at a client as an ETL developer. This particular client amazed me with how difficult it was to work with their data. Business definitions and data architecture was unclear. Their data was of low quality and all over the place. I wanted to get a grip on how to organize and manage data and the practices in the field. A dear colleague pointed me to the big blue book: DAMA DMBOK1.
It’s big, it’s crude in some areas, it’s blue. It took me several attempts to get through it. The DMBOK — to me — is a formalization of domain knowledge shared by thousands of data professionals. No individual section is new or unique, but to bundle it together as Data Management and to define a common vocabulary is what makes it significant.
We all know that on the business side of things, it’s most difficult to agree upon a vocabulary. Such as what do we consider a customer or what do we mean with governing data. After defining that, we can be productive. In my work I use the DMBOK not because it’s always the best way to go at things, but the DMBOK vocabulary helps me get a common ground quickly and get to the important things.
John Ladley is a great writer and thinker, and thus will not always agree with big blue. Ladley recognizes, however, that it’s more productive to contribute to the field of knowledge rather than to take the book into the boxing ring. Ladley’s Data Governance 2nd edition on page 18:
Today is the day that we talk the DMBOK’s dialect of data language. It’s imperfect, but it’s the best we have. Let’s be real, it’s perfectly usable and a great resource in our work.
Some people have a strong adversity to conformity. As soon as a definition or a framework comes near them, they retch “but it’s not aligning with the real world!” No, not really but rarely anything does. I let them go at their big blue windmills while we get ahead.