DAMA-DMBOK (Data Management Body of Knowledge): DAMA-DMBOK – Tutorial (about 60 minutes)

The DAMA-DMBOK, the Data Management Body of Knowledge, is a reference guide published by DAMA International that describes what it takes to manage data as a valuable organisational asset, from governance and architecture to quality, security, integration and metadata. Data governance leads, chief data officers, data architects, data stewards, analysts and engineers use it as a shared vocabulary and as a map of the whole discipline. After this tutorial you will be able to explain how the guide is organised, use its main frameworks to plan and discuss data management work, recognise where its individual certification (CDMP) fits, and start a practical, prioritised data management programme in your own organisation.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current edition is the DAMA-DMBOK2 Revised Edition, owned by DAMA International and published by Technics Publications. It is a maintenance revision of the second edition (first released in 2017) that DAMA made available in 2024; it standardised terminology and acronyms, corrected errors in text and figures, reviewed the twelve knowledge-area context diagrams and strengthened the Data Quality chapter with an added appendix. DAMA states that the revised edition has been the reference for CDMP exam preparation since October 2024. A third edition is in progress: DAMA's DMBOK 3.0 project held its kick-off on 25 June 2025 and runs with specialty editors, a lead editor and peer reviewers; DAMA's own project page gives no publication date, and a 2027 target mentioned by secondary sources is not confirmed by DAMA. This course therefore teaches the DMBOK2 Revised Edition. Verified 2026-10-29 against dama.org (DMBOK page, revised-edition FAQ and DMBOK 3.0 project page) and cdmp.info.

Who it is for: people who are new to structured data management: software and data engineers who keep fixing the same data problems, business analysts and report owners who need trustworthy numbers, quality, risk, privacy and compliance staff who depend on well-controlled data, project managers starting a data platform or master data project, and anyone preparing to study for the CDMP.

Prerequisites: none. A rough idea of what a database, a report and a business process are is enough.

How to use this tutorial: read the seven lessons in order (about 45 minutes), study the five diagrams, then use the remaining time for the reflection questions before you take the 25-question knowledge check.

Learning objectives:

You will be able to explain what the DMBOK is, who maintains it, what it is not (a law, a certifiable management system standard or a product list) and what its current edition is.
You will be able to define core data management vocabulary such as data governance, stewardship, metadata, reference data, master data and data quality dimensions.
You will be able to describe the DAMA Wheel, the Environmental Factors Hexagon and the knowledge-area context diagram, and use them to scope a piece of work.
You will be able to outline how an organisation turns the guide into a practical programme: strategy, governance operating model, priorities, roles and metrics.
You will be able to explain how capability is assessed with maturity assessments and how individuals are certified through the CDMP.
You will be able to apply the knowledge areas to a realistic scenario and spot common mistakes.
You will be able to relate the DMBOK to neighbouring frameworks such as the DMM, DCAM, ISO 8000, ISO/IEC 38505 and ISO/IEC 27001.

Lesson 1 – Origins, purpose and scope

Why a body of knowledge for data?

Every organisation runs on data, yet for decades data was treated as a by-product of applications. Each system had its own customer list, its own product codes and its own idea of what a "sale" was. Problems showed up late and expensively: reports that disagreed, mailings sent to the wrong address, regulators asking questions nobody could answer quickly, analytics projects that spent most of their time cleaning inputs. The people who fixed these problems learned the same lessons again and again in different companies, but there was no common description of the discipline, no shared words and no agreed outline of what "good" looks like.

Older professions solved this by writing a body of knowledge: a structured summary of the generally accepted practices of a field. Project management has the PMBOK Guide, business analysis has the BABOK Guide. DAMA International, a not-for-profit, vendor-independent association of data management professionals with chapters around the world, did the same for data. Its body of knowledge collects what experienced practitioners agree on, names the parts of the discipline and shows how they depend on each other.

A short history

The first edition of the DAMA-DMBOK Guide appeared in 2009. The second edition, usually written DMBOK2, followed in 2017 after a large rewrite with contributions from many practitioners. It expanded coverage of data handling ethics, refreshed the governance material, added a chapter on big data and data science, and introduced new chapters on maturity assessment, organisation and roles, and organisational change management. In 2024 DAMA released the DMBOK2 Revised Edition. It does not restructure the guide; it cleans it up, with consistent terminology, corrected figures, reviewed context diagrams and a stronger Data Quality chapter. Work on a third edition started in 2025 as a community project, with the stated aim of modernising the framework and adding topics such as AI, cloud and modern data platforms. Until it is published, the revised second edition is the version to learn.

