Fragmented data estates usually share a trait – there’s no consistent representation of core business entities.
It’s a common thread I’ve seen – system-centric entities and attributes, then another solution which recreates these in its own unique way. Different systems talking different languages make integrations messy and bespoke. It’s a technical mess, and it doesn’t make for happy engineers. Trust me.
Here’s where a standardised representation of these entities helps – a Canonical Data Model for an organisation.
It’s an obvious solution from a technical perspective, but achieving this draws out:
- Teams disagree on the entities and attributes
- Lines of ownership are blurred across teams
- Accountability becomes contentious
- Faster delivery trumps enterprise consistency
Your buying team sees a product as a contract with a supplier, cost price, and margin, focusing on sales volumes. Your warehouse team sees the product as an item with dimensions, a barcode, and stock levels, requiring replenishment planning. The same entity, with differing perspectives.
Agreeing on a common representation is a People problem, not a technical one.
But selfishly from a technical perspective, this is really useful for us. A canonical model provides a consistent representation, reducing bespoke mappings and repetition across legacy systems. If you’ve repeatedly mapped different interpretations of the same attribute across systems, this will sound utopian.
So whilst a technical team can’t solve the problem directly, there are ways to support:
- Carefully choose the starting point – blank slates aren’t always a good starting point. Use a core system, or leverage existing frameworks such as the Common Data Model, especially if you’re invested in Dynamics
- Do the legwork up front – for more bespoke (or opinionated) organisations, start with a consolidation from existing technical solutions. Use this as a baseline to iterate from, or focus conversations around specific decisions and pain points
- Management tooling shouldn’t be a blocker – the ability to manage the data shouldn’t be a point of friction, options should be well understood based on existing applications and integrations. Master Data Services was a low-effort option prior to its unfortunate removal in SQL Server 2025
Essentially you want a head-start so there’s already momentum. The reality is these initiatives often fail due to lack of traction.
Establishing a Canonical Data Model is a People problem at its core. But the payoffs can be very much technical. If you’re on the technical side of these decisions, arrive early, arrive prepared, and grease the wheels to make sure it arrives smoothly.
Andy Brownsword 