Most Silver layers are full of cleaned tables, standardised formats and automated transformations. But that is not where the real value sits.
The real value of Silver is that it turns business decisions into reusable enterprise meaning.
That is why a canonical model is not just a shared schema between applications. It is the organisation’s shared understanding of its business, expressed in a form that people, processes, applications, analytics and AI can use consistently.
Technology can transform data. Only the business can define meaning. Canonical models are therefore about governed semantics, not just integration.
Why Canonical Models Are About Governance, Not Integration
In my previous article, I argued that canonical models belong in the Silver layer of a medallion architecture, not because Silver is where data is transformed, but because it is where enterprise meaning is established.
That naturally raises the next question: What actually makes a canonical model canonical?
Many architects still see it as a technical artefact: a common schema for exchanging data between systems. That made sense in the days of Enterprise Service Buses (ESBs), where applications translated their own formats into a shared XML message.
Today, that definition is no longer enough. A canonical model is not only an integration contract. It is a business contract.
Silver Isn’t Where Data Gets Clean
Most explanations of medallion architecture describe the Silver layer in technical terms: clean the data, standardise formats, remove duplicates and apply business rules.
None of that is wrong. But it misses the most important point: every transformation in the Silver layer represents a business decision.
Questions such as these cannot be answered by technology alone:
- What makes someone a customer?
- Which supplier record should take precedence when two systems disagree?
- Can an inactive customer still receive invoices?
- When should two products be treated as the same product?
- Which address is considered the official one?
- How should legal entities relate to trading brands?
These are not technical questions. They are business decisions that the data pipeline merely automates.
A Canonical Model Captures Those Decisions
Canonical models are often described as common data structures. That is incomplete. The structure exists only because the organisation has answered questions about meaning, ownership and policy.
When a canonical Customer contains attributes such as Legal Entity, Trading Name, Global Ultimate Parent, Customer Status and Primary Address,
they are not simply columns in a table.
Each one reflects a decision about:
- what the organisation considers important,
- how business concepts are defined,
- which system is authoritative,
- how conflicting information is resolved,
- who is responsible for maintaining it.
Without those decisions, a canonical model is just another database schema.
Governance Defines the Semantics
This is where many data programmes lose their way. They ask the integration team to design the canonical model. But integration specialists cannot decide what a customer is. Nor should they. Those decisions belong to business domains operating within a governance framework.
Only the business can define:
- what constitutes a customer,
- which attributes are mandatory,
- who owns each attribute,
- how quality should be measured,
- when exceptions are acceptable.
Governance does not equal the canonical model. Governance defines the framework for business concepts, ownership, rules and semantics. The canonical model is one representation of those concepts, shaped for consistent use across systems, analytics, processes and AI.
Many organisations have strong governance without a canonical model. Others have canonical models with weak governance. The relationship is better understood as: Governance – Business semantics – Canonical model – Implementation.
Integration Is No Longer the Only Consumer
Historically, canonical models were introduced to reduce system integration complexity.
That made sense when applications were the primary consumers.
Today, the list is much broader.
Canonical models now support data products, analytics and reporting, artificial intelligence, APIs,event-driven architectures, master data services and digital twins.
These consumers do not care how SAP, Salesforce or Microsoft Dynamics represent a customer. They care about the enterprise definition. Integration is often still the primary operational consumer, and in many organisations it remains the reason the investment is made. But it is no longer the only consumer.
Bronze Stores Facts. Silver Stores Decisions. Gold Delivers Perspectives.
A simple way to think about the medallion architecture is this:
| Layer | Purpose |
| Bronze | Preserve source data exactly as it was received. |
| Silver | Apply governance decisions to create consistent enterprise meaning. |
| Gold | Present curated views designed for specific business needs. |
This is why canonical models belong in the Silver layer. Not because Silver transforms data, but because Silver is where the organisation decides what its data means.
Deeper into the concept on Canonical Models
If you want to go deeper into the concept, structure and practical use of canonical models, you can read much more here:
Leave a Reply