DMM (Data Management Maturity Model): DMM – Tutorial (about 60 minutes)

The Data Management Maturity (DMM) Model is a reference model, created by the CMMI Institute, that describes the practices an organisation needs in order to manage its data as a business asset and arranges them along a path of increasing capability. Chief data officers, data governance leads, data architects, data quality analysts and process improvement teams use it to find out where their data management is weak, to agree priorities with the business and to measure progress. After this tutorial you will be able to explain how the model is organised, what each of its five capability levels means, how a DMM assessment works, and how to plan a realistic improvement programme with it, even though the model itself is no longer sold or supported by its owner.

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

Course overview

Edition and status: The only published edition is the Data Management Maturity (DMM) Model version 1.0, announced by the CMMI Institute in May 2014 and released in the summer (August) of 2014 after development with the Enterprise Data Management (EDM) Council and industry sponsors. The CMMI Institute became part of ISACA in 2016. The DMM has since been retired as a separate product: the former DMM pages on cmmiinstitute.com no longer exist, the Institute's current site lists only the CMMI domains, and industry commentators date the end of DMM training and new DMM certifications to around 2022. Organisations that licensed the model earlier may still use their copy. Selected DMM ideas live on inside the CMMI model: ISACA's April 2023 CMMI update added a Data Management domain, which secondary sources describe as including Data Management and Data Quality practice areas. There has never been a version 2.0 of the DMM. This course therefore teaches DMM 1.0 as a reference model that is still widely cited and used for self-assessment, and it tells you plainly where the official support has ended. Verified 2026-10-29 against the ISACA newsroom (6 April 2023 release), the CMMI Institute website and the secondary sources listed at the end.

Who it is for: data governance and data quality practitioners, data and enterprise architects, business intelligence and analytics leaders, risk and compliance staff who depend on trustworthy reporting, process improvement specialists who know CMMI and now face data problems, and students preparing for data management certifications that expect a working knowledge of maturity models.

Prerequisites: none. It helps if you have seen two departments argue about whose customer count is correct, because that kind of argument is exactly what the model was built to prevent.

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

Learning objectives:

You will be able to explain why the DMM was created, who built it and what its current status is.
You will be able to use its core vocabulary correctly, including process area, practice, work product, capability level, business glossary, metadata and data profiling.
You will be able to name the six categories and describe what the process areas in each category cover.
You will be able to describe what changes in an organisation as a process area climbs from Performed to Optimized.
You will be able to explain how a DMM assessment is prepared, run and turned into a roadmap, and what kind of credential it produced.
You will be able to apply the model in a realistic improvement programme and avoid the most common mistakes.
You will be able to relate the DMM to the CMMI Data domain, DCAM, DAMA-DMBOK, ISO 8000 and ISO/IEC 33000-series process assessment.

Lesson 1 – Origins, purpose and scope

Why data needed its own maturity model

Most organisations collect far more data than they manage. Customer records are created in a sales system, copied into a billing system, reshaped in a data warehouse, extracted into spreadsheets and finally summarised in a board report. At every step someone makes a small decision about meaning, format or quality, and nobody sees the whole chain. The symptoms are familiar: two reports that should agree do not, a regulator asks where a number came from and nobody can answer quickly, a data science project spends most of its budget cleaning inputs, and a migration to a new platform stalls because no one knows which of three address tables is authoritative.

By the late 2000s, many firms, especially in financial services after the 2008 crisis, had learned that these were not purely technical problems. Buying a better database or a new integration tool did not fix them, because the root causes were missing decisions and missing disciplines: who owns a data set, what a term means, how good is good enough, who approves a change, and how all of this is funded. Organisations needed a way to describe those disciplines, check how well they were performed, and plan improvements in a sensible order. Software engineering already had such a tool in the Capability Maturity Model Integration (CMMI), which describes good practice for development and services and lets organisations measure their process capability. The question was whether the same thinking could be applied to the management of data.

Who built the DMM