Purpose

The guide has several purposes that are worth keeping apart:

It gives the profession a common vocabulary, so that a data steward in a bank and a data architect in a hospital mean the same thing by "reference data" or "data lineage".
It describes the scope of data management: the knowledge areas, their goals, their typical activities and how they connect.
It offers frameworks for thinking about the discipline as a whole, so that leaders can see gaps and dependencies rather than isolated projects.
It serves as the reference for the CDMP, DAMA's certification for individual professionals.
It records generally accepted practices without telling you which tools to buy.

What it is not

Beginners often expect the guide to behave like a standard such as ISO 9001. It does not. It contains no "shall" requirements, no audit criteria and no certificate for organisations. Nobody can certify a company as "DMBOK compliant". It is not a step-by-step method either: it tells you what the parts of data management are and what good practice in each looks like, but you must decide what to do first, how far to go and how to adapt it to your size, sector and regulators. It is also vendor-neutral, which is one of its strengths: the same concepts apply whether your data sits in a mainframe, a cloud warehouse or a set of spreadsheets.

Scope

The scope is broad on purpose. The guide covers the whole lifecycle of data from planning and design through creation, storage, use, sharing and archiving to disposal, and it covers structured data in databases as well as documents and content. It addresses people and organisation as much as technology, because most data problems are caused by unclear responsibilities and conflicting incentives rather than by software.

Lesson 2 – Key concepts and vocabulary

The DMBOK has a large glossary. You do not need all of it, but the following terms appear everywhere, and the rest of this course uses them precisely. The definitions are paraphrased.

Data management – the planning, carrying out and oversight of the policies, programmes and practices that deliver, control, protect and increase the value of data across its whole lifecycle.
Data governance – the exercise of authority and shared decision-making over how data is managed: who decides, by what rules, and how compliance is monitored. Governance does not do the day-to-day data work; it makes sure the work is done properly.
Data stewardship – the accountability for, and day-to-day care of, data assets on behalf of the organisation. Stewards define terms, set quality rules, resolve issues and advise on use.
Data steward – a person with formal stewardship responsibilities. The guide distinguishes several kinds, such as executive, enterprise, business, technical and coordinating stewards.
Knowledge area – one of the functional parts of data management described in its own chapter, such as Data Quality or Metadata.
Data asset – data recognised as having value to the organisation, and therefore worth managing deliberately like money, people or equipment.
Data lifecycle – the stages data passes through: plan, design, create or acquire, store and maintain, use, enhance, and finally archive or dispose of.
Metadata – data that describes other data. The guide groups it as business metadata (definitions, owners, rules), technical metadata (tables, columns, data types, lineage) and operational metadata (job runs, volumes, errors, access logs).
Data lineage – a description of where data came from and what happened to it on the way to a report or application.
Reference data – sets of permitted values used to classify other data, such as country codes, currency codes or a list of policy statuses. It changes slowly and is often shared across many systems.
Master data – data about the core business entities that many processes share, such as customers, suppliers, products, employees and locations.
Data quality – the degree to which data is fit for the purposes it is used for. Quality is measured along dimensions such as completeness, validity, accuracy, consistency, timeliness and uniqueness.
Business glossary – an approved list of business terms with their definitions, owners and related rules; it is a key piece of business metadata.
Data architecture – the blueprints that describe the organisation's data assets, how data flows between systems and how data structures support business strategy.
Data model – a precise description of data requirements at conceptual, logical or physical level.
Data handling ethics – principles for using data in ways that are fair, transparent and respectful of the people the data describes, beyond what the law requires.
Chief Data Officer (CDO) – a senior leader accountable for the organisation's data strategy and data management programme.

Governance versus management

The most important distinction in the whole guide is between governance and management. A useful analogy, which the guide itself draws, is finance: accountants manage the money day to day, while auditors and the board check that it is managed according to the rules. In the same way, data governance sets direction, approves policies and standards, resolves disputes and monitors compliance, while data management functions such as architecture, quality and integration do the work. Mixing the two leads to familiar failures: a governance council that tries to design tables, or an IT team that silently decides what "active customer" means for the whole company.

Data as an asset with unusual properties

