Common Data Model Tools: Design It, Document It, or Enforce It?

Search “common data model tools” and you get three different conversations. One is about Microsoft Dataverse. One is about OMOP in clinical research. The third is a governance catalog page explaining how a business glossary creates a shared language.

All three are valid. None of them answers the question a data leader is usually asking: how do I get forty systems to agree on what a customer is, and keep them agreeing when those systems change next quarter?

That question has a design half and a runtime half. Most tools cover one. This piece maps the category so you can see which half each tool owns.

What Is a Common Data Model (CDM) in Data Integration?

A common data model is a standardized schema for core business entities, such as customer, product and transaction, that data from many sources is mapped into so every downstream system reads the same structure.

Microsoft, which published one of the best-known CDMs, describes it as “a standardized, modular, and extensible collection of data schemas” that provides “a shared data language for business and analytical applications to use” (Microsoft Learn).

Three terms get mixed up here:

• Common data model vs. “data model” in general. A data model in data engineering is a schema. In data science, “model” usually means a statistical or ML model. If you landed here looking for the most common data science models, this is not that.
• Common data model vs. canonical data model. These are close cousins. The Enterprise Integration Patterns book defines a canonical data model as one “independent from any specific application,” and requires “each application to produce and consume messages in this common format” (Enterprise Integration Patterns). In practice, “canonical” is the integration architect’s word and “common” is the vendor and industry word.
• CDM vs. semantic layer. A semantic layer defines metrics and business meaning on top of data (what “net revenue” means). A CDM defines the structure the data arrives in. You want both, and they work best when they share definitions.

There are also industry CDMs you can adopt instead of designing your own:

• OMOP CDM in healthcare, “an open community data standard, designed to standardize the structure and content of observational data” (OHDSI).
• Microsoft Common Data Model, influenced by Dynamics 365 schemas; Microsoft notes “If you are a customer or a partner using Dynamics 365, you are already using Common Data Model” (Microsoft Learn).
• Pega Common Data Model, which Pega describes as able to “provide the data and integration layer for your Pega application,” built around entities like Account and Contact (Pega Academy).

Why Common Data Models Matter for Integration and Governance Together

A CDM cuts the number of mappings you maintain and gives governance one place to attach definitions and policy, but only if the same model is used in both places.

The integration math is simple. Without a shared model, every system that talks to every other system needs its own translation. Enterprise Integration Patterns spells it out: six applications need “30(!) Message Translators without a Canonical Data Model” and “only 12 Message Translators when using a Canonical Data Model” (Enterprise Integration Patterns). That is n x (n-1) against 2 x n. At 40 systems it is 1,560 against 80.

The governance case is about consistency. If “customer” is defined once, then access rules, PII handling, lineage and quality checks can be defined once too.

Here is where the market splits. Catalogs govern but do not move data. Integration tools move data but often leave definitions in someone’s spreadsheet. So you end up with a beautifully documented model in one tool and pipelines in another tool that do not know it exists.

I have seen this pattern too many times. The glossary says one thing, the pipeline does another, and nobody finds out until a dashboard and a finance report disagree.

Types of Common Data Model Tools

There are four types: modeling tools, governance catalogs, vertical CDM standards, and integration platforms that enforce a CDM at runtime.

1. Modeling and design tools (erwin Data Modeler, ER/Studio). These are where architects draw the model. erwin, now owned by Quest Software, lets you build a logical model “that is not dependent on a specific database technology,” then forward engineer the DDL “required to instantiate the schema” (Wikipedia: erwin Data Modeler). IDERA describes ER/Studio as “the essential cross-platform data modeling tool” (Teradata partner page). Both are strong at design. They produce schemas, not pipelines, so you still need something to map live data into them.
2. Data catalogs and governance platforms These manage metadata, glossary and policy. Alation, for example, positions itself as a “data intelligence platform” covering metadata management, lineage, glossary and stewardship (Alation Docs). In a catalog, the CDM lives as a documented reference: definitions, owners and policies. Catalogs are not where pipelines run, so the model still has to be applied to the data somewhere else.
3. Vertical and ecosystem CDMs (OMOP, Microsoft CDM and Dataverse, Pega). These are prebuilt models, not tools in the usual sense. They are excellent when you live inside that domain or ecosystem. Dataverse, for example, ships standard tables where customer data “is intended to be stored using the account or contact tables,” and those standard tables cannot be deleted (Microsoft Learn).
4. Integration platforms with built-in CDM enforcement (Nexla, Workato). These map source data into the model while it moves, so the CDM is not a diagram but the actual shape of the data arriving downstream. They differ a lot in depth, which the next section covers.

Common Data Model Tools Compared: Modelers vs. Catalogs vs. Integration Platforms

Modeling tools design the model, catalogs document it, Workato uses it inside specific connectors, and Nexla enforces it on data in motion across sources.

Tool	Primary role	Schema enforced in pipelines?	Handles schema drift?	Governance attached to the model?	Source
Data catalogs (e.g. Alation)	Metadata, glossary, policy	Not described	Not described	Yes, as metadata and stewardship	Alation Docs
erwin / ER/Studio	Model design, DDL generation	No, generates schemas	Not described	Not described	Wikipedia
Workato	iPaaS with data models	Yes, in supported connectors	Not described	Not described	Workato Docs
Microsoft CDM / Dataverse	Prebuilt ecosystem model	Inside Microsoft apps	Not described	Inside Microsoft apps	Microsoft Learn
Nexla	Data integration with CDM	Yes, mapped in flight	Yes, automatic detection	Yes, lineage, access and PII rules	Nexla

A few notes on reading that table.

