Data mesh: what it is, how it works and why it does not replace data governance

Data mesh is a way of organizing a company's data architecture by distributing responsibility among the business areas that generate the data, instead of concentrating everything in a single central team. Instead of a data team in the middle, looking after one data lake for the entire company, each domain (purchasing, sales, logistics, finance) becomes the owner of its own data and treats it as a product that other areas will consume.

It looks like an architecture detail, a topic for the technical team. But data mesh touches the most sensitive point in companies: who answers for the data. And there the conversation stops being about technology and becomes a conversation about data governance. In this article I explain what data mesh is, how it works, who uses it, which tools support it and where the opportunities are. And, above all, why it does not eliminate the need for well-governed master data. If that base is bad, data mesh just distributes the problem.

What data mesh is, in plain terms

Data mesh is a domain-based data architecture and organization model. The central idea is that a company's analytical data should not be handled by a single central team that doesn't know the business in depth, but by the areas that produce and understand that data day to day.

The concept was formalized by Zhamak Dehghani and gained traction because many companies lived the same problem: the central data team became a bottleneck. Every report, every indicator, every integration went through a single queue. The areas complained about slowness, and the data team complained that it didn't understand each area's rules. Data mesh is born as a response to this, proposing to distribute responsibility instead of centralizing it. It is an architecture change, but before that it is a change of responsibility, and every change of responsibility inside a company is, at bottom, a change of governance.

How it works: the four principles of data mesh

Data mesh rests on four principles that work together. The first is domain-oriented ownership: each area becomes the owner of its data. Whoever knows the business rule is the one who answers for the data, and that makes sense, because nobody understands supplier data better than the person who negotiates with suppliers every day.

The second is data as a product. Here is the shift in mindset. Data stops being a file dumped in a folder and starts to be treated as a product, with an owner, documentation, monitored quality and a consumer in mind. Whoever produces the data needs to think about who will use it, the way a product team thinks about the customer.

The third is the self-service platform. For each domain to look after its own data without depending on a central team for every task, the company needs an infrastructure that allows publishing, finding and consuming data without reinventing the wheel in every project. Without that platform, data mesh becomes just a nice idea nobody executes.

The fourth is federated governance, the principle that the most people ignore when they are dazzled by distribution. Even with each domain looking after its data, there are common rules that apply to everyone: definitions, quality standards, security and privacy policies. And, whenever possible, those rules are applied automatically inside the platform, not in a document nobody reads. Notice the balance: the first three principles distribute, and the fourth stitches everything back together. Without the fourth, data mesh isn't decentralization, it's fragmentation.

Data mesh and MDM: why one does not replace the other

Here is the point almost nobody talks about, and it is where the risk lives. Data mesh deals with analytical architecture, with how data flows into reports and decisions. Master Data Management deals with master data, the customer, supplier, material and product masters that support the entire operation. They are different things, and data mesh does not solve the problem MDM exists to solve.

An example of the kind that comes up a lot in companies. An organization adopts data mesh and distributes responsibility by domain. Purchasing looks after supplier data, finance looks after the supplier from the payment point of view and tax from the tax point of view. Each one owns its piece. Except that, if there is no single supplier master, with a common definition of who that supplier is, each domain will see a different supplier. The purchasing report will say the company has eight thousand suppliers, finance will say six thousand, and nobody will know which number is right. Data mesh distributed responsibility, but it distributed the definition problem along with it.

That is why I keep saying that data mesh without master data governance is distributing the mess more elegantly. Domain ownership only works when there is a governed master data layer, with a golden record, with a single definition of what a customer, supplier and material is. The same goes for AI: many companies want to use data mesh to speed up the delivery of data to artificial intelligence models, but if the master data is duplicated or poorly classified, AI will decide on a leaky base, only faster and in more places at once. Speed doesn't fix bad data. As I discuss in the book Master Data Management: Fundamentos e Aplicações (book in Portuguese), published by Editora Brasport, master data quality is the foundation on which any modern architecture stands. Data mesh doesn't change that. It only makes that foundation even more important.

Who uses data mesh and who is responsible

Data mesh is not for every company, and that needs to be said clearly. It makes more sense in large organizations, with many domains, many data sources and a central team that has become a bottleneck. Smaller companies, with few sources and manageable volume, usually do better with a well-built centralized architecture. Adopting data mesh too early only adds complexity with no return.