The guide's opening chapter explains that data behaves differently from physical assets. It is not used up when you use it; it can be copied cheaply, so it multiplies into many inconsistent versions; its value depends on its quality and on whether people understand it; and the risk it carries (privacy, security, legal) grows with every copy. These properties explain why data needs deliberate management: without it, copies drift apart, meaning is lost and risk accumulates unseen. The chapter turns them into principles, for example that managing data means managing its quality, that metadata is needed to manage data, that data management needs planning and an enterprise perspective, and that it requires leadership commitment.

Lesson 3 – Structure of the guide and its frameworks

The chapters

The revised second edition has seventeen chapters. Reading them as groups makes the book far easier to navigate:

Foundations (chapters 1–2): Data Management, which introduces principles and frameworks, and Data Handling Ethics.
Knowledge areas (chapters 3–14): Data Governance; Data Architecture; Data Modeling and Design; Data Storage and Operations; Data Security; Data Integration and Interoperability; Document and Content Management; Reference and Master Data; Data Warehousing and Business Intelligence; Metadata Management; Data Quality; and Big Data and Data Science.
Making it work in an organisation (chapters 15–17): Data Management Maturity Assessment; Data Management Organization and Role Expectations; and Data Management and Organizational Change Management.

The DAMA Wheel

The best-known picture from the guide is the DAMA Wheel, also called the DAMA-DMBOK Framework. It shows eleven knowledge areas: Data Governance at the hub, with the other ten arranged as segments of a circle around it. The message is simple: governance is not just one more segment alongside the others, it is the hub that gives every other area direction, decision rights and oversight. The wheel also shows that the areas are equals in the sense that a mature organisation needs all of them; it does not say they are equally urgent for you right now. Big Data and Data Science has its own chapter and context diagram but is not one of the wheel's segments; it builds on the other areas rather than replacing any of them.

A short orientation to each area helps:

Data Governance sets strategy, policies, standards, decision rights, stewardship and issue management.
Data Architecture defines the target picture of data assets and flows and aligns it with business strategy.
Data Modeling and Design captures data requirements in conceptual, logical and physical models.
Data Storage and Operations runs databases and storage: availability, backup, recovery, performance and retention.
Data Security protects data according to policy and regulation, covering access, authentication, authorisation, entitlement and audit.
Data Integration and Interoperability moves and combines data between systems, for example through batch extract-transform-load jobs, change data capture, messages or APIs.
Document and Content Management handles unstructured information such as documents, records, e-mails and web content, including retention and legal holds.
Reference and Master Data manages shared code lists and core entities so that every system uses consistent, trusted versions.
Data Warehousing and Business Intelligence provides integrated data for reporting and analysis; the guide discusses both the Inmon and the Kimball styles of warehouse design.
Metadata Management collects, integrates and publishes descriptions of data, including glossaries, catalogues and lineage.
Data Quality defines quality requirements, measures data against them, finds root causes and drives improvement.

The Environmental Factors Hexagon

The wheel answers "what are the parts?". The Environmental Factors Hexagon answers "what must be in place for any one part to work?". At its centre are the goals and principles of the area. Around them sit six factors, which can be read as people, process and technology: roles and responsibilities, and organisation and culture (people); activities and deliverables (process); and practices and techniques, and tools or technology (technology). The guide uses the same factors in every knowledge-area chapter, so once you understand them you can read any chapter with the same mental checklist.

The practical lesson is that a gap in any factor can sink an initiative. A brilliant data quality tool fails if no one has the role of acting on its alerts; a clear policy fails if the culture rewards speed over accuracy; well-defined activities fail if they produce no tangible deliverable that others can use.

The knowledge-area context diagram

Each of the twelve knowledge-area chapters (3–14, including Big Data and Data Science) opens with a context diagram. These diagrams were reviewed and improved in the 2024 revision. A context diagram is a one-page summary built like a process description. It names the definition and goals of the area, the business drivers behind it, the inputs it needs and who supplies them, the activities it performs, the deliverables it produces, the participants who do the work and the consumers who use the results. It also lists the technical drivers: techniques, tools and metrics.

Activities in a context diagram are tagged with one of four letters that tell you their nature: P for planning (setting direction, for example writing a data quality strategy), D for development (building something, such as designing a new data model), O for operational (running and supporting things day to day, such as monitoring jobs) and C for control (checking and enforcing, such as auditing access or measuring compliance with a standard). The tags help you plan staffing: development work is often project-based, while operational and control work needs permanent owners.

