Complete a quick assessment and discover your Data Governance Maturity Score.

Walk into most AEC firms and ask a senior leader to explain the difference between data governance, data management, and MDM. The most common answer is a version of: ‘they’re all roughly the same thing.’ They are not, and the confusion has direct operational consequences.

When a large general contractor selects a new project management platform and migrates project data into it, they perform data management. When the firm can’t agree on what counts as a project code, whether it includes phases, sub-projects, or client identifiers, they have a data governance problem. When the same project appears under three different names in the CDE, the ERP, and the cost control system, they have an MDM problem. All three failures are happening simultaneously. All three have different causes. And all three require different interventions.

AEC firms invest heavily in technology to solve these problems: CDE platforms, BIM management tools, ERP systems, and asset tracking software. What the technology cannot do is decide who owns a data element, what quality standard applies to it, or which system is the master source. Those are organizational decisions. The disciplines of data governance, data management, and MDM provide frameworks for making them.

This article defines each discipline clearly, shows where they overlap and where they diverge, and maps each to the specific AEC challenges it is designed to address. If you are evaluating a governance program, planning a system migration, or building an information management capability, this distinction will determine which program you actually need, and which problem you should fix first.

What Is Data Management?

Data management is the broadest of the three disciplines. DAMA International’s Data Management Body of Knowledge, Second Edition (DMBoK 2) defines it as ‘the development, execution and supervision of plans, policies, programs and practices that deliver, control, protect and enhance the value of data and information assets throughout their lifecycles.’ It is the operational discipline, engineering, and administration of data as a functional resource.

In practical terms, data management covers the full operational scope of working with data: designing and maintaining databases and data warehouses, building data pipelines and integration layers, managing storage and backup, enforcing access controls, running data quality processes, and keeping the technical infrastructure that data depends on operational and reliable.

In AEC, data management manifests as the operational administration of the CDE, the configuration and maintenance of BIM platforms, the integration between project management and cost control systems, the archival of project deliverables, and the backup and recovery processes for engineering drawings and specifications. These are infrastructure functions. They require technical skills and operational rigour. They do not, by themselves, define who decides what the data standards are, who is accountable when data quality fails, or what happens when two systems disagree about the same project record.

Data management is the how. It answers: how do we store data, how do we move it, how do we make it available, how do we protect it? It is necessary but not sufficient. Without the authority layer that governance provides, data management produces well-maintained systems filled with inconsistent, ungoverned data.

What Data Management Covers in AEC

• CDE architecture: the design, configuration, and operational management of the Common Data Environment used across project stages

• BIM platform administration: user access, folder structures, naming convention enforcement at the system level

• Data integration: connections between the CDE, ERP, cost control, asset management, and HR systems

• Data quality operations: detecting and correcting data errors, duplicates, and incomplete records at the technical layer

• Data lifecycle management: archival schedules, retention policies at the operational level, version control for deliverables

• Backup, recovery, and business continuity: ensuring data assets survive system failures, project handovers, and organizational change

What Is Data Governance?

Data governance is the authority and accountability layer that sits above data management. DAMA DMBoK 2 defines it as the exercise of authority and control (planning, monitoring, and enforcement) over the management of data assets. Governance is not an operational practice; it is an organizational capability. It determines who has the right to make decisions about data, what standards apply, and what happens when those standards are not met.

The critical word in the DAMA definition is authority. Data governance is meaningless without decision rights. You can have governance policies written into documents, governance committees meeting quarterly, and governance frameworks published on intranets, and still have no actual governance, because no one has the authority to enforce standards or resolve disputes. Effective governance requires the organizational structure to back the policies.

In AEC, data governance is the discipline that answers questions like: Who decides what naming conventions apply to drawing files? What approval process applies before project data moves from the CDE to the client? Who is accountable when a specification of version conflict creates a field error? What is the policy on retaining project data after contracts close? How do we ensure that AI tools used on project data operate within defined access and security controls?

These are not IT questions. They are business questions with significant financial, legal, and operational consequences. Governance is the discipline that converts them from unresolved tensions into documented decisions with accountability behind them.

What Data Governance Covers in AEC

• Data ownership: identifying and assigning individual accountability for specific datasets, domains, or information types across the enterprise