The CMMI Institute, which at that time was a Carnegie Mellon University enterprise responsible for CMMI, began work on the model in January 2011. It worked in cooperation with the EDM Council, an industry association founded by financial institutions to advance data management practice, and with corporate sponsors that included Booz Allen Hamilton, Kingland Systems, Lockheed Martin and Microsoft. When the model was unveiled in May 2014 it was still being peer reviewed by more than 140 data management and CMMI experts. Melanie Mecca managed the programme at the Institute. Version 1.0 became available in the summer of 2014, together with a series of training courses, a facilitated assessment method led by a DMM-certified professional, and a partner programme.

In 2016 ISACA, the professional association known for COBIT and for audit, security and governance certifications, acquired the CMMI Institute. For several years the DMM continued to be offered with training and certifications. Industry commentators report that around 2022 ISACA stopped offering the model and its training and certification as separate products, carrying data management content into the main CMMI model instead. In April 2023 ISACA announced a major CMMI update with new domains, one of them Data Management. If you meet the DMM today you will usually meet it in one of three ways: as a licensed copy inside an organisation that adopted it while it was offered, as a reference in data management literature and in the DAMA body of knowledge, or as the ancestor of the data content in CMMI.

Purpose and scope

The DMM has three main purposes. First, it is a reference model: a structured description of what a capable data management function does, written so that business and technical people can share it. Second, it is a measurement tool: its practices are arranged by level, so an organisation can establish a baseline and track movement over time. Third, it is a roadmap: because the levels build on each other, the gaps found in an assessment suggest a sensible order of work.

The scope is the management of data across the enterprise, not the design of any particular system. The model covers strategy, funding and communication; governance and shared vocabulary; data quality; how data requirements are captured and how data flows through its life; how architecture, platforms and integration support the data; and the general process disciplines, such as measurement and risk management, that keep everything stable. It does not prescribe tools, products, database designs or a specific organisation chart. Its authors repeatedly stressed that it says what an organisation should be able to do, not how to do it, so it is technology-neutral and can be applied in banks, government agencies, manufacturers, hospitals or research repositories alike.

It is also important to know what the DMM is not. It is not a law or regulation, not an international standard published by ISO, and not a security control catalogue. Data protection and privacy are touched only indirectly. It is a voluntary industry model, which explains both its flexibility and the fact that its fate depended on a single owner.

Lesson 2 – Key concepts and vocabulary

The DMM borrows much of its language from CMMI and adds terms from the data management profession. The following terms appear throughout the rest of this tutorial.

Data asset – data treated as something of value to the organisation, which therefore deserves ownership, investment, protection and measurement, just like money, equipment or people.
Data management – the set of business and technical activities that plan, define, create, control, deliver and improve data so that it is fit for its intended uses throughout its life.
Category – one of the six top-level groupings of the model, such as Data Governance or Data Quality. Categories make the model easier to navigate and to divide among assessment teams.
Process area – a cluster of related practices that together achieve a recognisable result, for example Business Glossary or Data Profiling. The DMM has 25 process areas, and each one can be studied, assessed and improved on its own.
Practice (practice statement) – a short description of an activity or capability that an organisation should exhibit within a process area. Practices are arranged by capability level, so lower-level practices describe basic performance and higher-level ones describe consistency, measurement and optimisation.
Work product – a tangible output that shows a practice is really performed, such as a data quality rule set, a glossary entry, a lineage diagram, a governance charter or meeting minutes. The model lists example work products, which assessors use as evidence.
Capability level – a rating from 1 (Performed) to 5 (Optimized) that summarises how well and how consistently the practices of a process area are carried out.
Maturity – the overall state of the organisation's data management, shown by the pattern of capability levels across process areas. Maturity is a profile, not a single heroic score.
Infrastructure support practices – practices that do not belong to one data topic but help any process area last: policies, plans, resources, training, stakeholder involvement, monitoring and review. They play the same role as institutionalisation or generic practices in CMMI.
Institutionalisation – the state in which a way of working has become ordinary, documented, resourced and checked, so that it survives reorganisations and staff turnover.
Data governance – the system of decision rights, roles, policies and accountability that decides how data is managed. Governance makes the decisions; other disciplines carry them out.
Data steward – a person, usually from the business, who is accountable for the definition, quality and correct use of a specific data domain such as customer, product or supplier.
Business glossary – an approved, shared list of business terms with their definitions, owners and relationships, so that "active customer" means the same thing in marketing, finance and operations.
Metadata – data that describes other data: names, definitions, formats, sources, owners, transformations and lineage. Good metadata lets people find, understand and trust data.
Data profiling – examining the actual content of a data set (value ranges, patterns, missing values, duplicates, relationships) to discover what is really there before judging or fixing it.
Authoritative source – the system or provider that the organisation designates as the trusted origin of a given data element; other copies should be derived from it.
Enterprise Data Management Expert (EDME) – the CMMI Institute's senior individual certification for people qualified to lead DMM assessments. New EDME certifications are no longer issued.

