The Right Way to Use Canonical Models: Three Lessons from the Field
Published at: 2/16/2026
Author: Danijel Buljat
Data standardization is one of the most tempting ideas in enterprise architecture. The promise is elegant: instead of maintaining dozens of different integrations between your systems, create one standard data format that everything uses. One language. Clean connections. Order from chaos. Many insurance companies invest millions in this vision. And many discover, often too late, that they've built something that looks perfect in diagrams but struggles in practice. The problem isn't canonical models themselves. It's where and how companies use them. Let me share three lessons that can help you get real value from standardization without the common pitfalls.
Lesson 1: Canonical Models Work Best at the Boundaries, Not Inside Systems
The Pattern We See
Here's a common scenario: A company decides to standardize everything using ACORD, the insurance industry's data standard. They implement it across their CRM, policy administration, billing, and claims systems.
ACORD is comprehensive, a customer record can have 847 fields covering every insurance scenario imaginable. Your personal auto insurance CRM might need 50 of those fields. The other 797 sit empty.
Fast forward two years:
• Queries run slower because databases are scanning through mostly empty fields
• Sales teams complain about navigating through irrelevant screens
• Finance can't get reports in the format they need
• Teams start building workarounds and maintaining shadow systems
The canonical model technically works. But people avoid using it because it doesn't fit how they actually work.
A Better Approach
Think of canonical models as translation hubs rather than universal storage formats.
Each system should store data in the format that makes it work best:
• Your CRM stores customer data the way that helps sales teams work efficiently
• Your policy system stores data optimized for underwriting and rating
• Your claims system organizes information for fast adjudication
The canonical model sits at the integration points. When systems need to communicate, they translate:
CRM (native format) → translate to canonical → Policy System receives canonical → translates to its native format
This approach gives you two advantages:
1. Each system performs well because it's optimized for its purpose
2. When you replace a system, you only rewrite one integration instead of six
The canonical model becomes your insurance policy against vendor lock-in, which insurance companies should appreciate.
Lesson 2: Use Industry Standards Strategically
External vs Internal Integration
ACORD works beautifully for certain scenarios:
External partners: Brokers, reinsurers, and regulators expect ACORD. They've built their systems around it. Use full ACORD here.
Regulatory reporting: Regulators require specific formats. Give them exactly what they want.
For internal integration, you have more flexibility. You can create an "ACORD-inspired" model that keeps the useful concepts but removes what you don't need.
An 80-field customer model that covers your actual business is better than an 847-field standard where most fields are always empty.
The Multi-Line Challenge
If you offer both life insurance and property & casualty, you face an interesting challenge. ACORD has separate standards for each (ACORD Life and ACORD P&C), with different structures and terminology.
How do you answer: "What's the total value of customer Maria Svensson across all our products?"
You can't, not with just the two separate ACORD standards.
You need an enterprise aggregation layer:
P&C systems → ACORD P&C format → Enterprise Model → Analytics Life systems → ACORD Life format → ↗
The enterprise model knows how to combine information from both domains. It includes fields that ACORD doesn't have: household relationships, total customer lifetime value, cross-product analytics.
This is more complex than a single standard. It's also realistic. Trying to force life and P&C products into one format creates compromises that serve neither business well.
Lesson 3: Borrow Concepts Across Standards
The CRM Example
ACORD P&C wasn't designed for customer relationship management. It models insurance transactions (policies, claims, payments) not the long-term customer relationships that CRM systems need to track.
Here's an interesting solution: borrow from ACORD Life.
ACORD Life has richer relationship models because life insurance involves longer timeframes. Estate planning, beneficiary structures, multi-generational thinking. Those relationship concepts work beautifully for P&C customer management too:
• Household structures
• Family relationships
• Corporate hierarchies for commercial accounts
Your customer model might look like:
• Party (ACORD P&C concept)
• Relationships (ACORD Life structure)
• Contact preferences (ACORD Life detail)
• Your custom fields (customer segment, lifetime value)
You're not following either standard completely. You're taking the best concepts from both and adding what your business needs.
This is "ACORD-inspired" rather than "ACORD-constrained."
What This Means in Practice
For Direct System Integration
If you have Dynamics CRM talking to Guidewire policy administration, both are internal systems with good APIs. A direct integration with thoughtful field mapping often works better than inserting a canonical layer between them.
Save canonical models for:
• Integration platforms that connect ten different systems
• Data warehouses that consolidate information
• API layers that external partners use
For Data Streaming
When streaming data to a data lake, you don't need to transform everything into a standard format at the storage layer. Keep events in their native format. Transform when you query across systems.
Your streaming topics can carry:
• CRM data in CRM format
• Policy data in policy format
• Claims data in claims format
Build canonical views downstream in your analytics layer, where you're actually combining information.
The Costs of Getting This Wrong
Large insurers have spent 50 million kronor or more on comprehensive standardization programs. That includes architect time, platform licensing, vendor consulting, system modifications, testing, and training.
Those are just the direct costs. The indirect costs include:
• Systems that run slower than they need to
• Reports that take longer to generate
• Employees working around official systems
• Missed opportunities while IT manages complexity
Companies that use canonical models strategically spend a fraction of that amount. They standardize at integration points and for external interfaces, not everywhere.
Questions to Ask Before You Start
If someone presents a canonical model proposal, here are useful questions:
Where does translation happen?
If it's at the integration layer, that makes sense. If it's in the storage layer, reconsider.
What's the vendor independence strategy?
If you can swap systems by changing one integration, that's valuable. If you'd need to rewrite everything anyway, the canonical model isn't delivering value.
Where are you using industry standards?
For external partners and regulatory reporting, absolutely. For internal CRM operations, explain why you need hundreds of empty fields.
How are you handling multiple business lines?
If you're forcing life and P&C into one format, that's a warning sign. If you're building an enterprise layer on top of domain models, that makes sense.
What are you NOT standardizing?
If the answer is "everything eventually," you might be about to spend a lot learning why that doesn't work.
What Success Looks Like
The most successful insurance companies aren't the ones with the most elegant data architecture in PowerPoint.
They're the ones whose systems help employees do their jobs efficiently. Whose reports run fast enough to support timely decisions. Whose integrations work reliably without constant maintenance.
Sometimes that requires canonical models. Sometimes it doesn't.
The skill is knowing the difference and having the discipline to use standardization as a tool for specific problems rather than a universal solution.
The Key Insight
There isn't one universal truth in enterprise data. There are different perspectives for different purposes:
• Sales truth (leads, conversion, customer engagement)
• Underwriting truth (risk assessment, pricing, exposure)
• Claims truth (loss patterns, reserves, settlements)
• Finance truth (revenue, reserves, combined ratio)
The question isn't how to make them all identical. The question is how to let them coexist while still communicating effectively.
That's what canonical models should enable: communication between different perspectives, not enforced uniformity.
When used this way (at interfaces, for vendor abstraction, for external communication) canonical models deliver real value. They reduce integration complexity, increase flexibility, and protect against vendor lock-in.
When used everywhere as universal storage formats, they create expensive, slow systems that people work around.
The difference is worth understanding before you spend millions learning it the hard way.