The term 'data mesh' has been circulating in Japanese IT departments since around 2022, but the explanations tend to be either too abstract or too tied to the specific tooling of a particular vendor. This article explains the concept plainly, describes where it fits in a typical Japanese enterprise data environment, and points out where it does not fit.

The core idea: data as a product, owned by the domain

A data mesh is an architectural approach that treats data as a product and assigns ownership of that data to the team that generates it. In a traditional setup, a central data team ingests data from every department, transforms it, and serves it from a warehouse. In a mesh, the logistics team owns and serves its own data, the finance team owns and serves its own, and so on. A shared infrastructure layer handles discovery and access control.

How this differs from a data warehouse

A data warehouse centralises data physically. Everything is copied into one place, transformed into a common schema, and served from there. This works well when data volumes are manageable and the central team has enough capacity to keep up with every source system's changes. It breaks down when the number of source systems grows, when source schemas change frequently, or when different departments need different definitions of the same entity. Which is common in Japanese manufacturing and retail environments.

Where Japanese enterprises are adopting it

Adoption in Japan has been fastest in manufacturing and financial services, where data is generated by many distinct operational systems. Production lines, ERP instances, trading platforms. That were never designed to talk to each other. Retail has been slower, partly because many mid-size retailers still run on-premise ERP systems that predate modern API conventions. The mesh approach is particularly well-suited to these environments because it does not require replacing the source systems.

Where it does not fit

A data mesh is not the right answer for a small team with one or two data sources. The overhead of domain ownership and a shared infrastructure layer only pays off when you have enough domains and enough data volume to justify it. For a team of ten analysts working from a single database, a well-maintained data warehouse is simpler and cheaper. The mesh architecture is a solution to a coordination problem, and you need to have the coordination problem first.

If your organisation has more than five distinct data sources and more than one team arguing about whose numbers are correct, the mesh architecture is worth a closer look. The full platform module list covers how Meshblend implements this in practice.