Data Mesh Decomposition for a Centralized Data Team That Had Become a Bottleneck

A growing technology organization with a centralized data team responsible for all ingestion, transformation, modeling, and reporting work across multiple product domains. The model had worked at small scale and had broken at the scale the company had grown to.

The central data team had become the universal bottleneck. Every product team that needed data work was waiting in the same queue. Priorities were being negotiated at the executive level because the central team couldn't service everyone simultaneously. Lead times for data work had grown to weeks or months for non-trivial requests. The leadership had concluded that the centralized model wasn't scalable and that the organization needed to move toward decentralized data ownership while preserving the consistency the central team had provided.

A data mesh architecture that distributed ownership of data products to the domain teams that owned the underlying business capabilities.

A reference architecture was defined for what a domain-owned data product looked like — how data was published, what quality contracts it carried, how access was granted, how lineage was preserved. Domain teams gained autonomy over the data products they produced; they also gained responsibility for them.

Self-service tooling was built to support the domain teams. Templated dbt projects, deployment pipelines, observability dashboards, and access management surfaces. Domain teams without prior data engineering experience could publish their first data product against the templates without needing the central team to do the work for them.

The central team's role shifted from execution to platform. They built and operated the underlying infrastructure — the lakehouse, the catalog, the orchestration platform, the observability surfaces. They defined and enforced the cross-domain standards. They provided expert support for domain teams hitting hard problems. They stopped doing the per-domain implementation work that had been their bottleneck.

A federated governance model was defined. Domain teams owned their data; cross-domain decisions — naming conventions, access classifications, retention policies — were made through a governance group with representation from each domain. Standards became negotiated rather than imposed.

Migration was phased. The first two domain teams were chosen for the migration based on their readiness and their willingness to be the early adopters. Their experience informed the patterns the subsequent domain teams adopted. The central team didn't try to migrate everything at once.

Lead times for domain-specific data work dropped substantially as each domain team gained the ability to do its own work. The central team stopped being the bottleneck and became the platform team enabling everyone else. Cross-domain consistency was preserved through the federated governance model rather than through central execution. The organization's overall data velocity improved noticeably.

The shift required cultural change as well as technical change. Domain teams accepting responsibility for their data was the harder part; the tooling and architectural work supported the cultural shift but couldn't substitute for it.