Registry, Consolidation, Coexistence… the names vary, but the underlying question is always the same: where will the data “live” and how will it “flow”? And here’s a warning: this decision isn’t just technical. It defines whether your initiative will be viable or not. In practice, these three approaches represent different levels of ambition (and organizational impact).

The lightest model is Registry.

In this model, you don’t try to truly centralize the data. Each system keeps its own version, and MDM acts as a layer that connects these versions. It identifies which records represent the same entity and creates a “virtual” consolidated view.

It works well when the main problem is lack of visibility. You want to know that the customer in the CRM is the same one in the ERP, but you don’t want—or can’t—change the systems right now.

You get quick wins because the change is small. But there’s a clear limit: you don’t fix the problem at the source. The data remains inconsistent—you can just see it more clearly now.
 

The second model, Consolidation, goes a step further.

Here, you bring data into a central repository, improve quality, resolve duplicates, and build a Golden Record in a more structured way. This consolidated data becomes the reference, especially for analytics and reporting.

This model works very well when the goal is to improve information consistency, especially in companies with many systems and lots of discrepancies between them. But there’s still an important limitation: the source systems continue to exist with their own versions. In other words, you significantly improve how data is read, but not always how operations run.
 

That’s where the most complete—and most challenging—model comes in: Coexistence.

In this scenario, MDM stops being just a consolidation point and becomes an active part of operations. It not only creates the Golden Record but also distributes that information back to systems and, in some cases, becomes the point where data is created and maintained. This is where the idea of a “single source of truth” truly materializes.

But this comes at a cost—not just technical, but organizational. You’re changing processes, responsibilities, and often the autonomy of different teams. That’s why the most common mistake is trying to start with this model.

The intention is good—jump straight to the “ideal.” But in practice, this often leads to long, complex projects that struggle to show value in the short term.
 

A more pragmatic approach tends to work better.

Start with something closer to a Registry or a light Consolidation model, solve a concrete problem (like customer duplication or product inconsistency), generate visible results, and then evolve.

Over time, as the organization gains confidence and maturity, it makes sense to increase the level of centralization and control. Not every company needs to reach the most advanced model—and that’s okay.

The key point is that MDM architecture isn’t about choosing the “most complete” model. It’s about choosing the model your organization can absorb right now without disrupting operations.

Because in the end, the best design isn’t the most sophisticated one. It’s the one that actually gets implemented, improves data quality, and keeps working after the project is over.