Why Enterprise Data Architects Should Build Distributed Data Meshes Instead of Centralized Data Platforms

Enterprise data architects should not build large centralized data platforms; they should create distributed data meshes.

“I recommend the next enterprise data platform architecture be a fusion of distributed domain‑driven architecture, self‑service platform design, and data product thinking.”

Dehghani’s talk highlights new management principles and a new language to support this mindset, such as “service over‑consumption” and “discover and use over‑extraction and loading.”

She identifies three failure modes in traditional data platform architectures. First, they are centralized and monolithic; aggregating all data types works for small organizations but fails for enterprises with many data sources and consumers.

Second, she describes the problem of “coupled pipeline decomposition.” Generations of architects have broken data platforms into pipelines of processing steps that are orthogonal to the axis of change, requiring updates to all steps for new features.

Third, isolated and overly specialized ownership leads to failure. Centralized architectures create separate teams for data providers and data consumers, with data and machine‑learning experts in the middle; the central team must remain domain‑agnostic.

Dehghani compares these challenges to the N‑layer monolith problem, where new customer demands require modifications across all layers. Micro‑services align better with change but demand a different design approach. Implementing a data mesh requires a similarly dramatic shift in thinking.

To decentralize the overall data platform, we must reverse our view of data, its location, and ownership. Domains should host and serve their data sets in a consumable way rather than flowing data to a centrally owned lake or platform.

The envisioned architecture treats domain data products as first‑class components, each owned by a team that understands the domain. Rigid, monolithic data pipelines are no longer the primary design focus, and data is not strictly divided into source and consumption modes. Distributed teams can use the data they need and feed their outputs back into the mesh for others.

For such an architecture to succeed, data products must be discoverable, addressable, trustworthy, self‑describing, interoperable, secure, and governed by global access controls. These attributes are the responsibility of each data product owner, supported by joint governance and the platform providing data infrastructure.

Data warehouses and data lakes can still exist within this architecture, but they become just another node in the mesh rather than a centralized monolith. Teams should be free to use them when needed, and the adoption of micro‑services and polyglot solutions remains relevant.

Dehghani’s QCon presentation “A Paradigm Shift to Data Mesh in Data Platform Architecture” will be released in the coming weeks, and her article “How to Migrate from a Single Data Lake to a Distributed Data Mesh” is already published. She will also appear as a guest on the InfoQ podcast.