• Data quality standards: defining what ‘good’ data looks like for each domain, completeness, accuracy, consistency, timeliness, and who is responsible for maintaining it

• Data policies and procedures: documented rules governing how data is created, accessed, modified, shared, and retired

• Regulatory and contractual compliance: ensuring data practices meet the obligations of GDPR, UK GDPR, PIPEDA, HIPAA for joint ventures with healthcare clients, and ISO 19650 requirements on information management

• AI and analytics readiness: establishing the data access controls, consent frameworks, and quality thresholds that AI systems require to operate reliably and within legal boundaries

• Governance operating model: the committee structure, escalation paths, and decision-making framework that makes governance durable across project cycles and organizational change

What Is Master Data Management (MDM)?

Master Data Management is a focused discipline within data management that addresses a specific and persistent problem: critical shared data entities appearing in multiple versions across multiple systems, with no single authoritative source. MDM’s purpose is to create, maintain, and distribute a ‘golden record’, a single, trusted, authoritative representation of each key entity that all systems agree on.

The data entities that MDM addresses are called master data. These are the nouns of an enterprise: clients, projects, assets, employees, vendors, materials, and locations. Unlike transactional data, invoices, timesheets, RFIs, change orders, master data does not change frequently. But when it is inconsistent across systems, every transaction that references it is potentially compromised.

In AEC, MDM is relevant because the same core entities appear in multiple systems that do not automatically synchronize. A client might be ‘Acme Holdings’ in the CRM, ‘Acme Construction Holdings LLC’ in the ERP, and ‘ACH’ in the project management system. A project might carry different codes in cost control, procurement, and document management system. An asset, a building or infrastructure component, might be tracked under different IDs in the design model, the facilities management system, and the capital planning tool.

This fragmentation is not a technology problem. It is an organizational problem that MDM addresses by establishing what the canonical entity looks like, where it is mastered (the system of record), how updates propagate to dependent systems, and who is responsible for maintaining the golden record when it changes.

Core MDM Domains in AEC

• Client master: a single, verified identity for each client or employer entity, consistent across CRM, legal, procurement, and project management systems

• Project master: a canonical project record with a consistent code structure, name, and status that all project-adjacent systems reference, CDE, ERP, cost control, scheduling, and HR for labor tracking

• Asset master: a unique identifier and attribute set for each built asset, building, bridge, road segment, plant equipment, that survives across design, construction, and operations phases

• Vendor and supplier master: a deduplicated, verified registry of all vendors, subcontractors, and suppliers, with consistent identifiers that procurement, accounts payable, and compliance systems share

• Location and site master: standardized geographic and site identifiers that connect project coordinates, regulatory boundaries, and operational areas across planning, delivery, and facility management tools

How They Relate: A Practical Comparison for AEC

The three disciplines are interdependent but distinct. A useful way to understand the relationship is to think of them as three layers that address different levels of the same problem.

Data management is the operational layer, infrastructure, and practice of working with data. Data governance is the authority layer, who decides, who enforces, who is accountable. MDM is the entity control layer, ensuring that the specific entities all systems shares are consistent, reliable, and singular.

You need all three. Data management without governance produces well-run systems with ungoverned content. Governance without data management is policy without infrastructure. MDM without governance is a technical project that gets overridden the moment someone creates a new vendor entry in the wrong system.

AEC Use Cases: Where Each Discipline Applies

The three disciplines are easier to understand in the context of problems AEC firms actually face. The following use cases illustrate where each one applies, and why the others, alone, would not be sufficient.

Use Case 1: Drawing File Naming Conventions Are Inconsistent Across Projects

A mid-sized engineering consultancy finds that different project teams have applied different naming conventions to drawing files. When a new CDE platform is implemented, the migration surfaces thousands of files that cannot be automatically classified. The CDE vendor recommends a naming standard, but teams continue applying their own conventions because there is no policy and no one to enforce it.

The data management response is to configure the CDE to enforce naming conventions at upload. But this fails because no one has agreed on what the standard is. The MDM response might help if the problem were about project identifiers specifically. The discipline that actually solves this is data governance: define the naming standard, assign stewardship responsibility to an Information Manager, and build the escalation path for non-compliance into the project delivery workflow.

Use Case 2: The Same Client Appears Under Different Names in Four Systems