Two distinctions deserve special attention. The first is between capability and evidence. An organisation may honestly believe it manages metadata well, but in an assessment only work products and consistent practice count. The second is between governance and management. Governance decides and oversees; management plans and executes. Many failed data programmes skipped this distinction, created a committee and expected the data to improve by itself.

Lesson 3 – Structure of the model

Six categories and 25 process areas

The model groups its 25 process areas into six categories. Twenty process areas deal directly with data management and sit in five categories. The sixth category, Supporting Processes, holds five process areas adapted from CMMI that support all the others. The names below are those used in DMM 1.0; the descriptions are summaries in our own words.

Data Management Strategy (5 process areas)

Data Management Strategy – a written, approved vision, goals and priorities for data, aligned with the business strategy.
Communications – planned, two-way communication of data policies, standards, progress and decisions to everyone affected.
Data Management Function – the organisational structure, roles, responsibilities and skills that carry out data management.
Business Case – justification of data management initiatives in terms of costs, benefits and risks that business leaders understand.
Program Funding – sustained, predictable funding for the data management programme rather than one-off project money.

Data Governance (3 process areas)

Governance Management – the bodies, decision rights, policies and escalation paths that govern data.
Business Glossary – creating, approving and maintaining shared business terms and definitions.
Metadata Management – capturing, integrating and using business and technical metadata, including lineage.

Data Quality (4 process areas)

Data Quality Strategy – the organisation-wide approach to quality: goals, roles, priorities and policies.
Data Profiling – discovering the real content and structure of data sets.
Data Quality Assessment – measuring data against agreed quality dimensions and thresholds, and reporting the results.
Data Cleansing – correcting defects in a controlled way and, wherever possible, fixing the cause at the source.

Data Operations (3 process areas)

Data Requirements Definition – capturing what data the business needs, with definitions, quality expectations and rules.
Data Lifecycle Management – understanding and managing how data is created, flows, is used, changes and is retired across business processes.
Provider Management – managing internal and external data suppliers through agreements, service levels and quality expectations.

Platform and Architecture (5 process areas)

Architectural Approach – the target data architecture and the plan for moving towards it.
Architectural Standards – standards for data models, representations, access and exchange, and how compliance is checked.
Data Management Platform – the platforms and tools that store and serve data, chosen and run to meet business needs.
Data Integration – moving and combining data between systems in a controlled, consistent way.
Historical Data, Archiving and Retention – keeping history where needed, archiving what is no longer active and disposing of data according to retention rules.

Supporting Processes (5 process areas)

Measurement and Analysis – defining, collecting and analysing measures that tell managers whether the data programme meets its goals.
Process Management – defining, maintaining and improving the organisation's standard data management processes.
Process Quality Assurance – objectively checking that processes and work products follow the agreed standards.
Risk Management – identifying, analysing and treating risks to data and to the data programme.
Configuration Management – controlling versions and changes of important artefacts such as models, glossaries, rules and interface specifications.