Figure 3 – The structure of a knowledge-area context diagram: suppliers provide inputs, participants use techniques and tools to perform activities, deliverables go to consumers, and metrics show whether the goals are met.

Other models in the opening chapter

Chapter 1 also explains a few general models that help leaders position data management. The Strategic Alignment Model, from Henderson and Venkatraman, shows the need to align business strategy, IT strategy, organisational infrastructure and technical infrastructure, with data as part of that alignment. The Amsterdam Information Model adds an explicit layer for information management between business and technology. The chapter also presents later views of the framework, such as a pyramid attributed to Peter Aiken, which makes the point that advanced uses such as analytics and master data depend on foundations such as sound storage, models, security, quality and metadata, and a grouping of the areas into governance, lifecycle management and foundational activities. You do not need to memorise these figures; the point is that the areas depend on each other and must be planned together.

Lesson 4 – How it works in practice

Start from business drivers

The guide is a reference, not a project plan, so the first practical skill is choosing what to do. The right starting point is a business driver: a regulatory deadline, a costly operational failure, a merger, a planned analytics or AI initiative, or a customer experience problem. A driver gives you sponsorship, a budget and a way to measure success. Trying to "implement the DMBOK" in general, all areas at once, is one of the most common reasons programmes stall.

A data management strategy

The guide recommends a data management strategy that links data work to business goals. Typical contents are a vision, a short business case, guiding principles, the scope of the programme, the priority knowledge areas and data domains, a roadmap of initiatives, measures of success, and the governance arrangements that will oversee delivery. The strategy is a living document: it is reviewed as priorities and capabilities change.

A governance operating model

Governance needs structure. The guide describes operating models that range from centralised, where one data governance organisation owns all decisions, through replicated, where each business unit runs its own similar model, to federated, where a central body sets common policies while business units govern their own data within them. Many large organisations end up with some form of federated model. Common bodies are a steering committee or data governance council of senior leaders who approve policy and settle disputes, a data governance office that coordinates the programme, and stewardship teams organised by data domain, such as customer, product or finance data.

Roles

Clear roles are the heart of the people side. Typical roles are:

a chief data officer or equivalent executive who owns the strategy and the programme;
executive data stewards, senior leaders who sit on the council and represent their area's interests;
business data stewards, subject-matter experts who define terms and rules for a data domain and decide on quality issues within it;
technical data stewards, people in IT who know how the data is stored and processed and implement the rules;
coordinating data stewards, who lead stewardship teams and bring issues between domains together;
data owners, where an organisation uses that term, who are accountable for decisions about a data domain;
specialists such as data architects, modellers, database administrators, integration developers, data quality analysts and metadata specialists.

A useful rule of thumb is that the business decides what data means and how good it must be, while IT decides how to store, move and protect it to meet those needs. Stewards bridge the two.

Policies, standards and issue management

Governance turns principles into policies (short statements of intent, such as "every critical data element has an accountable steward") and standards (more detailed rules, such as naming conventions or quality thresholds). It also needs an issue management process: a way to log a data problem, route it to the right steward, decide, fix and record the decision. Issue management is often the first visible success of a programme, because it ends the endless e-mail threads about who should fix what.

Typical artefacts

Across the knowledge areas you will see the same kinds of deliverables: a data strategy and roadmap; a governance charter; policies and standards; a business glossary; conceptual and logical data models; data flow and lineage diagrams; a data catalogue; data quality rules, scorecards and issue logs; security classifications and access rules; integration specifications; master data match and merge rules; retention schedules; and metrics dashboards. Each artefact should have an owner, a place where people can find it, and a review cycle.

Change management

Chapter 17 is easy to skip but matters a great deal. Data management changes how people work: someone who used to create customer records freely now follows a standard; a team that owned "its" report now accepts an enterprise definition. The guide therefore applies organisational change management, drawing on well-known change models such as Kotter's, to explain the need for a sense of urgency, a guiding coalition, a clear vision, quick wins and embedding new habits. Communication and training plans belong in every data management roadmap.

An implementation cycle

Putting these pieces together gives a repeatable cycle. Figure 4 shows a practical version used by many programmes.

Figure 4 – A practical DMBOK-based programme cycle: drivers and assessment lead to priorities, governance and a focused initiative, whose measured results feed the next round.

The data quality improvement cycle

