Evolution of the Data Model Hierarchy

The classic hierarchy - Conceptual → Logical → Physical - works well when you’re building a single system in isolation. But most organisations no longer work that way. They run hundreds (sometimes thousands) of applications that all need to integrate, share data and ultimately speak the same data language.

That shared language is no longer a “nice to have”. As AI matures, it becomes essential. AI is only as good as the consistency and meaning of the data it consumes.

Before looking at how the data model hierarchy has evolved to support this reality, it is worth clearing up a common misunderstanding.

A diagram is not a model

People often use model and diagram interchangeably - but they are not the same thing.

• A model defines meaning, rules, and structure.

• A diagram is simply a visualisation of that model, used to align people.

We’ve all seen the whiteboard sketch that gets called a “data model”. Try handing that to a developer and asking them to build a database from it - it rarely ends well.

With the right tooling, models can be managed properly: diagrams generated, traceability maintained and even deployable code produced. That’s the real value of modelling.

The modern data model hierarchy

At an enterprise level, organisations aim to maintain a single Business Glosary, Ontology & Rules and a single Enterprise Data Model (EDM). Together, these give everyone a shared understanding of what an organisation’s data actually means.

By design, these artefacts are broad. They span every domain in the business. But no single application needs all of that detail. Applications only ever need a subset - and that is where diagrams play an important role. They visualise just the slice of the enterprise models that matters for a specific process or system.

When every application is able to express its data needs using this shared language, governance, integration and interoperability improve dramatically.

Business Glossary, Ontology & Rules

These aren’t data models themselves, but they enable everything that follows. 

The Business Glossary, Ontology and Rules capture an organisation’s shared business language, concepts and behavioural constraints. Ideally, they exist once at an enterprise level and are reused everywhere. They form the governed foundation from which the Enterprise Data Model is built.

Business Glossary (Vocabulary)

• Definition: The foundational level, focused on terms and their unambiguous meaning.

• Purpose: Provides the authoritative, business definitions of all organisational nouns and verbs (e.g., Customer, Order) used by an organisation. It eliminates semantic ambiguity, ensuring all departments reference the same definition within a specific context.

Business Ontology (Concepts & Facts)

• Definition: The structural level, represented as a Business Concept Model of the fundamental business concepts and how they relate to one another (facts). It is built using terms defined in the Business Glossary to identify them.

• Purpose: Defines the structural truth of the business (e.g., "A Customer places an Order"), acting as the necessary requirements to create data models.

Business Rules (Behaviour)

• Definition: The behavioural level, consisting of rules that constrain or guide business activity. They are written using the business concepts defined in the Business Ontology.

• Purpose: Business Rules dictate what the business must or must not do. For example: "A Premium Customer's discount must not exceed 15%" or "The order status must be set to 'Complete' if all items have been shipped".

I highly recommend reading the book by Ronald G. Ross - Business Knowledge Blueprints: Enabling Your Data to Speak the Language of the Business - to properly understand how this should be implemented

Enterprise Data Model

The Enterprise Data Model (EDM) provides a technology-agnostic, organisation-wide understanding of data. It focuses on defining what the data is, not how individual applications choose to store it.

It intentionally avoids system-specific design. Large organisations can’t - and shouldn’t - try to capture every application’s requirements in a single model. Instead, the EDM defines the shared truth.

For example, an HR system may store Date of Birth as an attribute of Employee, while a CRM system stores it on Customer. But the attribute actually belongs to Individual, because a person’s Date Of Birth exists regardless of any role they play. The EDM captures this pure, application-independent truth.

This shared understanding becomes a powerful accelerator for consistent application delivery.

Subject Areas

Subject Areas divide the EDM into logical groupings, making it practical to deliver at scale. They enable federated modelling, where domain experts work independently while following shared standards - ensuring the EDM remains unified rather than fragmented.

Conceptual Data Model (CDM)

• Definition: A technology-agnostic data model of the core business concepts and the relationships between them. It captures the big picture without diving into attributes or keys. 

• Purpose: A CDM diagram of the relevant subset for a business process or application gives business and technical teams a clear, high-level, shared understanding of the data in scope, ensuring alignment before detailed design begins. 

Enterprise Logical Data Model (ELDM)

• Definition: A detailed, technology-agnostic model expanding the CDM concepts into attributes, keys, and fully defined relationships. It reflects the logical understanding of data used across an organisation. 

• Purpose: An ELDM diagram of the relevant subset gives teams a precise understanding of the data using an organisation’s common data language. This forms the foundation for building Application Data Models in a consistent way. 

Application Data Models

Application Data Models are where enterprise meaning meets real-world system behaviour. 

The EDM tells us what the data is. Application models define how a specific system needs to store, query and manage that data.

Starting application modelling from a subset of the EDM keeps systems aligned to enterprise meaning, while still allowing models to be optimised for performance and usage patterns.

Application Logical Data Model (ALDM)

• Definition: The ALDM is the logical design of an application’s data, shaped by its requirements and chosen modelling approach (relational, dimensional, data vault, document, graph, etc.). It defines how an application structures both data-at-rest and data-in-transit to support its query patterns. 

• Purpose: It gives a clear, technology-agnostic definition of tables, attributes, keys, relationships and constraints - even when the choosen application technology(s) won’t, or isn't, enforcing them - so all teams share the same understanding of how an application’s data is structured and can be queried.

Physical Data Model (PDM)

• Definition: The PDM is the technical realisation of the ALDM, adding the technology-specific details such as indexes, partitions, clustering, compression and more. A well-designed ALDM should support multiple physical implementations without needing structural redesign. 

• Purpose: It produces the deployable model code for the chosen technology, ensuring the data structures are implemented correctly and consistently.

Data Traceability

Data traceability - sometimes called vertical lineage - lets you follow a data element through the entire hierarchy: where it came from, how it was designed and how it is physically implemented.

When application models are forward-engineered from enterprise models, traceability becomes a natural by-product rather than a painful afterthought. This significantly strengthens governance, compliance and trust.

Applying the hierarchy to existing applications

Most organisations aren’t starting with a clean slate. Many existing applications were never built using this hierarchy and rebuilding them simply isn’t realistic.

The good news is that you don’t have to.

By reverse-engineering the missing models and linking them back to the EDM, even legacy systems can begin to “speak” the enterprise data language. Over time, this allows cleaner, enterprise-aligned interfaces to be exposed - without touching the internals of the system.

Data Model RACI

The RACI below illustrates the roles typically responsible for creating and maintaining the different artefacts in the data model hierarchy.

Conclusion

A strong data model hierarchy is the foundation for consistent, trustworthy and interoperable data.

When every application is anchored to a shared enterprise understanding, integration becomes simpler, delivery becomes faster and data becomes far more reliable.

This matters even more in an AI-driven world. AI depends on clean meaning, consistent structure and reliable context. Without those foundations, even the best platforms and models struggle.

When data is modelled well, everything built on top of it becomes simpler, clearer and far more scalable.