Figure 1 – How the six DMM categories relate: strategy sets direction, governance turns it into decisions, three execution categories act on the data, and the supporting processes underneath keep that work stable.

Figure 1 is a way of reading the structure, not a mandatory sequence. Strategy explains why data matters and what the organisation is trying to achieve. Governance converts that intent into decisions, policies and shared meaning. Data Quality, Data Operations and Platform and Architecture are where people actually touch the data. The supporting processes are the "engine room" that makes the work measurable, controlled and repeatable. The authors were explicit that process areas are not steps in a sequence: an organisation can start with any area that matters most to it, and many start with data quality because the pain is visible there.

Inside a process area

Each process area in the model follows a similar pattern. A short purpose statement explains why the area matters. Introductory notes describe the topic in plain language for readers who are not specialists. Goals state what the area should achieve. Core questions help assessors and practitioners think about the current state. Then come the practice statements, grouped by capability level from 1 to 5, followed by example work products that would show those practices are happening. Infrastructure support practices sit alongside and describe what any process area needs in order to be institutionalised.

This layout makes the model readable in two directions. Read across a level, it tells you what "Defined" looks like for every topic. Read down a single process area, it shows you the growth path for that topic from basic performance to optimisation. Assessment teams use both views: down a process area to score it, across levels to understand the organisation's overall shape.

The five capability levels

The DMM uses five levels. Their names follow the CMMI family, but their descriptions are written for data.

Figure 2 – The five DMM capability levels: each level keeps everything from the levels below it and adds more consistency, measurement and improvement.

Level 1 – Performed. The work gets done, but mostly inside individual projects and in reaction to problems. Results depend on the skill and goodwill of particular people. Data is fixed when it breaks; little is written down or shared.
Level 2 – Managed. Work is planned and carried out according to policy. Roles are assigned, people have the skills and resources they need, relevant stakeholders are involved, and work products are reviewed. Leaders begin to treat data as an asset that needs management, although practices may still differ between business units.
Level 3 – Defined. The organisation has a standard set of processes, definitions and guidelines that are used consistently across units, with tailoring rules for local needs. Data is recognised as critical to performance at an enterprise level, and data management is coordinated rather than fragmented. Many organisations treat Level 3 as a sensible target for their most important process areas.
Level 4 – Measured. Process measures and data quality measures are defined and used to manage performance. Variation is understood and controlled, often with statistical or other quantitative techniques. Data is seen as a source of competitive advantage, so its management is managed by numbers.
Level 5 – Optimized. The organisation uses its measurements and feedback to improve its processes continually, introduces innovations in a controlled way and shares good practices with peers and the wider industry. Data management is regarded as essential to the organisation's survival in a changing market.

Two consequences follow from this ladder. First, higher levels are cumulative: a process area cannot be credibly "Measured" if the basics of Level 2 are missing, because the measurements would describe chaos. Second, the right target is a business decision. A small charity does not need Level 5 provider management; a global bank that consumes market data from dozens of vendors may need far more than Level 2.

Lesson 4 – How the DMM works in practice

Roles and governance of the programme

The DMM is used by people, so the first practical question is who is involved. A typical programme has an executive sponsor, often a chief data officer or chief operating officer, who owns the business case and funding. A data management office or central team coordinates standards, tools and training. A governance council with business representation makes policy decisions and resolves disputes. Data owners, usually senior business managers, are accountable for domains such as customer or product, and data stewards do the day-to-day work of defining terms, reviewing quality and approving changes. Data architects, integration engineers, platform teams and quality analysts deliver the technical side. Internal audit or quality assurance checks that the agreed processes are followed. The model does not dictate this exact structure, but its Data Management Function and Governance Management process areas expect clear roles of this kind.

An improvement cycle

The DMM is most useful when it is embedded in a repeating improvement cycle rather than used once for a report.