A general contractor runs a CRM, an ERP, a project delivery platform, and a facilities handover system. A major client that has undergone a rebrand now appears under the old name in the ERP, the new name in the CRM, an abbreviation in the delivery platform, and a legacy code in the handover system. Contract documents to reference all four variants. When the firm tries to build a consolidated account view for executive reporting, the inconsistency blocks the analysis.

This is an MDM problem. The fix is to establish a client master with a canonical identifier, likely managed in the CRM as the system of record, and propagate that identifier to the ERP, delivery platform, and handover system. Data governance is a prerequisite: someone must have the authority to designate the CRM as the master source and mandate that all other systems reference it. Data management delivers technical integration. All three disciplines are required in sequence.

Use Case 3: AI Copilot Tools Cannot Access Project Data Reliably

An AEC firm deploys a Microsoft Copilot license for project managers. The expectation is that Copilot can surface relevant project data from SharePoint and the CDE to answer queries about document status, specification versions, and RFI history. In practice, Copilot returns inconsistent results because project folders are structured differently across projects; access permissions are applied inconsistently, and document metadata is incomplete.

The data management response is to standardize folder structures and metadata schemas. The MDM response is to ensure project identifiers are consistent so Copilot can correctly scope queries by project. The governance response is to establish who is responsible for maintaining the folder structure standard and the metadata quality across all active projects. Without governance authority behind the data management and MDM fixes, the inconsistency will reassert itself within the next project cycle.

Use Case 4: Asset Data Does Not Survive the Handover from Design to Operations

A large infrastructure owner commissions a construction project. The asset data embedded in the BIM model, equipment specifications, maintenance schedules, warranty information, location coordinates, is rich and accurate at handover. Twelve months into operations, the facilities management system contains only a fraction of that data. The rest was lost in the handover process because there was no protocol for exporting structured asset data from the BIM model into the CAFM system.

This is both a data management problem and a governance problem. Data management provides the technical mechanism for extracting structured BIM data and loading it into the CAFM system. Governance provides the policy requiring that handover data be complete, the role responsible for verifying it, and the contractual mechanism for holding the delivery team accountable. MDM ensures the asset identifiers used in the BIM model match those used in the CAFM system so records link correctly.

How Other Industries Handle the Distinction

AEC is not unique in navigating these three disciplines. Healthcare and financial services have had to resolve the same definitional challenges, under sharper regulatory pressure and with longer institutional experience with data governance programs. Their approaches offer useful comparative lenses.

Healthcare: Governance and MDM as Patient Safety Infrastructure

Healthcare organizations operate under HIPAA’s requirements for the protection, accuracy, and integrity of protected health information. The HIPAA Privacy Rule and Security Rule impose governance requirements explicitly: covered entities must designate a Privacy Officer responsible for data policies, must implement safeguards for PHI, and must document accountability structures. This is data governance written into federal law.

On the MDM side, patient identity management is a patient’s safety imperative. HL7 FHIR (Fast Healthcare Interoperability Resources) provides a widely adopted standard for structuring health data and defining clinical master data entities, including patient demographics, practitioner identifiers, and care locations. US healthcare systems have invested heavily in Master Patient Index solutions, MDM programs specifically for the patient entity, because a patient record mismatch can lead directly to clinical harm.

The AEC parallel is clear. In healthcare, a misidentified patient creates a safety event. In AEC, a misidentified asset record during a facilities takeover creates maintenance errors, warranty lapses, and capital planning failures. The stakes differ; the underlying discipline required is the same.

Financial Services: Governance as a Regulatory Mandate

The Basel Committee on Banking Supervision’s BCBS 239 Principles for Effective Risk Data Aggregation and Reporting, published in January 2013 and subject to ongoing supervisory assessment, established data governance as a regulatory requirement for systemically important banks. The principles include an explicit requirement that banks establish a firm-wide data governance framework with defined data ownership, quality standards, and reporting accountability.

Financial services also use the Legal Entity Identifier (LEI), a 20-character, alphanumeric code defined under ISO 17442, as a global MDM standard for identifying legal entities that participate in financial transactions. LEI adoption is mandated under MiFID II in the EU, the Dodd-Frank Act in the US, and equivalent regulations in Canada and the Netherlands. It is an MDM as a statutory infrastructure.

