Back to Catalog
Integration
Message Transformation
Canonical Data Model
Agree on one shared data language — translate to/from it at every integration boundary.
Intent & Description
Real-world Use Case
Enterprise customer data hub — 8 systems (CRM, ERP, billing, support, analytics, mobile, web, partner portal) all exchange customer data. Canonical CustomerProfile model defined. Each system has 2 translators. Total — 16 translators vs 56 point-to-point. Future 9th system — add 2 translators, not 8.
Source
📌 TL;DR
Canonical Data Model = the shared language of your integration layer. Translate once to canonical, translate once from canonical. O(N) translations instead of O(N²). Hard to design, massive long-term payoff.
Advantages
- Reduces translation complexity from O(N²) to O(N)
- Single place to evolve the shared data language
- New systems only need to implement 2 translators, not N
- Creates a stable integration contract independent of any single system
Disadvantages
- Canonical model design is a major upfront investment — requires domain expertise
- Canonical model can become the lowest common denominator — losing source richness
- Organizational alignment needed — all teams must agree on and adopt the model
- Canonical model evolution requires coordinated updates across all translators