Figure 3 – A DMM-based improvement cycle: baseline, targets, roadmap, pilot, institutionalise, measure, then set new targets.

Agree business drivers and scope. Start from concrete business problems: regulatory reporting accuracy, a cloud migration, a customer experience programme, an analytics initiative. The drivers decide which process areas and data domains matter most. Trying to assess everything at once usually produces a long report and little change.
Establish a baseline. Use a facilitated assessment (Lesson 5) or a careful self-assessment to score current capability per process area, collecting evidence rather than opinions.
Set targets. For each relevant process area, agree a target level and a time frame with the business. Targets should be different for different areas; a uniform target is a sign that nobody has thought about value.
Build a roadmap. Group the gaps into initiatives, respect dependencies (a glossary before quality rules that rely on definitions, governance roles before escalation processes), estimate effort and secure funding.
Pilot. Introduce new practices in one data domain or business unit, learn and adjust. A visible early success builds the case for wider adoption.
Institutionalise. Write the policy, assign the roles, train people, put the work into normal processes and tools, and make quality assurance check it. This is where the infrastructure support practices matter.
Measure and re-assess. Track agreed measures, such as the number of critical data elements with an approved definition and owner, or defect rates for key quality rules, and re-assess periodically to show progress and set the next targets.

Typical artefacts

Organisations that use the DMM well tend to produce a recognisable set of artefacts: a data management strategy document approved by executives; a governance charter with decision rights; a register of data domains with owners and stewards; a business glossary; a metadata repository or catalogue with lineage for critical data; data quality rules, thresholds, scorecards and issue logs; data requirements templates used by projects; agreements with internal and external data providers; architecture principles and standards; integration patterns; and retention schedules. None of these is mandatory as a document type, but each is the kind of work product an assessor would look for.

How the categories reinforce each other

The process areas are separate for assessment, but in practice they are interdependent. A data quality rule needs a definition from the business glossary, an owner from governance, a lineage trail from metadata management, a place in the data lifecycle where it can be enforced, a platform to run on, and measurement to show whether it works. When an organisation improves one area in isolation, it often hits a ceiling caused by another. Recognising these links is a large part of planning a sensible roadmap. A useful habit is to ask, for every planned improvement, "which other process area must be at least at Level 2 for this to stick?"

Scaling the model to the organisation

A large enterprise may run the DMM across dozens of business units, while a small organisation may apply it to one critical data domain. The model works at both scales because process areas can be selected independently. Research and science data repositories, for example, have adapted the DMM to their own vocabulary, turning business cases into grant strategies and provider management into management of data contributors. That flexibility is a strength, as long as the adaptation is documented so that results remain comparable over time.

Lesson 5 – Assessment, certification and compliance

What a DMM assessment is

A DMM assessment establishes a baseline of capability across selected process areas and produces findings and recommendations. When the model was supported, the CMMI Institute's method expected an assessment to be led by a trained and certified Enterprise Data Management Expert, so that results were consistent between organisations. Self-assessment was always possible and is still the most common use today, but its value depends on how well the team understands the model and how honestly evidence is collected.

Figure 4 – The main stages of a DMM assessment, from sponsorship and preparation through workshops and scoring to a report and an improvement roadmap.

How it runs

Preparation usually takes a couple of weeks. The sponsor confirms scope and goals; the assessment lead identifies participants from both business and IT, because data management is shared work; documents and work products are gathered in advance. The core of the assessment is a series of facilitated workshops, typically spread over several days, in which participants discuss each process area against the practice statements. The facilitator asks for examples and evidence: "Show us the glossary entry for that term. Who approved it? When was it last reviewed?" Practices are scored on whether they are performed and how consistently, and scores roll up into a capability level per process area.

A good assessor separates what the organisation controls from what it does not, and keeps capability (what the organisation can do) apart from maturity evidence (how it can show that it does it consistently). Findings are validated with participants before they are finalised, which avoids surprises and builds ownership. The report describes strengths, weaknesses, scores and prioritised recommendations, and it usually includes a heat map of process areas. The conclusion and reporting phase typically takes another couple of weeks.

