The problem with central data teams
For the past decade, the dominant way to manage data in companies has been to centralize it: a single data team takes requests from across the organization, ingests data from every system, and serves analytics to every department. That model makes sense when the organization is small and data isn’t critical to the business.
When the company grows, data becomes a strategic asset, and analytics requests multiply, the central team turns into a bottleneck. Requests pile up, timelines stretch, and business teams end up building their own siloed solutions — which makes the original problem worse.
Data mesh is the architectural and organizational answer to this problem.
What data mesh is
Data mesh, a concept formalized by Zhamak Dehghani, rests on four core principles:
-
Domain-oriented data ownership: each business area (sales, production, finance, logistics) owns its data as if it were a product. The sales team doesn’t wait for the central data team to process its data — it governs, publishes, and maintains that data itself.
-
Data as a product: each domain publishes its data with the same attention to quality, documentation, and accessibility it would give a software product. Internal consumers can trust that data.
-
Self-service infrastructure: a central data platform provides the tools, pipelines, and storage the domains need, so they don’t have to build it from scratch.
-
Federated governance: a shared set of standards (security, privacy, interoperability) applies to every domain, with autonomy inside those standards.
What data fabric is and how it differs
Data fabric is a complementary architectural approach that starts from a different premise: instead of reorganizing data ownership by domain, it connects heterogeneous data sources through active metadata and knowledge graphs, creating an intelligent integration layer.
Data mesh is mainly a change in organization and accountability. Data fabric is mainly a technology change: it uses metadata catalogs, integration engines, and shared semantics to make data from different systems accessible and usable without moving it.
The two aren’t mutually exclusive. Many organizations adopt data mesh principles in their operating model and data fabric technology to solve technical integration.
When each approach makes sense
Data mesh fits when:
- The company has several divisions or business units with their own technical teams.
- The central data team can’t keep up with growing demand for analysis.
- Business domains are technically mature enough to manage their own data.
Data fabric fits when:
- The company needs to integrate data from many heterogeneous systems without a structural reorganization.
- Data is widely distributed across locations or multiple clouds.
- The priority is data accessibility and discovery rather than ownership.
For business groups with several companies or divisions, a data mesh architecture can transform the relationship between data teams and the business. For companies with a wide variety of legacy systems, data fabric can be the bridge to a more coherent data platform.
A gradual rollout: it’s not all or nothing
Neither data mesh nor data fabric requires a radical transformation on day one. The most pragmatic path starts by identifying the most mature and most in-demand data domains, establishing the data product model with them, and gradually extending the principles to the rest of the organization.
At AIRES, we work with companies to assess which approach fits their organizational structure, data maturity, and business goals, and we design a roadmap that minimizes the risk of the transition.
Frequently asked questions
Is data mesh only for large companies? No, although it’s more common in large organizations. Domain ownership applies to any company with more than two or three distinct business areas. What changes is the complexity of the implementation. A midsize company can adopt data mesh principles pragmatically, without a complex infrastructure platform.
What happens to governance when data is distributed? Federated governance is one of the pillars of data mesh precisely to keep decentralization from turning into chaos. We define common standards for quality, security, format, and documentation that every domain must meet, and set up a lightweight governance body that ensures they’re applied without micromanaging.
How long does the transition to data mesh take? A full transition in a midsize or large organization is a multi-phase project. The first benefits — more autonomous domains, a smaller central backlog, better quality in the most critical data — show up once the first domains are complete, as long as they’re prioritized correctly.