Data catalogs are strong at what they are built for: stewardship, glossary terms and lineage metadata. What comes into a catalog is metadata about the data. The pipelines that shape the data still run somewhere else.

Workato has a real CDM feature: “a standard schema that organizations define to simplify data flow.” Its docs also say data models can currently be used only in the Java messaging service connector and the Mapper connector (Workato Docs). Useful for app-to-app workflows, narrower for analytics and data products.

erwin and ER/Studio are where many enterprise CDMs are born. Keep them if your architects love them. Just plan for a separate system to operationalize what they design.

How Nexla Implements a Common Data Model Differently

In Nexla, the CDM is enforced where data moves: sources are auto-mapped to shared entity templates, schema changes are detected on every ingest, and governance rules travel with the data product.

Here is how it works, in Nexla’s own terms.

• Shared entity templates. Teams “establish standardized structures for common business entities like customers, products, transactions, and events” (Nexla).
• Automatic mapping. Nexla’s mapping engine “automatically understands incoming data and maps it to your CDM structure” (Nexla).
• Nexsets as the CDM layer. Nexla “automatically creates Nexsets, virtual data products that make any data ready to use and reuse” (Nexla). Schemas bind to Nexsets and evolve with them (Nexla Docs).
• Drift handling. “Each time Nexla ingests data from a data source, it not only reads the data but also analyzes it.” Minor changes update the existing Nexset schema; significant changes create a new detected Nexset, and the change is logged with notifications to email, Slack or webhooks (Nexla Docs).
• Governance on the object, not in a separate tool. Lineage is built in, access is controlled “through centralized policies,” and Nexla “detects and tags PII, and provides built-in data masking and hashing as rules.” Records that fail validation “are quarantined to prevent downtime, and alerts are sent” (Nexla).

What changed in 2026 matters for CDM work specifically:

• Connector coverage. As of July 2026, the library has 1000+ bidirectional connectors, with read and write on every one. For systems not yet covered, the AI connector builder “ships it in a median of under one week” (Nexla). For a CDM, coverage is everything: a model that cannot reach a source is a model with a hole in it.
• Meaning, not just structure. Helix, Nexla’s open context layer, “learns what your data means: what each field is, which system is right, and how fresh it is,” and Nexsets are “the data products inside Helix” (Nexla). This is where the CDM and the semantic layer start to meet.
• Agents reading the model. MCP Studio “builds governed, task-specific MCP servers scoped to a single business process” (Nexla). If an AI agent is going to query “customer,” it should get the governed CDM version, not whichever raw table it finds first.

A customer result that shows the effect: Nexla’s CDM page cites Glovo at “45X faster partner onboarding,” with integration time going “from 6 months to 3-5 days” (Nexla). Partner onboarding is a CDM problem at heart. Every new partner sends data its own way, and the job is to land it in your shape.

Common Data Model Examples Across Industries

The best-known CDMs are OMOP in healthcare, Microsoft CDM and Dataverse for Dynamics and Power Platform, Pega’s CDM for customer engagement, and in-house enterprise models for customer, product and transaction.

• OMOP (healthcare and clinical research). Standardizes observational patient data, plus vocabularies that provide “organization and standardization of medical terms” across clinical domains (OHDSI). Getting EHR data into OMOP is itself an integration job, often a large one.
• Microsoft CDM and Dataverse. Standard entities such as Account and Campaign, shared across Power Apps, Power BI, Dynamics 365 and Azure (Microsoft Learn).
• Pega CDM. An industry-specific model built around Account, Contact and Service Account, extended per industry (Pega Academy).
• Workato data models. A shared schema for iPaaS recipes so apps can be swapped without rebuilding every integration (Workato Docs).
• Generic enterprise CDM. Customer, product, order, transaction and event entities shared by BI, operations and now AI agents. This is the most common case and the one with no off-the-shelf answer, because your “customer” is not the same as anyone else’s.

How to Choose a Common Data Model Tool

Pick based on whether the tool enforces the model on live data, handles schema change without manual rework, and keeps governance attached to the model itself.

Common Data Model vs. Data Governance Tools: What’s the Difference?

A CDM standardizes the structure of data; data governance sets the policies, access and compliance rules on top of it. They are different jobs that work best when they share one object.

Governance catalogs show up for both searches because a business glossary is about common definitions. That is a shared language. A CDM is a shared structure.

The difference shows up in day-two operations. When a source changes, a glossary entry does not break. A pipeline does. If the model and the policies live in different tools, someone has to notice the change, update the model, update the catalog and fix the pipeline.

That is why we built Nexla to treat them as one thing. The Nexset is the model, the data product and the place where governance rules are applied. One object, one change log.

Keep your catalog if it serves your stewards well. Just make sure something in your stack is actually enforcing the model on the data.

FAQ

What is a common data model in simple terms?

A shared schema for core business entities that every source maps into, so all downstream systems see the same structure (Microsoft Learn).

Is a data catalog a common data model tool?

Partly. A catalog documents definitions, glossary terms, lineage and stewardship (Alation Docs). It does not run the pipelines that map data into the model, so it is usually paired with an integration platform.

What is the difference between a common data model and a canonical data model?

They are nearly the same idea. “Canonical” comes from integration architecture (Enterprise Integration Patterns); “common” is used more by vendors and industry standards.

What is the OMOP common data model?

An open standard from OHDSI that standardizes the structure and content of observational healthcare data (OHDSI).

How does Nexla handle schema drift in a common data model?

It analyzes data on every ingest, updates the Nexset schema for minor changes, creates a new detected Nexset for significant ones, and logs and alerts on each change (Nexla Docs).

How many connectors does Nexla have?

1,000+ bidirectional connectors as of July 2026 (Nexla).