On responsibility, data mesh redistributes roles. Each domain needs people who answer for its data, which brings the figures of data owner and data steward closer to the business areas. The data owner stops being an abstraction and becomes someone inside purchasing, logistics, sales. There is also a group that looks after federated governance, a platform team that looks after the infrastructure and, at the top, someone who answers for the data strategy of the whole company, a role that usually falls to the Chief Data Officer. In other words, data mesh doesn't eliminate governance roles, it spreads them across the company. Anyone who imagines that distributing the data means needing less governance has understood the concept backwards.

Which tools support data mesh

There is no single tool called data mesh that you buy and install. Data mesh is a model, and what exists are tools that support each part of it. For the data catalog and for finding data products, the market uses solutions such as Collibra, Alation and Microsoft Purview. For the platform and processing-at-scale layer, names like Snowflake, Databricks and the data clouds of the large providers appear. For quality and observability, there are tools such as Ataccama and Informatica. And, for the master data base, which supports the common definition across domains, the market uses MDM platforms such as SAP Master Data Governance, Informatica, Stibo Systems, Reltio, Semarchy, Profisee and Ataccama.

Notice that the MDM list is still there, in the middle of a data mesh architecture. It's no coincidence. It is practical confirmation that governed master data remains the foundation, whether the architecture is centralized or distributed. The choice of tool must start from the company's problem and its maturity, never from the vendor's pitch.

How to learn and the career opportunities

Anyone who wants to truly understand data mesh needs to start with the base, and the base is governance and master data. Learning data mesh without understanding data quality, data definition, governance roles and the master data life cycle is learning the roof without the foundation. A good path involves mastering the fundamentals of data management, studying the DAMA-DMBOK, which is the field's reference body of knowledge, and considering the DAMA CDMP certification when the goal is to consolidate a career. The most common mistake is getting stuck in the vocabulary of the moment, data mesh, data fabric, data lakehouse. Those who understand governance and master data evaluate any of these concepts with judgment, instead of chasing the term of the moment.

And the demand exists. The data field remains one of the biggest hirers, and governance is the part companies discover they need when the project starts to stall. Opportunities appear in roles such as domain data steward, data governance specialist, data architect, product owner of data products and, in leadership, Chief Data Officer. The detail that makes the difference is being able to translate: the professional who only talks about architecture stays stuck in IT, while the one who shows leadership that a duplicate supplier becomes a wrong purchase, a wrong tax and a wrong decision is the one who moves up.

Main questions about data mesh

Does data mesh replace the data warehouse or the data lake? No. Data mesh is an organization and responsibility model, not a technology that replaces the data warehouse. Each domain's data products still use data warehouses, data lakes and lakehouses underneath. What changes is who answers for them and how they are made available.

Does data mesh end the need for MDM? No, quite the opposite. Data mesh distributes responsibility for analytical data, but it still depends on a single, trusted definition of customer, supplier and material. Without governed master data, each domain sees a different version of the same entity and the numbers never close.

What is the difference between data mesh and data fabric? Data mesh is an organizational approach, centered on domains and responsibility. Data fabric is more technological, centered on integrating and automating access to data through metadata. They are not opposites and can coexist, but they start from different points.

Should every company adopt data mesh? No. Data mesh solves scale and bottleneck problems in large, complex organizations. Smaller companies usually do better with a well-governed centralized architecture. Adopting it as a fad, without a problem that justifies it, only adds complexity.

Where to start if the company wants to move toward data mesh? With governance and master data. Before distributing responsibility, you need common definitions, clear data owner roles and a trusted master data base. Distributing without that base is spreading the problem.

MDM Academy: where the foundation is taken seriously

All of these concepts, from data mesh to master data, depend on something no architecture delivers on its own: professionals who truly understand data governance. That is what MDM Academy, 4MDG's school of governance and master data, exists for. The proposal is to train those who live the data problem day to day, the master data, purchasing, supply chain, IT and governance people, with content that starts from practice and translates technical concepts into business impact. If you want to build that foundation and grow in a field that only keeps expanding, it is worth getting to know MDM Academy and joining the Data Club, where we exchange real experience on governance, master data and career.

Conclusion

Data mesh is a legitimate answer to a real problem. The central data team became a bottleneck in many companies, and distributing responsibility by domain makes sense when scale justifies it. But the part that dazzles, decentralization, is also the one that hides the trap. Distributing data without governance and without trusted master data doesn't solve the problem, it only spreads it to more places.

What supports any data architecture, old or modern, remains the same: clear definition, data owner, quality and a master data base the company trusts. Data mesh doesn't change that truth, it only makes it more evident that, without that foundation, no architecture saves the company from deciding wrong. The question that remains is simple: before thinking about distributing your data, does your company trust the definition it has of customer, supplier and material?