Types of data architectures: which one should you choose?

Why the architecture choice is a strategic decision

Data architecture decisions have a long half-life. Migrating from a centralized warehouse to a distributed model or vice versa is expensive, disruptive, and time-consuming. Organizations that approach this choice tactically, optimizing for the immediate problem rather than the structural direction, frequently find themselves rebuilding their data organization every three to five years.

The right starting point is not the technology. It is the operating model: who owns data, who consumes it, how quickly do business units need to act on it, and how tightly does governance need to be centralized to meet regulatory and quality requirements. The architecture should follow from that model not determine it.

This is the framing Mantu brings to data strategy consulting engagements: architectural choices are downstream of organizational and strategic ones, and they need to be evaluated together.

Centralized vs decentralized data: the foundational tension

The oldest tension in enterprise data organization is between centralized vs decentralized data and it has not been resolved, because neither extreme works at scale.

In practice, most large enterprises operate somewhere between these poles and the dissatisfaction is mutual. Centralized teams are overwhelmed and accused of slowing the business. Decentralized teams produce fast but inconsistent output that erodes trust in data. This is the problem that federated and mesh architectures were designed to solve.

Federated data models: a middle path with governance teeth

Federated data models distribute data ownership to business domains while maintaining shared standards, interoperability contracts, and a governance layer that spans the organization. The key insight behind federation is that autonomy and consistency are not mutually exclusive — they require a different organizational design.

What federation actually means in practice

In a federated model, each domain finance, marketing, supply chain, product owns its data, is responsible for its quality, and publishes it according to agreed schemas and standards. A central function does not own the data; it owns the standards and the infrastructure that makes interoperability possible.

This requires genuine organizational change: domain teams must develop data engineering capability, and central teams must shift from owning data to enabling data owners. For organizations without that capability today, the transition is the hardest part not the technology.

Federated models work well when domains are genuinely distinct, have sufficient engineering maturity, and when the central governance function has the authority to enforce standards without owning execution. They are a poor fit when domains lack data talent or when governance is politically contested.

Data mesh vs data hub: two philosophies, two operating models

The most debated architectural choice in enterprise data strategy today is data mesh vs data hub. They represent fundamentally different answers to the same question: how do you make data available, trustworthy, and usable at enterprise scale?

Data mesh: organizational model, not just technology

Data mesh, as articulated by Zhamak Dehghani, is premised on four principles: domain ownership, data as a product, self-serve data infrastructure, and federated computational governance. Critically, data mesh is not a technology stack it is an operating model. Organizations that implement a technical data mesh without the organizational shifts required tend to reproduce centralized dysfunction in a distributed wrapper.

The data mesh approach is most powerful in large, complex organizations where multiple domains have both the business need and the engineering capability to own their data products. It fails in organizations where data maturity is low or where domain teams cannot be resourced to take on data product ownership.

Data hub: faster path, narrower ceiling

A data hub provides a centralized integration layer that ingests data from multiple sources and makes it available to consumers through standardized interfaces. It is faster to stand up than a mesh, easier to govern in the short term, and appropriate for organizations that need consolidated data access without the organizational overhead of full domain ownership.

The limitation is scale. As the number of producers and consumers grows, hub architectures tend to become integration bottlenecks the same problem they were designed to solve in monolithic data warehouses, at a different level of abstraction.

Which architecture fits your organization?

There is no universally correct answer. The right architecture depends on the interaction between organizational maturity, governance requirements, domain autonomy, and engineering capacity. The following framework is a starting point for that evaluation:

In practice, most enterprise data architectures are hybrids centralized governance with federated execution, or a data hub for certain data products and mesh principles applied to others. The architecture is not a binary choice; it is a design space, and the best designs are informed by an honest assessment of current organizational capabilities, not by a desire to adopt the most sophisticated model.

That assessment mapping the gap between current state and target architecture, and designing the transition is where strategic guidance makes the most difference. Mantu's data strategy consulting teams work with CDOs and CIOs to make these architectural choices with organizational reality in view, not in spite of it.