Wat is een data mesh?

Een data mesh is een manier om data te organiseren waarbij niet één centraal team alle gegevens beheert, maar elk domein - inkoop, transport, warehouse, finance - eigenaar is van de data die het zelf produceert, en die levert als een product waar de rest van de organisatie op kan bouwen.

Het is geen product dat je koopt en geen tool die je installeert. Het is een keuze over wie ergens over gaat. De term komt uit het werk van Zhamak Dehghani (2019) en is sindsdien vooral populair geworden bij organisaties die merkten dat hun centrale datateam niet meegroeide met de vraag.

Waarom het idee ontstond

De klassieke opzet is een centraal datateam dat alle bronnen ontsluit. Dat werkt zolang het aantal bronnen klein is. Groeit de organisatie, dan ontstaat er een wachtrij: elke nieuwe vraag moet langs hetzelfde team, dat de betekenis van de gegevens moet raden omdat het het werk zelf niet doet. Het team wordt het knelpunt, en tegelijk de plek waar de meeste fouten insluipen.

Hetzelfde werk, maar de betekenis komt van een andere plek.

Een mesh draait dat om. De planner die weet wanneer een order werkelijk gereed is, legt die definitie vast. Niet een analist die het uit een kolomnaam afleidt.

De vier principes

Vier afspraken die samen een mesh maken. Los van elkaar werken ze niet.

Eigenaarschap per domein. Wie het werk doet, gaat over de betekenis van de gegevens die eruit komen. Dat betekent ook: het domein wordt aangesproken als een levering te laat of onjuist is, niet het centrale team.

Data als product. Een dataset is pas klaar als er een beschrijving bij zit, een afspraak over kwaliteit en versheid, en een aanspreekpunt met een naam. Een product heeft gebruikers, en die gebruikers mogen iets verwachten.

Platform als zelfbediening. Domeinen mogen niet elk hun eigen infrastructuur bouwen. Eén platform, één keer goed gebouwd, waar iedereen zichzelf op bedient: opslag, verwerking, catalogus, toegang, monitoring.

Gestuurd, niet vrijgelaten. Toegang, definities en herleidbaarheid worden centraal afgedwongen, zodat autonomie geen wildgroei wordt. In de literatuur heet dit federated governance: het beleid is centraal, de uitvoering ligt in het domein.

De eerste twee gaan over mensen, de laatste twee over techniek. Organisaties die alleen de laatste twee doen, hebben een duur platform en dezelfde ruzie over cijfers als daarvoor.

Hoe een dataproduct er in de praktijk uitziet

"Data als product" blijft abstract tot je het opschrijft. Een bruikbaar dataproduct heeft in de praktijk zes dingen:

1. Een naam en een doel. Bijvoorbeeld: orders gereed voor verzending, gebruikt door planning en klantenservice.
2. Een definitie in woorden. Wanneer is een order gereed: als de laatste regel gepickt is, of als de pallet is gewogen en gelabeld? Eén van de twee, opgeschreven.
3. Een vorm. Welke velden, welke eenheden, welke sleutels, en wat er gebeurt als een veld leeg is.
4. Een afspraak over versheid en kwaliteit. Ververst elk kwartier, maximaal 0,5 procent regels zonder gewicht, en een melding als het daarbuiten valt.
5. Een eigenaar met een naam. Niet een afdeling, een persoon die aanspreekbaar is en een vervanger heeft.
6. Herleidbaarheid. Van elk veld is te zien uit welk bronsysteem het komt en welke bewerkingen erop zaten.

Die zes punten samen zijn wat wij een data contract noemen. Zonder dat document is een dataproduct alleen een tabel met een mooiere naam.

Welke rollen je nodig hebt

Een mesh vraagt drie rollen die in veel organisaties nog niet bestaan.

De domeineigenaar is verantwoordelijk voor de betekenis: welke definitie geldt, en wat de organisatie mag verwachten. Dit is een businessrol, geen technische.

De data-product-engineer bouwt en onderhoudt de levering. In kleinere organisaties is dit iemand uit het domein met tijd en toegang, niet per se een specialist.

Het platformteam bouwt de zelfbediening en dwingt beleid af. Het levert geen datasets meer op verzoek. Dat is een grotere verschuiving dan hij klinkt: het team gaat van dataleverancier naar wegbeheerder.

Waar het in de praktijk misgaat

Drie patronen komen steeds terug.

Eigenaarschap zonder capaciteit. Een domein wordt eigenaar gemaakt in een stuurgroep, maar krijgt geen uren en geen mandaat. De kwaliteit gaat dan omlaag in plaats van omhoog, want het centrale team laat los en het domein pakt niet op.

Een mesh zonder platform. Elk domein bouwt zijn eigen pijplijnen, met zijn eigen keuzes voor opslag en rechten. Na een jaar heb je geen mesh maar vier kleine centrale teams die elkaars werk niet kunnen lezen.

Een platform zonder afspraken. Techniek staat, definities niet. Twee domeinen leveren beide "omzet", op twee manieren berekend, en de vergadering is terug bij af.

Wanneer een mesh niet past

Bij twee bronnen en één analist is een mesh overhead. Het loont pas als meerdere domeinen tegelijk data leveren en de wachtrij bij het centrale team merkbaar is: vragen die weken blijven liggen, of rapporten die naast elkaar bestaan omdat niemand nog weet welke de goede is. Ook loont het niet als de organisatie geen eigenaarschap kan of wil beleggen. Dan is een goed ingerichte centrale opzet met vastgelegde definities eerlijker en goedkoper.

Hoe je begint: één domein, één product

Vijf stappen die je in weken kunt doen, niet in kwartalen.

Begin bij één cijfer waar de directie elke maand op leunt en dat nu meer dan één antwoord heeft. Wijs het domein aan dat het werk doet, schrijf het contract, publiceer de levering als product en meet daarna wie het gebruikt en waar het afwijkt.

Dat laatste is de stap die het vaakst wordt overgeslagen en die het meest oplevert: zonder gebruiksmeting weet je niet of je product wordt vertrouwd, en dus ook niet of het volgende domein hetzelfde patroon moet volgen.

Wat eronder moet liggen

Onder een mesh zit gewoon een platform: opslag in open formaat, één catalogus, herkomst per veld en toegang per rol. In veel omgevingen is dat een lakehouse, bijvoorbeeld op Databricks. Hoe die lagen zich tot elkaar verhouden, staat in wat is data architectuur. Hoe wij die laag bouwen en beheren, beschrijven we op de motor.

Eén domein, één dataproduct, één cijfer waar de directie op leunt. Als dat navolgbaar klopt, volgt de rest vanzelf.