Within the Data Quality chapter the guide uses the familiar plan-do-check-act cycle. In the plan stage you assess the scope and root causes of quality problems and decide what to fix; in the do stage you fix the root causes and correct the data that matters; in the check stage you monitor data against the agreed quality rules and thresholds; in the act stage you respond to issues and adjust the rules or processes. The emphasis on root causes is deliberate. Cleaning data downstream, again and again, is expensive; changing the process or system that creates bad data is usually much cheaper over time.

Quality expectations should come from use. A field that must be perfect for regulatory reporting may only need to be roughly right for a marketing campaign. The guide therefore expects quality rules and thresholds to be agreed with the data consumers, not set by technicians alone, and it discusses several published sets of quality dimensions; a widely used short list is completeness, uniqueness, timeliness, validity, accuracy and consistency.

Lesson 5 – Assessment, certification and compliance

No organisational certification

Because the DMBOK contains no requirements, there is no certificate for an organisation. A consultant who offers to "certify your company against DMBOK" is offering their own opinion, not a recognised scheme. If you need an external, certifiable framework, you will look elsewhere: for example ISO/IEC 27001 for information security management, or sector rules from your regulator. The DMBOK is still very useful in those contexts, because it explains the data capabilities you will need to satisfy them.

Maturity assessment

What organisations can do is assess their own data management capability. Chapter 15 explains data management maturity assessment: you choose a model, decide the scope (the whole enterprise, a business unit or a few knowledge areas), gather evidence through interviews, document reviews and surveys, rate each area, and turn the gaps into an improvement plan. The chapter illustrates a generic scale running from level 0, no capability, through initial or ad hoc, repeatable, defined and managed, to optimised at level 5. It also describes established models that organisations use for formal assessments, such as the CMMI Institute's Data Management Maturity model and the EDM Council's DCAM, and it warns against treating a maturity score as a goal in itself.

Good practice for assessments is simple to state and hard to follow: assess against business priorities rather than chasing the highest level everywhere; use evidence, not opinion; involve both business and IT; repeat the assessment so you can show progress; and make sure every gap leads to a decision, even if the decision is to accept it.

The CDMP for individuals

DAMA's certification is for people, not organisations: the Certified Data Management Professional (CDMP). According to the CDMP site, every level requires the Data Management Fundamentals exam. Higher levels add two specialist exams, chosen from areas such as Data Governance, Data Quality, Metadata, Data Modelling and Design, Reference and Master Data, Data Integration and Interoperability, and Data Warehousing and Business Intelligence. The levels differ in the experience expected and the pass mark:

Level	Exams	Pass mark	Experience
Associate	Data Management Fundamentals	60 %	Guideline of six months to five years
Practitioner	Fundamentals plus two specialist exams	70 % in each	Guideline of two to ten years
Master	Fundamentals plus two specialist exams	80 % in each	At least ten years, with an evidence review

The CDMP site describes each exam as 100 multiple-choice questions in 90 minutes, with extra time available in a version for people taking it in a second language, and says that all CDMP exams test against the DMBOK2; DAMA recommends the DMBOK2 Revised Edition for preparation, and it has been the study reference since October 2024. Fees, recertification rules and the list of specialist exams can change, so check cdmp.info before you plan your study.

Compliance uses

Even without a certificate, the DMBOK supports compliance. Privacy laws such as the GDPR expect organisations to know what personal data they hold, why, where it flows and who can access it; that is metadata, lineage, security and governance work described in the guide. Financial supervisors expect accurate, traceable risk data; that is data quality, architecture and lineage. Records retention rules depend on document and content management. When auditors ask "how do you know?", the artefacts of a DMBOK-style programme, such as glossaries, lineage, quality scorecards, access reviews and issue logs, become your evidence.

Lesson 6 – Worked example: an insurer brings order to its policy and customer data

The situation

Northgate Mutual (a fictional company) is a mid-sized insurer with 2,000 staff, three policy administration systems inherited from earlier acquisitions, a claims system, a customer portal and a cloud data warehouse. The board has two concerns. First, the monthly count of active policies differs between finance, underwriting and the regulatory return, and nobody can explain the gap quickly. Second, the company wants to use machine learning for claims triage but the data science team says it spends most of its time cleaning data. A new chief data officer, Amira, is asked to fix both within eighteen months.

Step 1 – Business drivers and scope

Amira resists the temptation to launch eleven work streams. She writes down two drivers, regulatory reporting accuracy and readiness for analytics, and agrees with the executive team that the first scope is two data domains: policy and customer. She documents this in a short data management strategy with principles (for example, "one approved definition per critical term" and "fix quality at the source"), a roadmap and three measures of success.

