Enterprise Data Model

Definition

An enterprise data model (EDM) defines the key business entities an organization cares about, their attributes, and the relationships between them at a conceptual and logical level — before any decision is made about how that data is physically stored. It answers questions like: what does 'Customer' mean across the enterprise, how does it relate to 'Account' and 'Household,' and which business rules govern that relationship? Because it is expressed independent of technology, the same EDM can be used to reason about a mainframe system, a cloud data warehouse, and a SaaS application without contradiction. The EDM sits at a different altitude than the data models architects encounter daily. It is broader than a single application's database schema, more abstract than a physical data model with tables and keys, and more business-oriented than a data dictionary that simply catalogs field names. It is narrower than the full data architecture discipline, which also covers data flows, integration patterns, storage technology, and data governance operating models — the EDM is the reference structure that discipline organizes around. Critically, an EDM is not built for its own sake. Its value comes from being cross-mapped to other architecture artifacts: business capabilities that create or consume each entity, value streams that transform data as it moves through a process, and applications that currently hold conflicting or duplicate versions of the same concept. Done well, the EDM becomes the shared vocabulary that lets business and technology stakeholders agree on what 'Customer' actually means before they argue about whose system is authoritative.

Origin & Context

Enterprise data modeling grew out of entity-relationship modeling techniques formalized in the 1970s, notably Peter Chen's ER modeling notation, which gave architects a rigorous way to represent business concepts and their relationships independent of physical database design. The practice was elevated to an enterprise concern through frameworks like the Zachman Framework, which dedicates an entire column to the 'What' (data) perspective across levels of abstraction, and later through TOGAF's Data Architecture phase within the Architecture Development Method. Today it is a core practice area within the DAMA-DMBOK body of knowledge for data management.

Why It Matters

CIOs and CDOs rely on a well-governed EDM to eliminate the redundant, conflicting data stores that drive up integration cost and slow every system replacement project. Business architects use it to cross-map capabilities and value streams to the data they actually depend on, exposing where 'Customer' or 'Product' silently means three different things across the business. Compliance and risk leaders in regulated industries depend on a defined EDM to demonstrate data lineage and aggregation capability to regulators. And M&A teams use it as the fastest way to assess how painful — or straightforward — combining two companies' systems will actually be.

Common Misconceptions

Myth: An enterprise data model is just a big entity-relationship diagram for a database.

Reality: A physical or logical database schema describes how one system stores data, including tables, keys, and indexes optimized for performance. An EDM is deliberately technology-agnostic and sits above any single system, defining what a business entity means and how it relates to other entities regardless of where or how it is eventually stored.

Myth: The enterprise data model is an IT deliverable that business stakeholders don't need to be involved in.

Reality: Data architects can model structure, but only business stakeholders and business architects can define what an entity actually means to the business, who owns it, and which capabilities and value streams depend on it. Without that business context, the EDM becomes a technically correct artifact that nobody trusts or uses.

Myth: Building an EDM requires modeling every entity in the enterprise before it delivers any value.

Reality: Most practitioners build the EDM iteratively, prioritizing the entities most critical to a specific driver — a merger, a master data management initiative, a regulatory mandate — and expanding coverage over time rather than attempting a big-bang, all-encompassing model that never ships.

Practical Example

During a bank merger, the Chief Data Architect and a business architect co-led an effort to reconcile how each institution defined 'Customer.' One bank modeled Customer as a household-level relationship; the other modeled it strictly at the individual account holder level. By cross-mapping both definitions against the combined capability map — specifically the Customer Onboarding and Relationship Management capabilities — the team identified where downstream reporting, risk aggregation, and marketing segmentation would break if the discrepancy went unresolved. They defined a single enterprise-level Customer entity with clear attributes and relationships, documented ownership with the retail banking business unit, and used it to guide which legacy system would become the golden source. The result was a materially smoother systems consolidation, with far fewer late-stage data reconciliation surprises than the integration team had experienced in prior mergers.

Industry Applications

Financial Services

Used to define shared entities like Customer, Account, and Instrument that support regulatory risk data aggregation requirements such as BCBS 239, ensuring consistent reporting across risk, finance, and compliance functions.

Healthcare

Defines core entities such as Patient, Provider, Encounter, and Claim to support interoperability across clinical and administrative systems and to underpin population health analytics.

Retail and Manufacturing

Unifies Product, SKU, and Location entities across e-commerce, ERP, and point-of-sale systems, enabling consistent inventory visibility and omnichannel reporting.

Related Terms

• Data Architecture: broader discipline encompassing the EDM along with data flows, integration, and governance