AEC firms operating internationally face comparable requirements around project entity identifiers and counterparty identification in the context of procurement regulations, anti-bribery compliance, and supply chain due diligence. The discipline is the same; the regulatory driver is different.

Manufacturing: Operational Technology and Product Master Data

Large manufacturing organizations, particularly in process industries and industrial construction, have dealt with data management, governance, and MDM challenges across their product and asset data for decades. The intersection of operational technology (OT) and information technology (IT) data creates governance boundary problems: who owns data generated by a sensor on a production line, the IT team, the plant operations team, or the engineering team that designed the sensor integration? These ownership disputes are direct analogues to the BIM-versus-ERP ownership disputes that AEC organizations face.

Manufacturing organizations that have resolved these questions have done so by applying data governance principles to OT/IT boundaries, defining domain ownership, establishing data stewardship for product master and asset master data, and building MDM programs for their equipment registries. AEC firms undertaking digital twin programs are entering precisely this territory.

Professional Standards and Frameworks

Three professional frameworks directly address the relationship between data management, data governance, and MDM. Each is verifiable, actively maintained, and directly applicable to AEC information management.

DAMA International: DMBoK 2

DAMA International’s Data Management Body of Knowledge, Second Edition (DMBoK 2) remains the authoritative professional reference for all three disciplines. DMBoK 2 defines data governance in Chapter 1 as the overarching function that provides authority and direction for all other data management knowledge areas. Data management disciplines, including data quality, data integration, reference and master data management, and data architecture, are treated as the operational functions that governance directs.

Chapter 10 of DMBoK 2 addresses Reference and Master Data Management specifically, defining master data as ‘data about the business entities that provide context for business activity’ and distinguishing it from reference data (codes and values) and transactional data. The chapter defines the key MDM implementation styles, registry, consolidation, coexistence, and centralized, and maps each to different organizational MDM maturity levels.

DMBoK 2 makes the relationship between the three disciplines structurally explicit: governance is the authority layer that all management disciplines operate under, and MDM is one of the eleven data management knowledge areas that governance must address. This hierarchy maps directly to how AEC information management programs should be designed.

ISO 19650: Information Management in AEC

ISO 19650 does not use the term ‘data governance’ explicitly, but its information management requirements encode governance principles into a contractual and operational standard for AEC. The standard defines roles and responsibilities for information management (covered in detail in Blog 04 of this series), establishes requirements for the Common Data Environment, and mandates information management planning at the project level.

Crucially, ISO 19650-1 establishes the concept of the Exchange Information Requirement (EIR), a formal document specifying what information an Appointing Party needs, in what format, to what level of development, and at what project stage. This is governance applied to information deliverables: defining the standard, the accountability for meeting it, and the verification process. AEC organizations that implement ISO 19650 rigorously are, in effect, implementing project-level data governance.

For UK public sector projects, ISO 19650 compliance is a procurement requirement under the UK BIM mandate. For Netherlands government infrastructure to work under RGD standards, equivalent information management requirements apply. US federal projects under GSA BIM guidelines impose comparable information management mandates. AEC firms active in BluEnt’s primary geographic markets cannot treat information management as optional.

ISO/IEC 38505-1: Governance of Data

ISO/IEC 38505-1:2017 is the international standard for governance of data as part of IT governance, operating under the ISO/IEC 38500 corporate governance of IT framework. It provides a model for evaluating, directing, and monitoring data governance at the organizational level. Unlike DAMA DMBoK 2 (which is practitioner-focused), ISO/IEC 38505-1 is governance-board-focused, addressing how organizational leadership should exercise oversight over data as a strategic asset.

AEC firms that have ISO 9001 quality management systems or ISO/IEC 27001 information security management systems in place are already operating within the ISO governance framework family. ISO/IEC 38505-1 extends that framework specifically to data governance. Organizations seeking a formal, auditable governance structure, particularly those responding to regulatory scrutiny or enterprise client governance requirements, may find it a useful complement to the DAMA practitioner framework.

Five Signs Your Organization Is Confusing These Disciplines

AEC firms that have conflated data management, data governance, and MDM tend to exhibit recognizable patterns. These five signs indicate where the confusion is causing real operational damage.

Sign 1: You Treat a CDE Rollout as a Governance Program