Step 2 – Baseline assessment

Her team runs a light maturity assessment of the knowledge areas that matter for the two drivers: governance, metadata, data quality, reference and master data, and integration. Interviews and document reviews show that there is no glossary, quality checks exist only inside individual reports, policy status codes differ between the three administration systems, and customer records are duplicated across systems with no match rules. The team rates most of these areas at an ad hoc level, and records the evidence behind every rating.

Step 3 – Governance and roles

Amira sets up a federated model. A data governance council of executives from finance, underwriting, claims, risk and IT meets monthly to approve policies and settle disputes. A small data governance office coordinates. For the policy domain, the head of underwriting operations becomes executive steward, two senior underwriters become business data stewards and a lead developer from the policy systems team becomes technical steward. The customer domain gets the same structure. An issue log and an escalation route are published in the first month.

Step 4 – Meaning first: glossary and reference data

The stewards start with the term at the centre of the board's complaint. Finance counted a policy as active if premium was being collected, underwriting counted it from the date cover started, and the regulatory team excluded policies in a cooling-off period. After two workshops the council approves one definition of "active policy" and two clearly named variants for special uses, all recorded in a new business glossary with an owner and calculation rule. The stewards then build a single reference list of policy status values and a mapping from each source system's codes to it. This is reference data management in action, and it removes most of the reporting gap without any new technology.

Step 5 – Lineage and integration

Next, the technical stewards document lineage for the twenty critical data elements used in the regulatory return: which source fields feed them, which transformations apply and which reports use them. They load this metadata into a data catalogue so analysts can see it. The integration team changes the warehouse load jobs to apply the agreed status mapping centrally rather than in each report.

Step 6 – Data quality at the source

Following the plan-do-check-act cycle, the data quality analyst profiles the customer data and finds that about one in twelve records lacks a valid postcode and that many customers exist two or three times. The stewards agree quality rules and thresholds with the consumers: the regulatory team, claims and data science. Root cause analysis shows that the oldest policy system allows postcode to be skipped. Rather than cleaning the warehouse every month, the team asks for a validation change in that system's entry screen and a one-off correction of existing records. For duplicates, the master data team defines match rules and a survivorship approach, creating a single trusted customer record that downstream systems can reference.

Step 7 – Security and ethics

Because claims triage will use personal and health-related data, the security and privacy teams classify the data elements, restrict access by role, and log access to sensitive fields. The council also discusses data handling ethics: whether some fields could lead to unfair treatment of customers, and how the model's use will be explained. These decisions are recorded so that the data science team works within clear boundaries.

Step 8 – Measure, communicate, repeat

After a year, Northgate's three measures look like this: the active policy figures reconcile across finance, underwriting and the regulator; the customer data quality scorecard shows postcode completeness and duplicate rates within agreed thresholds; and data scientists report far less time spent on cleaning. A repeat assessment shows governance, metadata and quality moving from ad hoc to repeatable or defined for the two domains. Amira publishes the results, thanks the stewards by name, and the council chooses the next domain: claims data.

What the example teaches

Northgate did not implement the whole wheel. It used governance at the centre, picked the knowledge areas that served real drivers, solved meaning before technology, fixed causes rather than symptoms, and used metrics to prove value. Each knowledge area contributed a specific piece: governance gave decision rights, metadata gave definitions and lineage, reference and master data gave consistent codes and customers, integration applied the rules centrally, quality created measurable improvement, and security and ethics kept the analytics work safe.

Figure 5 – How Northgate's governance decisions flowed into glossary, reference data, lineage, quality and master data work to deliver its two business outcomes.

Lesson 7 – Relationship to other standards and frameworks

The DMBOK sits in a crowded landscape. Understanding its neighbours helps you combine them rather than argue about which one to pick. The key difference is the type of document: the DMBOK describes the knowledge of the discipline; maturity models measure capability; ISO management system standards set auditable requirements; and specialised standards go deep in one area.

