Master data model design is meant to bring clarity. Yet in many organizations the three layers of the model, conceptual, logical, and physical, are blended together until no one is entirely sure what they are looking at. Executives are shown diagrams packed with attributes and keys. Architects debate table structures before the business has agreed on what a customer actually is. Stewards are handed platform specific models and told they represent the business view.
When these layers collapse into one another, confidence drops. What should be a shared understanding turns into a fog of mixed terminology, mismatched expectations, and unnecessary rework.
This blog post separates the three layers of master data model design and explains how each one serves a different purpose, a different audience, and a different decision point. By keeping them distinct and using each layer at the right moment, you strengthen alignment, accelerate delivery, and increase the credibility of your MDM program.
Why mixing UP the three layers is a problem
I have often seen the conceptual model treated as if it were the logical model and presented to executives in a form cluttered with attributes, keys, and technical jargon. The effect is predictable. Executives disengage, lose sight of the “why,” and begin to view MDM as an IT driven exercise rather than a business capability.
I have also seen situations where the logical model is skipped entirely in favor of the physical model. Teams jump straight from “we have customers and products” to “here is the table structure in the MDM hub.” It may seem efficient at first, but it leads to modelling what is already known rather than what the business and its processes actually require. Data stewards and architects lose the shared, business aligned blueprint they depend on. The result is rework, misaligned rules, and endless debates about what a customer really is.
And then there are cases where the physical model is presented as if it were the conceptual view. Platform specific tables, columns, and match rules are used to explain “what MDM is” to business stakeholders. The impact is severe. Confidence drops. Stewards feel excluded, executives feel overwhelmed, and the architecture appears fragile instead of intentional.
An Example of the three modelling layers
Reading on
Most organisations classify data before they’ve modelled it. They tag fields, assign sensitivity levels, and enforce access controls — all without agreeing on what the data means. The result? Classification becomes a technical artefact, not a business capability.
But classification is not a security task. It’s a modelling discipline. And unless it’s grounded in conceptual clarity and logical behaviour, it will fail — no matter how well it’s implemented.
This post explores why modelling must come first — and how a layered approach transforms classification from checkbox to strategic asset.
Leave a Reply