Certification: what existed and what exists now

It is important to be precise here. The CMMI Institute offered individual credentials connected with the DMM: training courses on building enterprise data management capabilities and, at the senior end, the Enterprise Data Management Expert certification for people qualified to lead assessments. It also had a partner programme for consultancies. The DMM was never an accredited management system standard like ISO 9001 or ISO/IEC 27001, so there was no accredited third-party certificate of conformity that an organisation could display in the same way.

Now that the model has been retired, new DMM certifications are not issued. Today, if an organisation needs an independent, formally rated appraisal of its data management, the nearest option from the same owner is a CMMI appraisal that includes the Data Management domain. Other organisations use the EDM Council's DCAM, which has its own training and certification. Any consultant offering an "official DMM certification" in 2026 should be asked to explain exactly which body issues it.

Compliance uses

No law requires the DMM, but a maturity assessment can support compliance with requirements that demand reliable data. A bank can use one to show supervisors how it manages risk data aggregation and reporting, a public agency can use one to justify a data programme in a budget case, and a company can use one to demonstrate control over data supplied by third parties. In each case the model provides structure and evidence; the legal obligation comes from the regulation itself.

Reading assessment results sensibly

Results should be read as a profile. A pattern such as Level 3 in Data Integration but Level 1 in Business Glossary tells a story: technical pipelines are standardised, but the meaning of what flows through them is not agreed. Comparing a single average across organisations is far less useful than understanding which gaps block business goals. Assessors also warn that a score is only as good as its evidence; a high self-assessed score without work products is a risk, not an achievement.

Lesson 6 – Worked example: a regional utility fixes its customer and asset data

The situation

Northvale Energy (a fictional company) supplies electricity and gas to about a million customers in one region. It runs a billing system from the 2000s, a newer customer relationship platform, a geographic asset system for its network, and a data warehouse that feeds regulatory and management reports. Three problems have reached the board. Billing complaints have risen because move-in and move-out dates differ between systems. The energy regulator has questioned figures on network outages because asset identifiers do not match between the asset system and the outage records. And a planned smart-meter analytics project has slipped because nobody can say which customer address is correct.

Step 1 – Drivers and scope

The new chief data officer agrees with the chief executive that the programme will focus on two data domains, customer and network asset, and on the business outcomes the board cares about: fewer billing complaints, defensible regulatory figures and a dependable foundation for analytics. Using the DMM's categories, the team chooses twelve process areas to assess first: Data Management Strategy, Data Management Function, Business Case, Governance Management, Business Glossary, Metadata Management, Data Quality Strategy, Data Profiling, Data Quality Assessment, Data Requirements Definition, Data Lifecycle Management and Data Integration. Supporting processes will be looked at through the lens of these areas.

Step 2 – Baseline assessment

An external assessment lead, experienced with the model, runs four days of workshops with billing, customer service, network operations, regulatory reporting, IT and finance. Evidence is collected beforehand. The results are mixed. Data Integration scores Level 2: the integration team has documented interfaces, change control and monitoring. Data Profiling is Level 1: analysts profile data inside projects, but results are thrown away afterwards. Business Glossary is Level 1: there are three conflicting definitions of "customer", and nobody has authority to choose. Governance Management is also Level 1: a data committee exists on paper but has met twice in a year without decisions. Data Management Strategy is Level 1: data is mentioned in the IT strategy but has no goals of its own.

The workshop discussions reveal the real causes of the board's problems. Move-in dates differ because the customer platform and the billing system apply different rules and nobody owns the rule. Asset identifiers differ because field crews create local codes when the asset system is slow, and there is no provider agreement between operations and the data warehouse team.

Step 3 – Targets and roadmap

