- A common data model is a governed shared specification for selected data, including names, formats, structures, and relationships.
- Useful scope is bounded by a business domain or defined use cases. One global model is rarely the best starting point.
- Common and canonical data models address related needs, though organizations and standards may use the terms differently.
- Mappings, ownership, review, governed metrics, and business context need active governance across the CDM and analytics layers.
Your teams can agree on what “customer” means in a meeting, then implement that meaning differently across warehouses, applications, pipelines, and reports. Soon, every new integration or metric review starts with the same debate: which definition applies here?
A common data model gives participating teams and systems a governed specification for selected business data. It defines shared names, formats, structures, and relationships without requiring every source to use the same schema or database. This guide covers the model’s core components, its relationship to a canonical model, a bounded implementation workflow, and the governance needed for analytics.
What a Common Data Model Means for Your Business
A common data model, or CDM, creates an agreed representation of selected data across a defined group of participants. Those participants might include applications, business domains, data products, partners, analytics teams, or downstream consumers.
NICHD and MITRE’s common data model definition says a CDM standardizes definitions, formats, and model content across participating data partners. Their report addresses a research and data-linkage context. Enterprise implementations vary, but the central idea travels well: participants agree on how specified data should be understood and represented.
Consider a Customer concept shared across sales, finance, support, and analytics. Each source can retain its operational structure, while the CDM documents the agreed definition, identifiers, attributes, and relationships used for selected exchanges or analyses.
The model does not settle every source-ownership question or repair weak records. It also does not replace every physical schema. Its practical value comes from giving participating teams a shared reference they can map to, review, and maintain.
The Value Is Shared Meaning Within a Clear Boundary
Scope makes that shared meaning governable. When your team names the domain, use cases, producers, and consumers, you can discuss definitions without drifting into every possible enterprise scenario.
The right phrase is often “shared semantic reference.” Consistent interpretation depends on accurate mappings, active stewardship, and participant adoption. With those pieces in place, teams have a clearer basis for reviewing integration logic and analytics definitions.
Boundaries also make disagreement easier to handle. Finance and sales may use different Customer definitions for valid reasons. A CDM can document the definition used for a specific exchange or decision, along with known exceptions, instead of forcing false consensus.
Core Components of a Common Data Model
A useful CDM combines business meaning with enough structure for systems and teams to apply it. A dictionary is the starting point, since it names and defines terms, but a full model also describes how those terms relate.
NIST presents one shared dictionary and mapping pattern in its additive manufacturing work. The pattern starts with a common data dictionary, adds a hierarchy of terms, and supports mappings to implementation formats. This is a standards-based case pattern, not a required sequence for every enterprise.
A related NIST case describes model structure and relationships among key concepts and terms. The example reinforces a useful distinction: a list of definitions helps, but the model also needs entities, attributes, relationships, and mappings.
Your implementation could appear in logical models, schemas, APIs, events, files, or semantic models. For the semantic consumption layer, teams can also use ThoughtSpot Models to create governed reusable data models. ThoughtSpot is one option, not a requirement for building a CDM.
A Practical Component Checklist
| Component | Question It Answers | Typical Governance Owner |
|---|---|---|
| Shared vocabulary | What does each business term mean? | Domain steward or business owner |
| Entities and attributes | What concepts and properties are in scope? | Data architect and domain expert |
| Relationships and hierarchy | How do the concepts connect? | Data architect and model owner |
| Source and consumer mappings | How does each implementation map to the model? | Data engineering or integration owner |
| Metadata and governance | Who approves, versions, and reviews changes? | Model owner and governance group |
These owners are examples, not fixed roles. What matters is that each decision has a named person or group, with a visible route for review and change.
Common Data Model vs. Canonical Data Model
This article uses “common data model” for the broader shared specification covering definitions, structures, and relationships. A canonical data model commonly refers to an integration pattern where systems map into and out of one intermediary semantic representation.
NIST’s Smart Grid framework describes this canonical model mapping pattern as a representation that other semantic models can map into. Terminology varies across organizations, vendors, and standards, so document your team’s usage before design work begins.
| Area | Common Data Model | Canonical Data Model |
|---|---|---|
| Primary purpose | Shared meaning and representation | Intermediary representation for mappings |
| Typical scope | A governed participant group or domain | Systems within an integration pattern |
| Mapping pattern | Participants adopt or map selected concepts | Systems map into and out of the canonical representation |
| Physical implementation | Can inform several formats and platforms | Often sits between source and consumer representations |
| Governance focus | Definitions, relationships, ownership, and reuse | Mapping rules, compatibility, and version control |
The concepts can overlap. A canonical representation may sit within a broader common-model program, especially when the program addresses both shared meaning and system exchange.
A Simple Way to Choose the Right Term
Use “common” when your main concern is shared definitions, structures, and relationships across a governed participant group. Use “canonical” when the primary concern is an intermediary representation for integration mappings.
If your architecture needs both, name both layers and assign clear owners. That language gives reviewers a better starting point than treating the terms as interchangeable or assuming an industry-wide definition.
A Practical Workflow for Implementing a Common Data Model
A pragmatic rollout starts with a problem you can name and a boundary you can govern. The following workflow interprets the standards-based patterns above for enterprise teams. It is guidance, not a prescribed standard.
Select one domain and its use cases. Choose a domain such as customers, orders, products, or finance. List the decisions, data exchanges, and analytics questions the model should support.
Name the participants and decision rights. Identify producers, consumers, owners, stewards, and reviewers. Write down who approves definitions, mappings, exceptions, and changes.
Define the shared vocabulary and structure. Document priority terms, entities, attributes, relationships, grain, and relevant hierarchies. Keep the first version tied to the selected use cases.
Map sources and consumers. Inventory participating systems, then document source-to-model and model-to-consumer mappings. Teams using ThoughtSpot can connect your data sources as part of their broader modeling and analytics workflow.
Test exchanges and analytics definitions. Use representative cases, including conflicting meanings and edge conditions. Test business interpretation alongside format and structure.
Publish governance and expansion rules. Record ownership, versioning, review steps, exceptions, and adoption guidance. Expand when shared definitions and reuse justify the added governance work.
Each step should produce something reviewable: a scope statement, participant list, dictionary, relationship diagram, mapping register, test cases, or change log. If teams disagree, record the competing definitions and choose the bounded meaning for the active use case.
Before expansion, check that owners are named, use cases are agreed, participating systems are mapped, and definitions have been tested. You also need a review cadence, since a model that nobody revisits will drift from the business it describes.
Start With a Bounded Domain
A strong first domain matters to the business, remains narrow enough to govern, and has identifiable producers and consumers. Good candidates often have recurring definition conflicts, repeated mappings, cross-team analytics demand, and available domain owners.
Data availability alone is a weak selection rule. Tie the scope to a real decision, exchange, or analytics use case. That connection gives reviewers a practical basis for deciding what belongs in the model.
Map, Test, and Document Exceptions
Make source-to-model and model-to-consumer mappings explicit. Review unit differences, status definitions, grain, time logic, null handling, and relationship cardinality because structural agreement can hide semantic conflict.
Keep exceptions visible in an exception register. A source may use a valid local definition that does not fit the shared model cleanly. Documenting that difference is more useful than pretending every system aligns perfectly.
Governance and Analytics Need the Same Business Context
A model becomes operational when people know who decides, who reviews, and how changes move through the participating systems. Governance should cover definitions, mappings, access expectations, versioning, exceptions, and recurring review.
The NSA’s guidance on data governance decision rights discusses accountability, control and access, and ongoing review of standards. For a commercial enterprise, these are design considerations rather than a legal or compliance checklist.
Your CDM can define shared entities and relationships, while a semantic layer adds governed metrics, calculation rules, synonyms, and analytical context. A context layer can carry that meaning further by assembling the business definitions and rules needed by analytics consumers and agents.
Teams can bring governed definitions into day-to-day analysis through their chosen analytics workflow. ThoughtSpot’s analytics workspace for data teams is one example to consider. Your CDM can use other tools and architectures as well.
Govern Definitions, Mappings, and Change Together
Your governance checklist should name the model owner, stewards, approval rights, access expectations, version policy, mapping owners, exception process, and review cadence. Each item answers a different question, so leaving one implicit can create gaps later.
Review the shared definition and its implementation mappings together. When either changes, record the reason and identify affected producers, consumers, reports, and metrics. This practice makes drift visible before teams quietly adopt competing versions.
Carry Governed Meaning Into Analytics
Analytics teams need more than consistent field names. They also need metric definitions, calculation logic, grain, filters, time rules, and approved business terminology.
Revenue offers a simple example. Two sources may align structurally while reports still differ because one calculation includes adjustments or uses a different period. The CDM supplies shared concepts and relationships, while the semantic or context layer carries the governed analytical meaning used by people and agents.
Build the Smallest Common Model Your Teams Can Govern
A broad vision matters less than a common data model your participating teams can define, map, test, own, and review. Start with one domain, document its use cases and owners, agree on vocabulary and relationships, then test the mappings and analytics definitions.
Expand when reuse and governance capacity support the next step. Your next move is simple: bring the domain owner, data architect, integration lead, and analytics lead together to draft the scope and decision-rights map.
