Dictionary

Data mesh

Data mesh is een organisatiemodel voor data waarbij elk businessdomein eigenaar wordt van zijn eigen datasets en die aanbiedt als producten. Het breekt met het idee dat één centraal dataplatform alles voor iedereen moet afhandelen.

Wat is data mesh?

Data mesh is een organisatiemodel voor data, in 2019 beschreven door Zhamak Dehghani. De kern: stop met te proberen alle data van een grote organisatie door één centraal data-team te laten beheren. Geef elk domein (verkoop, logistiek, finance, HR) eigenaarschap over zijn eigen datasets en laat ze die aanbieden als data producten aan de rest van de organisatie.

Data mesh is geen product en geen technologie, het is een manier van werken. Het kan op elk dataplatform geïmplementeerd worden, van Microsoft Fabric tot Snowflake tot een zelfgebouwde stack. Wat telt is de manier waarop verantwoordelijkheden verdeeld worden.

Je kan data mesh vergelijken met hoe microservices de applicatiewereld veranderden. In plaats van één grote monoliet die door één team onderhouden werd, bouw je vele kleine diensten, elk eigendom van een team dat de domeinkennis heeft. Hetzelfde gebeurt hier voor data.

Waarom data mesh?

Klassieke data warehouses en lakehouses centraliseren data in één platform dat beheerd wordt door een centraal data-team. Dat werkt prima in kleinere organisaties, maar loopt bij grote bedrijven vaak vast op drie punten.

Bottleneck bij het centrale team
Elke nieuwe vraag van elk domein moet door hetzelfde team. De backlog groeit, de doorlooptijd wordt maanden, de frustratie stijgt.

Verlies van domeinkennis
Het centrale team kent de details van vijftig verschillende businessprocessen niet even goed. Fouten sluipen erin, semantiek wordt vertaald door iemand die er niet dagelijks mee werkt.

Onrealistisch schaalplafond
Een centraal team kan niet eindeloos groeien. Bij tien domeinen gaat het nog, bij vijftig domeinen kraakt het.

Data mesh lost dat op door het verantwoordelijkheidsmodel om te draaien: niet centraal, maar federatief.

De vier principes van data mesh

Dehghani legde vier principes vast die samen een data mesh definiëren. Eén of twee oppikken zonder de rest is geen data mesh.

1. Domain-oriented ownership

Elk businessdomein bezit de data die bij zijn processen hoort. Het salesdomein bezit de klantendata en orderdata, het logistiekdomein bezit de zendingsdata, finance bezit de boekingen. Ze kennen de semantiek, ze dragen de verantwoordelijkheid.

2. Data as a product

Elk domein bouwt zijn data niet voor zichzelf, maar voor consumenten elders in de organisatie. Dat verandert de houding: je denkt aan gebruikers, documentatie, versiebeheer, SLA. Een data product heeft een eigenaar, een duidelijke interface, een data contract en tooling om makkelijk ontdekt en gebruikt te worden.

3. Self-serve platform

Om domeinen autonoom te maken, krijgen ze een platform dat het zware werk weghaalt. Geen eigen Kubernetes-cluster per team, geen eigen governance-tools. Het centrale platform-team zorgt voor de plumbing: storage, compute, pipelines, catalog, monitoring. Domeinen richten zich op de inhoud.

4. Federated computational governance

Domeinen zijn autonoom, maar niet volledig vrij. Er zijn organisatiebrede regels (privacy, veiligheid, naming conventies, interoperabiliteit) die centraal worden vastgelegd en via tooling op alle domeinen worden afgedwongen. De governance is federaal: samen beslist, automatisch gecontroleerd.

Wat is een data product?

Een data product is een dataset plus al wat eromheen hoort om ze makkelijk bruikbaar te maken.

  • Een beschrijving en schema, via een data contract.

  • Een SLA: hoe vers is de data, hoe beschikbaar, hoe kwalitatief.

  • Een eigenaar met contactinfo.

  • Documentatie over semantiek en gebruiksvoorbeelden.

  • Observability: statistieken, drift-monitoring, incidenten.

  • Interfaces: een tabel, een API, een stream, een semantisch model.

In Fabric kan een data product bijvoorbeeld een lakehouse zijn met een gepubliceerd semantisch model, een goed gedocumenteerde catalog-registratie en duidelijke rechten.

Wanneer past data mesh wel, wanneer niet?

Past bij:

  • Grote organisaties met tientallen domeinen en duidelijke domein-afbakening.

  • Volwassen data-teams die technische basispatronen al kennen.

  • Organisaties waar een centraal data-team structureel overbevraagd is.

Past meestal niet bij:

  • Kleinere organisaties die met één warehouse-team prima verder kunnen.

  • Beginnende data-teams: zonder basisvolwassenheid wordt data mesh een chaos in plaats van een oplossing.

  • Organisaties zonder engineering-mentaliteit in de domeinen. Zonder productdenken bij de domeinen werkt het niet.

Valkuilen

Data mesh als uitvluchtje om niet te centraliseren
Sommige organisaties verklaren hun chaos tot data mesh. Vier domeinen die elk hun eigen Excelletjes beheren is geen mesh, dat is wildgroei. Mesh vereist expliciete principes, tooling en governance.

Geen platform-team om op te bouwen
Zonder een sterk self-serve platform hebben domeinen geen fundament. Investeer eerst in het platform, pas dan in het mesh-model.

Governance onderschatten
Federated governance klinkt als licht beheer. In werkelijkheid is het moeilijker dan centrale governance: alle domeinen moeten meespelen en afspraken moeten automatisch afdwingbaar zijn.

Semantische silo's
Als elk domein zijn eigen definitie van klant of product hanteert zonder afstemming, krijg je rapporten die elkaar tegenspreken. Conformed dimensions en organisatiebrede afspraken blijven noodzakelijk.

Hypetrein
Data mesh lost een specifieke schaalproblematiek op. Voor veel organisaties is een goed warehouse of lakehouse nog steeds het juiste antwoord. Laat niet de hype je architectuurkeuze dicteren.

Laatst Bijgewerkt: April 18, 2026 Terug naar Woordenboek
Trefwoorden
data mesh zhamak dehghani data product data contract decentraal data warehouse data lakehouse governance microsoft fabric domain ownership