Estimated reading time: 6 minutes
In the past, the phrase ‘common data model’ (CDM) often elicited groans from project managers. It was associated with “analysis paralysis”—time-consuming attempts to categorise an entire organisation into a rigid framework that felt like a straitjacket.
In 2019, the argument against modelling was often: “We have a program to deliver, let’s just write the code.” Fast forward to now. The “move fast and break things” era has evolved. We are now in the age of Generative AI, Data Mesh, and hyper-connected Microservices. If you don’t have a shared language for your data today, you aren’t just dealing with messy code — you are feeding garbage to your AI and creating expensive data swamps.
This article explores what is a common data model, why the objections to it are outdated, and how to implement one in an Agile, API-first world.
What Is a Common Data Model?
At its core, a Common Data Model is a standardised definition of data concepts (entities, attributes, and relationships) shared across applications and data sources.
Think of it as the “Esperanto” or “Universal Translator” for your business. Instead of Sales calling a person a “Lead” and Billing calling them a “Debtor” with completely different data structures, a CDM ensures that when system A talks to system B (or when an AI agent queries your database), they both understand exactly what a “Customer” is.
In short, a well-designed data model plays a crucial role in digital transformation and serves as a central building block on which your journey is based.
Why People Don’t Model Their Data (The Myths)
Before we look at the benefits, let’s address the “why-nots” that persist in many teams:
- “It’s not Agile”: Myth. Agile requires a target state to be successful. A data model provides that target state for your sprint.
- “It boils the ocean”: Myth. You don’t need to model the entire enterprise at once. In 2025, successful modeling is iterative. You model the domain you are working on (e.g., “Billing”) and connect it to the wider whole later.
- “We’ll standardise later”: Myth. Integration debts interest rates are high. Fixing a messy API mesh after it has been deployed to production is significantly more expensive than spending a few days on a model upfront.
We have all heard some version of at least one of these, and the concerns are not entirely without merit, but with proper management and expectation-setting, it is entirely possible to deliver a lean, focused common model that standardises service interfaces, enhances business understanding and delivers value.
Why Are Data Models Important Now?
If you are asking why data models are important today, the answer goes beyond just “clean code.” It is about business survival and intelligence.
1. The Foundation for Generative AI
This is the biggest shift. Companies are rushing to implement LLMs (Large Language Models) and AI Agents. If your data is unstructured and inconsistent, your AI will hallucinate. A Common Data Model provides the semantic layer that allows AI to understand the context of your business, not just the raw text.
2. Order in the Microservices Chaos
Microservices are no longer a “trend”; they are the standard. However, without a model, these services descend into a mess of mismatched types. A CDM allows you to split your architecture into API-first designs. You can expose specific parts of the model (e.g., Customer Profile) to clients without exposing the underlying database technology.
3. Consistent Business Language
Data modelling bridges the gap between IT and Business. It forces the organisation to agree on definitions. When Marketing says “Churn,” does it mean the same thing as when Finance says “Churn”? A CDM solves this dispute once, in the model, rather than every time a report is run.
4. Enhanced Business Intelligence (BI)
In a world of real-time analytics, data quality is paramount. By introducing a façade service with a clear, consistent model, you mandate a minimum data quality for information flowing between systems. This ensures your BI dashboards reflect reality, not data errors.
Agile Common Data Modelling
Accepting some or all of the points above, we can agree that a common data model will provide real value to a digital transformation programme (small or large), and the concerns previously mentioned are successfully mitigated.
How can you get started on the right foot?
Let us examine briefly an example of how a data model might be defined, built, and made available within a commonly used agile pattern and its subsequent wider application. The model below illustrates the core phases of a single agile iteration, with the main steps highlighted as Define, Build, and Release.
The same concept can be applied to the development of a data model, where we would build an agile cycle to inform subsequent developments, with the listed activities outlined in each phase.
1. Define
- Identify what is coming up in future sprints and functionality they will likely need.
- Agree upon the main entities to support the sprint and how much has to be built on top of the already defined model.
- Map these entities against the roadmap (see section later on) to ensure we are not designing into a dead end.
- Identify the key stakeholders, data sources so the final model is representative of the final need.
2. Build
- Build the model with attributes as required, using best practices for things like naming standards (camelCasing) and XML conventions (complexTypes with element references)
- Try out the new model frequently, fill it with data and ensure it can meet the requirements. Does it allow a customer to have multiple addresses or several satisfaction scores?
3. Release
- Provide the model to the developers (typically via a repository / Artifactory location) as they define their interfaces and before they start building, as an immutable object (you don’t want them changing the model for you).
- Listen to feedback and allow them to guide you to useful changes they see as required. You’re not going to get it right the first time, but release it early enough in their cycle, and you can collate and refactor as needed.
Now, these modelling cycles should not take too long and often happen in parallel, as there will be views on what functionality needs to be delivered by when.
Devoteam’s Integration Strategy Proposition
Implementing a Common Data Model is a technical exercise and, even more, a strategic one. Devoteam’s integration strategy proposition guides organisations through this process. We help you move from “data chaos” to a structured “data mesh,” ensuring your modelling efforts support your digital transformation rather than hindering it.
Final Thoughts
The “straitjacket” reputation of data modelling is undeserved in the modern era.
- Microservices need it to communicate.
- AI needs it to understand the truth.
- Agile teams need it to define their target state.
Whether you are building a custom solution or leveraging a standardised model, the investment in defining your data always pays off in the long run. Get in touch with our data teams today.