Framework	Owner	What it is	How it relates to the DMBOK
DMM (Data Management Maturity Model)	CMMI Institute (part of ISACA since 2016)	A maturity model of data management practices with capability levels	Measures how capable an organisation is in areas the DMBOK describes; cited in the DMBOK's maturity assessment chapter
DCAM (Data Management Capability Assessment Model)	EDM Council	A capability framework and assessment model, widely used in financial services	Overlapping scope with a stronger assessment focus; many programmes use DCAM to score and the DMBOK to explain
ISO 8000 series	ISO	International standards for data quality and master data exchange	Goes deeper than the Data Quality and Master Data chapters, with formal requirements
ISO/IEC 38505-1	ISO/IEC	Guidance on how a governing body oversees the use of data	Board-level view of data governance; complements the DMBOK's operational governance material
ISO/IEC 27001	ISO/IEC	Certifiable information security management system standard	Provides the auditable security framework; the Data Security chapter explains the data-specific practices that support it
COBIT	ISACA	Framework for governance and management of enterprise information and technology	Broader IT governance; the DMBOK supplies the detailed data management content

Two further neighbours deserve a mention. Privacy laws such as the GDPR set legal duties that data governance, metadata and security work help you meet. And the body-of-knowledge family, the PMBOK Guide for projects and the BABOK Guide for business analysis, follows the same idea of describing a profession rather than prescribing a method; data programmes often use all three together.

A sensible combination for many organisations is: the DMBOK as the shared language and scope, a maturity model such as DCAM for formal scoring, ISO/IEC 27001 for certified security, ISO 8000 where data exchange quality must be contractually specified, and the organisation's legal and regulatory obligations as the top-level drivers.

Common pitfalls and best practices

Pitfalls

Trying to implement everything at once. Treating the wheel as a to-do list spreads effort thinly and delivers nothing visible; sponsors lose patience.
Treating data governance as an IT project. If only IT attends, business definitions and quality thresholds are guessed, and the business does not feel ownership.
Buying a tool before defining roles and rules. A catalogue or quality tool with no stewards to act on it becomes an expensive, outdated inventory.
Cleaning data downstream forever. Fixing the warehouse each month while the source keeps producing errors wastes money and hides the real cause.
Confusing the guide with a standard. Promising auditors or clients "DMBOK compliance" creates expectations that no certificate can meet.
Chasing maturity scores. Aiming for the top level in every area ignores business value and burns budget on low-priority capability.
Ignoring culture and change. New policies without communication, training and incentives are quietly bypassed.

Best practices

Anchor every initiative in a business driver and define two or three measurable outcomes before starting.
Start with a few critical data domains and data elements, prove value, then expand.
Give the business clear decision rights over meaning and quality, with named stewards and an escalation path.
Use the Environmental Factors Hexagon as a checklist for each initiative: goals, roles, culture, activities, deliverables, techniques and tools.
Fix root causes at the point of creation and monitor quality against thresholds agreed with consumers.
Make metadata visible: publish the glossary, catalogue and lineage where people actually work.
Plan change management from day one: communication, training, quick wins and recognition for stewards.
Reassess periodically and adjust the roadmap to what the business needs next.

Summary and key takeaways

The DAMA-DMBOK is a vendor-neutral body of knowledge, not a certifiable standard; the current edition is the DMBOK2 Revised Edition (2024), and DMBOK 3.0 is in development without a confirmed date.
Its seventeen chapters cover foundations and ethics, twelve knowledge-area chapters, and the organisational topics of maturity, roles and change management.
The DAMA Wheel places Data Governance at the centre of the other knowledge areas: governance directs and oversees, management functions do the work.
The Environmental Factors Hexagon and the context diagrams give a consistent way to describe and plan any knowledge area.
Successful programmes start from business drivers, choose a few domains, set up a governance operating model with clear stewardship roles, and measure outcomes.
Data quality is fitness for purpose: agree thresholds with consumers and fix causes at the source using a plan-do-check-act cycle.
Organisations can assess their maturity but cannot be certified against the DMBOK; individuals can earn the CDMP.
The DMBOK works best combined with maturity models, ISO standards and legal requirements, each used for what it does well.

Reflection questions

Pick one recurring data problem in your organisation. Which knowledge areas does it touch, and which one would you address first, and why?
Who in your organisation currently decides what a key business term means? How would you turn that informal practice into a stewardship role with clear decision rights?
Choose one planned data initiative and run it through the Environmental Factors Hexagon. Which factor is weakest, and what would you do about it?
If a senior manager asked you to "make us DMBOK certified", how would you explain the situation and what would you propose instead?
For a data set you use, which quality dimensions matter most to its consumers, and what thresholds would you propose? How would you find the root cause if they were missed?