What is Data Mesh?
Data Mesh is a decentralised data architecture that treats data as a product owned by domain-specific teams rather than a central data team. It distributes data ownership, governance, and quality responsibilities to the business domains that generate and best understand the data.
What is Data Mesh?
Data Mesh is an organisational and architectural approach to managing data at scale. Coined by Zhamak Dehghani in 2019, it challenges the traditional model where a single, centralised data team is responsible for collecting, cleaning, and serving all of an organisation's data. Instead, Data Mesh distributes data ownership to the business domains that produce and understand the data best.
Think of it this way: in a traditional setup, every department — sales, logistics, finance, marketing — sends its data to a central data engineering team, which must understand, transform, and make that data available for analytics and AI. This central team becomes a bottleneck. Data Mesh flips this model by making each domain responsible for its own data products, supported by a shared self-service data platform.
The Four Principles of Data Mesh
Data Mesh is built on four foundational principles:
1. Domain ownership of data
Each business domain (e.g., orders, payments, customer support) owns its data end-to-end. The team that generates the data is also responsible for cleaning it, documenting it, and making it available to the rest of the organisation. This eliminates the handoff to a central team and ensures that the people closest to the data maintain its quality.
2. Data as a product
Data is treated with the same rigour as a customer-facing product. Each data product has a clearly defined consumer, a service-level agreement for quality and freshness, documentation, and a discoverable interface. Domain teams think of other departments as their customers and design their data outputs to be genuinely useful and reliable.
3. Self-service data platform
A central platform team provides the infrastructure, tools, and templates that domain teams need to build, deploy, and monitor their data products without requiring deep data engineering expertise. This includes standardised pipelines, storage, cataloguing, access control, and monitoring tools. The platform reduces duplication of effort and ensures consistency.
4. Federated computational governance
Governance is not abandoned — it is distributed. Global policies around data quality, security, privacy, and interoperability are defined centrally but enforced locally by each domain. Automated policies embedded in the platform ensure compliance without manual gatekeeping.
How Data Mesh Differs from Traditional Architectures
In a traditional centralised data architecture, a data engineering team builds and maintains a monolithic data warehouse or data lake. All data flows through this central system. The advantages are simplicity and control, but the disadvantages are bottlenecks, slow time-to-insight, and the central team's inability to deeply understand every domain's data.
In a Data Mesh, each domain publishes its own data products that other teams can discover and consume. The central team shifts from building pipelines to building the platform that empowers domain teams.
| Aspect | Centralised Architecture | Data Mesh |
|---|---|---|
| Data ownership | Central data team | Domain teams |
| Pipeline building | Central team | Domain teams (with platform tools) |
| Governance | Central enforcement | Federated, automated |
| Bottleneck risk | High | Low |
| Domain expertise | Low in central team | High in domain teams |
Data Mesh in Southeast Asian Organisations
Data Mesh is particularly relevant for companies scaling across Southeast Asia's diverse markets:
- Multi-country operations: A company operating in Singapore, Indonesia, the Philippines, and Vietnam often has country-specific teams with deep local knowledge. Data Mesh lets each country team own its data while maintaining interoperability across the organisation.
- Rapid growth: Fast-growing companies in the region frequently outgrow centralised data architectures. Data Mesh provides a scalable alternative that grows with the organisation without overloading a central team.
- Diverse data regulations: Different ASEAN countries have different privacy laws. Domain-level ownership makes it easier to apply country-specific compliance rules while maintaining global standards.
Challenges and Considerations
Data Mesh is not a silver bullet. Common challenges include:
- Organisational readiness: Data Mesh requires a cultural shift. Domain teams must accept data ownership as part of their responsibilities, which may require new skills and incentives.
- Platform investment: Building a self-service data platform is a significant upfront investment that requires dedicated engineering resources.
- Interoperability: Without careful governance, domain data products can become siloed and incompatible. Standardised formats, schemas, and APIs are essential.
- Team maturity: Not every domain team has the technical skills to manage data products independently. Training and embedded data engineers can bridge this gap.
Getting Started with Data Mesh
For organisations considering Data Mesh:
- Assess your current pain points. If your central data team is a bottleneck and domain teams are frustrated with slow data delivery, Data Mesh may help.
- Start with one or two domains that are mature, motivated, and have clear data products to offer.
- Invest in the platform first. Without self-service tooling, asking domain teams to manage their own data will create chaos rather than agility.
- Define governance early. Establish global standards for data quality, naming, security, and discoverability before scaling to more domains.
- Iterate gradually. Data Mesh is a journey, not a switch. Most organisations take one to two years to see meaningful results.
Data Mesh addresses a problem that many growing companies in Southeast Asia face: the central data team becomes a bottleneck that slows down every department's ability to use data effectively. As organisations scale across multiple markets, products, and business units, the traditional model of funnelling all data through one team simply cannot keep pace.
For CEOs, Data Mesh offers faster time-to-insight because domain teams can serve their own data needs without waiting in a queue. For CTOs, it provides a scalable architecture that distributes the data engineering workload and reduces the risk of a single point of failure. It also improves data quality because the people who understand the data best are the ones responsible for it.
The strategic implication is significant: companies that adopt Data Mesh principles position themselves to scale their data capabilities at the same speed as their business, rather than being constrained by the capacity of a central team. In competitive Southeast Asian markets where speed and local market understanding are critical advantages, this alignment between data architecture and business structure can be a genuine differentiator.
- Data Mesh is an organisational change as much as a technical one. Success depends on domain teams accepting ownership of their data, which requires leadership buy-in and potentially new role definitions.
- Start with a self-service data platform before asking domain teams to manage data independently. Without proper tooling, decentralisation creates chaos.
- Define federated governance standards early, including naming conventions, quality metrics, and interoperability requirements. Without these, domain data products will become incompatible silos.
- Begin with one or two pilot domains that have clear, well-understood data products. Use their success to build organisational confidence before expanding.
- Budget for training and upskilling. Many domain teams will need support from embedded data engineers or training programmes to manage data products effectively.
- Data Mesh does not eliminate the need for a central team. It transforms that team into a platform team that builds and maintains shared infrastructure and governance frameworks.
- Measure success through business outcomes like reduced time-to-insight and improved data quality, not just technical metrics.
Frequently Asked Questions
Is Data Mesh only for large enterprises?
Data Mesh was originally proposed for large organisations with multiple distinct business domains, but its principles can benefit mid-sized companies too. If your organisation has clearly defined product lines or market segments with different data needs and you are experiencing bottlenecks with a centralised data team, Data Mesh concepts can help. However, very small companies with a single data team and few domains will likely find a centralised approach simpler and more practical.
How does Data Mesh differ from Data Fabric?
Data Mesh is primarily an organisational approach that distributes data ownership to domain teams, while Data Fabric is a technology-driven architecture that uses automation and metadata to integrate data across systems. Data Mesh focuses on who owns and manages data, while Data Fabric focuses on how data is connected and accessed. Some organisations combine both: using Data Mesh for governance and ownership and Data Fabric technologies for the underlying integration layer.
More Questions
Most organisations take 12 to 24 months to see meaningful results from a Data Mesh initiative. The first three to six months typically involve building the self-service platform and piloting with one or two domains. The next six to twelve months focus on expanding to additional domains and refining governance. Full organisational adoption is an ongoing process that evolves as the company grows and learns. Starting too fast without adequate platform investment is the most common cause of failure.
Need help implementing Data Mesh?
Pertama Partners helps businesses across Southeast Asia adopt AI strategically. Let's discuss how data mesh fits into your AI roadmap.