The executive team agrees targets for eighteen months: Level 3 for Governance Management, Business Glossary and Data Quality Assessment in the two chosen domains; Level 2 for Data Management Strategy, Data Profiling, Metadata Management and Data Lifecycle Management; and maintaining Level 2 in Data Integration while extending its standards. Level 4 is explicitly out of scope for now; the team would rather be consistent than measured badly.

The roadmap respects dependencies. In the first quarter, the board approves a short data strategy with three goals linked to the business drivers, and a governance charter that names a customer data owner (the director of customer operations) and an asset data owner (the director of network operations), each with stewards. In the second quarter, stewards agree definitions for twenty critical terms, starting with customer, premises, supply start date and asset identifier, and record them in a glossary with owners and approval dates. The team builds lineage for the regulatory outage figure from source to report. In the third quarter, analysts profile the customer and asset tables against the new definitions, write quality rules with thresholds, and publish a monthly scorecard to the governance council.

Step 4 – Pilot and institutionalise

The customer domain goes first. The billing and customer platform teams change their move-in rules to follow the glossary definition, and the steward approves the change through the governance process. Cleansing is done once, and the cause is fixed at the point of entry with validation in the customer platform. Then the approach is extended to assets: field crews get a quick way to request new asset identifiers, and a provider agreement sets service levels between operations and the warehouse team.

To institutionalise the changes, the data management office writes a data quality policy, adds data requirements templates to the project lifecycle, trains stewards, and asks internal quality assurance to check that new projects use the glossary. Configuration management is applied to glossary entries and quality rules, so that changes are versioned and approved.

Step 5 – Measure and re-assess

After eighteen months a second assessment confirms Level 3 in Business Glossary and Governance Management for the two domains and Level 2 in Data Quality Assessment, which falls short of its target because thresholds are not yet used consistently by all report owners. The board receives the honest result alongside business measures: billing complaints about move dates have fallen sharply, the regulator has accepted the documented lineage for outage figures, and the analytics project has restarted on profiled, owned data. The next cycle adds Provider Management and Historical Data, Archiving and Retention, because smart-meter data volumes will soon make retention a real cost and risk.

What the example teaches

Northvale did not try to reach a high average score. It started from business pain, assessed a focused set of process areas with evidence, set different targets for different areas, respected the dependencies between governance, vocabulary and quality, piloted in one domain, and institutionalised the new practices before claiming success. That is the pattern the DMM was designed to support.

Lesson 7 – Relationship to other standards and frameworks

The DMM sits in a crowded landscape. Knowing its neighbours helps you choose and combine tools sensibly.

Framework	Owner	What it is	Relationship to the DMM
CMMI (with Data Management domain)	ISACA / CMMI Institute	Capability and maturity model for development, services, suppliers, security, safety, people, virtual work and data, with formal appraisals	The DMM's parent family and its successor for data. The DMM borrowed CMMI's architecture; selected DMM content now lives in CMMI's data practice areas.
DCAM (Data Management Capability Assessment Model)	EDM Council	Capability framework and assessment method for data management, widely used in financial services	A close cousin. The EDM Council cooperated on the DMM and maintains DCAM (now version 3) as its own actively supported framework, with training and professional certification.
DAMA-DMBOK	DAMA International	Body of knowledge describing data management knowledge areas, with data governance at the centre	Describes the knowledge and functions; the DMM describes how capable the organisation is at them. DMBOK discusses maturity assessment and cites models such as the DMM.
ISO 8000 series	ISO	International standards on data quality and master data, including exchange of quality data	Gives detailed, formal requirements for data quality topics; the DMM's Data Quality category shows how capably an organisation manages quality overall.
ISO/IEC 33000 series	ISO/IEC	Framework for process assessment and capability measurement	A general, standardised approach to process assessment; the DMM is a domain-specific model with its own levels and assessment method, so the two share ideas (capability levels, evidence-based rating) but are separate.
COBIT	ISACA	Framework for governance and management of enterprise information and technology	Covers IT governance broadly, including data-related objectives; the DMM goes much deeper into data-specific practices.