Implementing a Common Data Environment is a data management initiative. It provides the infrastructure for document control, version management, and access control. It does not define who owns the content, what quality standards apply, or what happens when teams bypass the CDE and share files via email. AEC firms that expect a CDE implementation to solve their governance problems consistently find that the new platform is filled with the same disorganized, ungoverned data within two project cycles.

Sign 2: You Build MDM Programs Without Governance Authority

An MDM program that defines a golden record for the project master entity will fail if no governance authority mandates that all systems use it. In practice, what happens is that the MDM team creates the canonical project record in the ERP or CRM, and project teams continue creating local records in their delivery tools without referencing it. The golden record exists technically but is not the master source operationally. Governance authority is what converts MDM technical design into organizational practice.

Sign 3: Data Governance Policies Exist but Are Not Enforced

Many AEC organizations have data governance documents: naming convention standards, metadata requirements, and data quality guidelines. What they lack is the accountability structure to enforce them. When a governance policy has no data owner responsible for compliance, no escalation path for violations, and no mechanism for measuring adherence, it is a document, not a governance program. The presence of governance documentation is not evidence of governance capability.

Sign 4: You Cannot Answer ‘Which System Is Master? for Core Entities

If you ask your IT director, your BIM manager, and your finance director about which system contains the authoritative version of your project list, and you receive three different answers, you have an MDM gap. The inability to identify a system of record for critical entities means that any report, dashboard, or AI query that aggregates data across systems is potentially drawn from inconsistent sources. This is not a reporting problem. It is an MDM problem with a reporting symptom.

Sign 5: AI and Analytics Projects Stall at the Data Preparation Stage

Organizations that have invested in AI or advanced analytics capability for their AEC operations, Copilot deployments, predictive project risk tools, portfolio dashboards, consistently report that the majority of project time is spent on data preparation rather than analysis or insight generation. This is a reliable indicator that data management (data quality and integration), data governance (standards and accountability), and MDM (entity consistency) are all underdeveloped. The AI capability is ready; the data foundation is not.

Frequently Asked Questions

What is the difference between data governance and data management?Data management is the operational discipline of storing, processing, and maintaining data, infrastructure, and practices that keep data systems running. Data governance is the authority layer that determines who decides how data is managed, what standards apply, and who is accountable when standards are not met. Data management answers ‘how do we work with data?’ Data governance answers ‘who is in charge of data, and what are the rules?’ Both are necessary; neither replaces the other.

Do AEC firms need MDM, or is it only for large enterprises?MDM is relevant to any AEC organization that operates multiple systems containing the same entity types, projects, clients, assets, and vendors. This applies to firms of almost any size. A 200-person engineering consultancy using a CRM, an ERP, and a CDE will have a client master data problem if those systems do not share a canonical client identifier. The scope and sophistication of the MDM program will differ from a large enterprise, but the underlying need, a single, authoritative representation of critical entities, does not.

Should we implement data governance or MDM first?It depends on the most pressing operational problem. If the immediate pain is inconsistent with project identifiers and duplicate entity records across systems, MDM needs to be the first workstream, but governance authority must be established concurrently, or the MDM program will not hold. If the immediate problem is accountability gaps, policy gaps, or AI readiness failures, governance is the starting point, and MDM follows as one of the governance program’s deliverables. In practice, both programs are typically run in parallel with phased delivery.

How does ISO 19650 relate to data governance?ISO 19650 encodes information management governance requirements into a contractual and operational standard for AEC projects. It mandates information management roles, information management plans, and Exchange Information Requirements, all of which are governance mechanisms applied to project-level information. Organizations that implement ISO 19650 rigorously are implementing project-level data governance. Elevating that governance to the enterprise level, covering all projects and all systems, not just a single project’s CDE, requires an additional enterprise governance layer beyond what ISO 19650 specifies.

What is the fastest way to assess data governance, data management, and MDM maturity?The most efficient approach is a structured readiness assessment that evaluates governance accountability structures, data management operational practices, and MDM entity coverage against a defined maturity model. BluEnt’s Data Governance Readiness Assessment covers all three disciplines, benchmarks current maturity against AEC industry practice, and produces a prioritized roadmap that identifies which gaps close first based on operational impact. Assessments typically complete within three to four weeks.