The same customer may be represented as customer_id in one system, partner_number in another and account_id in a third. The difference, however, may go far beyond naming. One system may mean the contracting party, another the bill payer, and the third a registered user.

Within a single application, these local meanings are usually sufficient. Once we integrate data, produce reports or build AI solutions on top of it, we need a shared answer to a deceptively simple question:

What do we mean by a customer?

A Canonical Data Model does not answer this with yet another technical format. It creates a shared language between business concepts, data models, physical platforms and the use of information.

A shared model is not a shared database

The purpose of a canonical model is not to make every system use the same tables, field names or technologies. Each application still has its own purpose, lifecycle and optimal internal structure.

The shared model is a stable and, as far as possible, technology-independent contract. It:

  • defines the important business concepts;
  • describes the relationships between them;
  • captures the rules needed to interpret them;
  • and makes it possible to verify how source and target systems relate to them.

In an integration environment, this often means a neutral structure to which sources and targets can be mapped independently. In enterprise data architecture, it may play a broader role: connecting the business glossary, logical models, physical platform structures, data flows and analytical meaning.

In this article, Canonical Data Model refers to this broader semantic backbone. It does not mean a vendor’s pre-built data model or a single enterprise-wide schema intended to contain everything.

One meaning, five perspectives

Shared meaning does not emerge in a single step. The same concept needs to be described from several perspectives, while the relationships between those perspectives must also be preserved.

  1. 01BusinessWhat does it mean?
  2. 02LogicalHow is it connected?
  3. 03PhysicalWhere and how does it exist?
  4. 04MappingHow does it correspond?
  5. 05AnalyticsHow does it become information?

1. Business — where meaning begins

The first model is not about tables. It clarifies the things, events and rules the organisation talks about.

Alongside “customer”, for example, we also need to define:

  • whether the term refers to a person or a legal entity;
  • the role in which that party relates to the organisation;
  • what makes a customer active;
  • how many contracts or accounts may belong to one customer;
  • and which events can change the customer’s status.

At this level, the business definition, ownership and decision rules matter more than the technical representation. A strong starting point consists of statements understood in the same way by business and technology participants.

2. Logical — the structure of meaning

The logical model turns business concepts into entities, attributes, identifiers, relationships and rules. It is still not designed for a specific database. It describes the data structure capable of carrying the shared meaning consistently.

This is where we can see whether a customer is an entity in its own right or a role played by a person or organisation; how it relates to a contract; which identifiers belong to it; and which relationships need to be tracked over time.

One of the most important qualities of a logical model is that it makes meaning open to discussion and verification. A relationship, cardinality or mandatory attribute no longer remains an unspoken assumption.

3. Physical — implementing the meaning

The same logical model can be implemented in several physical forms.

An operational application may use normalised relational tables. An event-driven integration may transmit messages. A lakehouse may store data in columnar files. A data warehouse may use Data Vault structures, while the analytical layer applies a star schema.

These are not competing truths. They are physical perspectives optimised for different tasks. Their connection comes from being traceable to the same logical meaning.

The physical model therefore includes technology-specific decisions such as data types, keys, partitions, storage and performance solutions. These may change without redefining the business meaning of “customer”.

4. Mapping — where the models meet

Mapping is not administration performed after the design. It is what makes it possible to prove that shared meaning survives the full journey of the data.

A usable mapping shows:

  • which source field corresponds to which canonical attribute;
  • what transformation takes place;
  • how code values are translated;
  • how missing or ambiguous data is handled;
  • which rule and version applied at a given point in time;
  • and how the data continues into the target model.

If a CRM uses ACTIVE and an ERP uses A for what appears to be the same status, the shared model alone has not resolved the question. The mapping records whether they truly mean the same thing, under which conditions they correspond, and what their canonical value should be.

Mapping is therefore an integration specification, a data-lineage connection and a testable professional rule at the same time.

5. Analytics — when data becomes information

An analytical model has a different task from an integration or transactional model. It must answer decision-making questions clearly and consistently.

The canonical model therefore does not replace the semantic layer, dimensions, facts or KPI definitions. It gives them a stable foundation of meaning.

The metric “number of active customers”, for example, is comparable only when we have clarified:

  • what counts as a customer;
  • which roles are included;
  • the point in time to which activity refers;
  • how merged or duplicated identifiers are handled;
  • and which events change the status.

At this point, analytics does not invent a new meaning. It organises the agreed meaning into a perspective that supports decisions.

A short example: three systems, one customer concept

Suppose data arrives from three systems:

  • the CRM manages the sales relationship;
  • the billing system records the paying party;
  • the web interface identifies the registered user.

The canonical model does not declare that all three records automatically represent the same customer. Instead, it provides shared concepts and relationships: Party, Customer Role, Account, Contract and their identifiers.

The mapping layer then describes which concept each system record relates to and under which rule. The analytical model can build customer, contract and activity metrics on this verifiable network of relationships.

The value of a shared language becomes tangible here: systems do not need to be identical for their data to be used together consistently.

What keeps the model usable?

Begin with a clearly defined domain

A shared model can grow gradually. One business domain, an important data flow or a decision-making question is a strong enough starting point. Experience from actual use can guide the addition of new concepts and relationships.

Give it ownership and a lifecycle

Concepts, rules and mappings change. Versioning, ownership and impact tracking are therefore parts of the model. A canonical model is not a diagram produced once; it is a managed professional product.

Treat connections as seriously as models

Business, logical, physical and analytical perspectives can each be precise in isolation. The full system becomes consistent when the mappings between them are also visible, verifiable and maintainable.

Leave room for purpose-specific models

An integration message, a Data Vault layer and a star schema serve different purposes. The shared model does not erase these differences. It ensures that each of them remains connected to the same meaning.

The essential point

A Canonical Data Model is not shared because every piece of data is collected in one schema. It becomes genuinely shared by giving the organisation’s important concepts common meaning, clear relationships and verifiable mappings.

The journey is therefore more than a sequence of technical transformations:

Business → Logical → Physical → Mapping → Analytics

It is the story of how meaning is preserved from the business question to usable information.

Sources and further reading