Two practical points follow from the table. First, a body of knowledge and a maturity model answer different questions. DMBOK helps you understand what metadata management involves; the DMM helps you judge how well your organisation does it and what to do next. Many teams use both. Second, because the DMM is no longer supported, organisations starting today often choose between the CMMI Data domain, which suits those already using CMMI appraisals, and DCAM, which suits those that want a dedicated data framework with an active community. The DMM still offers a clear structure and vocabulary, which is why it remains a good teaching model and a useful checklist for self-assessment.

The DMM also complements regulation-driven frameworks. Privacy laws, banking supervisory principles on risk data and sector rules on record retention all set obligations. A maturity model does not replace any of them, but it helps an organisation build the disciplines needed to meet them repeatedly rather than through last-minute heroics.

Common pitfalls and best practices

Pitfalls seen again and again in DMM programmes:

Chasing a single score. Treating "reach Level 3" as the goal for every process area wastes money on areas that do not matter and hides the real business gaps.
Assessment without action. A thorough baseline report that is not turned into a funded roadmap simply documents the problem and erodes trust in the next initiative.
Governance on paper. A council that meets rarely, has no decision rights and no stewards behind it scores Level 1 however impressive its charter looks.
Tool-first thinking. Buying a catalogue or quality tool before agreeing definitions, owners and rules automates confusion; the DMM is deliberately tool-neutral for this reason.
Cleansing without root cause. Repeatedly fixing records downstream while the source keeps creating defects keeps Data Cleansing busy and Data Quality permanently immature.
Self-assessment by optimism. Scores based on opinions rather than work products overstate capability and lead to wrong priorities.
Ignoring the model's status. Promising stakeholders an official DMM certificate that can no longer be obtained damages credibility.

Best practices that make the model pay off:

Start from business drivers and choose process areas and data domains that serve them.
Insist on evidence in every assessment: work products, records of decisions and examples from real use.
Set different targets for different process areas, agreed with business owners and tied to value.
Respect dependencies: governance roles and shared definitions early, because quality, metadata and integration depend on them.
Pilot, then institutionalise with policy, training, quality assurance and configuration control, so improvements survive change.
Measure and re-assess on a regular cycle and report results honestly, including missed targets.
Map to current frameworks: if you need formal appraisal or a living community, map your DMM work to the CMMI Data domain or DCAM.

Summary and key takeaways

The DMM is the CMMI Institute's reference model for enterprise data management, version 1.0 released in 2014 with EDM Council cooperation; it has since been retired as a product (around 2022) and its ideas continue in CMMI's Data Management domain.
It organises 25 process areas into six categories: Data Management Strategy, Data Governance, Data Quality, Data Operations, Platform and Architecture, and Supporting Processes.
Practices are arranged by five capability levels (Performed, Managed, Defined, Measured, Optimized); higher levels are cumulative and targets should differ by process area.
The model describes what to achieve, not how; it is tool-neutral and process areas can be adopted independently.
Assessments are evidence-based, workshop-driven and produce a profile per process area plus recommendations; certification was for individuals, never an accredited organisational certificate.
Successful programmes start from business drivers, establish governance and shared vocabulary early, pilot, institutionalise and re-assess.
DAMA-DMBOK explains the knowledge areas, DCAM and the CMMI Data domain are today's actively supported assessment options, and ISO 8000 deepens data quality requirements.

Reflection questions

Think of one data dispute you have seen at work. Which DMM process areas were weakest, and what evidence would an assessor have found?
If your organisation could improve only three process areas in the next year, which would you choose, what target level would you set for each, and why?
How would you explain to a sceptical finance director why Business Glossary work should be funded before a new data quality tool?
Your team has completed a self-assessment with high scores but few work products. How would you test and correct those scores without demoralising the team?
Given that the DMM is no longer supported, how would you decide whether to continue with it, move to the CMMI Data domain or adopt DCAM?