Met datagovernance worden vragen beantwoordt als: Wie is de eigenaar van de data? Wie kan ik vragen stellen als ik de data niet begrijp? Waar komt mijn data vandaan? Hoe houdt je regie als adoptie van dataproducten groeit binnen jouw organisatie. Of te wel hoe houdt je controle over jouw data wanneer steeds meer collega’s zelf met de data aan de slag gaan. Een handige methodiek die hierbij kan helpen is de Data Mesh. Eerst zullen we uitleggen wat een Data Mesh überhaupt is en dan zullen we inzoomen op waarom deze Data Mesh zo’n interessante methodiek is.
Wat is een Data Mesh?
De term Data Mesh werd in 2019 geïntroduceerd door Zhamak Dehghani, Directeur opkomende
technologieën bij Thoughtworks. De Data Mesh is een methodiek of beter gezegd een architectuur
waarmee (complexe) dataplatformen ingericht kunnen worden om op een zo efficiënte manier, als
data gedreven organisatie, data producten uit te nutten en nieuwe data producten te creëren. Enerzijds kan je de Data Mesh zien als een architectuur omdat de Data Mesh sterk bepaald hoe jouw
data architectuur eruit komt te zien. Anderzijds kan je het ook als een methodiek zien omdat er ook
een sterke focus ligt op organisatorische uitdagingen. Data Mesh richt zich op 4 basis principes:
- Data-eigenaarschap: In de Data Mesh betekend eigenaarschap dat domein teams
verantwoordelijk zijn voor hun eigen data. Dat wil niet zeggen dat iedereen weer in zijn eigen
silo, met eigen middelen en technologie data oplossingen gaat bouwen. Nee, het is juist de
bedoeling dat de data zoveel mogelijk centraal opgeslagen wordt iedereen ook dezelfde werkwijze en standaarden hanteert, maar wel domein specifieke dataproducten ontwikkeld. Als medewerker binnen een bepaald domein ben jij degene die er toch het meeste verstand van heeft? Of je nu medewerker bent in het domein belastingadvies of onderdeel bent van de controlepraktijk. - Data als een product: Een tweede belangrijk principe is dat je naar data gaat kijken als een
product. Producten die met zorg zijn samengesteld en een hoge kwaliteit hebben. Daarnaast
is het belangrijk dat dataproducten gedeeld kunnen worden, zodat medewerkers in andere
domeinen data weer kunnen gebruiken. Enerzijds om op te sturen en anderzijds om weer
nieuwe dataproducten te ontwikkelen. Zo ontstaat een keten van dataproducten. - Zelf-servicedata omgeving: Binnen een datagedreven organisatie zou iedereen toegang tot
relevante data moeten hebben. Zoals we in ons vijf stappenplan al beschreven is het
belangrijk dat medewerkers hier wel de juiste competenties voor opbouwen. Het idee dat
iedereen zelf met, de voor haar rol of functie, relevante data aan de slag gaat is simpel: Als
domein specialist ken jij jouw domein het beste. Een data engineer heeft technische skills,
maar heeft zeker niet altijd specifieke domein kennis zoals een belastingadviseur of een register accountant dat wel heeft. Dit betekend dus niet dat we weer terug gaan naar losse data-oplossingen. Iedereen werkt wel op het centrale dataplatform en gebruikt dezelfde standaarden en richtlijnen om aan kwaliteitseisen te kunnen voldoen en om te zorgen dat iedereen op een eenduidige manier werkt. Dit heeft als gevolg dat de rol van data engineer langzaam aan het veranderen is en er een nieuwe rol aan het ontstaan is. Dit is de rol van analytics engineer. De data engineer zorgt voor alle koppelingen met bronnen en zorgt dat het fundament van het platform staat. De analytics engineer is een domein specialist met technische bagage. Deze specialisten zorgen dat de data getransformeerd worden naar bruikbare data producten. De eindgebruiker, of te wel de dataconsument kan data producten combineren om vraagstukken mee op te lossen. - Federatieve data-governance: De governance van data is cruciaal binnen de Data Mesh. Wil je al deze functionele domeinen goed met elkaar laten samenwerken dan zijn er duidelijke spelregels nodig en ook duidelijke afspraken over kwaliteit: Ook wel de standaarden en de richtlijnen. Naast deze standaarden en richtlijnen moeten er duidelijke afspraken gemaakt worden over het delen van data. Hier komt ook weer een nieuw concept om de hoek, namelijk het data contract. Dit is een afspraak over hoe een dataproduct geconsumeerd kan worden. In het contract liggen
aspecten als kwaliteit, periodiciteit van verversing en definities van de data vast. Hierdoor weet de dataconsument precies hoe hij de data kan gebruiken en wat hij er wel of niet van mag verwachten. Door dataproducten te delen voorkom je ook dat business logica vaker ontwikkeld wordt. Je wilt namelijk maar 1 versie van de waarheid. En anders zul je business logica ook op meerdere plekken moeten beheren en onderhouden wat sowieso niet verstandig is. Wanneer er dus een nieuwe data vraag komt kijk je eerst op de menukaart wat er al is. Daar kan je eventueel eigen ingrediënten aan toevoegen om een nieuw (data-)gerecht te maken. Mocht het een lekker gerecht zijn, dan laat je het gerecht ook weer opnemen op de menukaart.
Nieuwe termen
Binnen de Data Mesh worden een aantal nieuwe termen geïntroduceerd. Voordat we het gaan
hebben over waarom je voor een Data Mesh zou moeten kiezen is het goed om even wat verder op
deze termen in te zoemen.
Dataproduct: De term dataproduct is niet per se nieuw, maar wel de manier hoe een dataproduct
gedefinieerd wordt binnen een Data Mesh. Een Data Product is het logische geheel van onderdelen
binnen een dataplatform welke nodig zijn om een use-case te kunnen realiseren. Deze definitie is
redelijk abstract, maar betekend concreet dat een dataproduct niet alleen de data zelf betreft, maar
ook alle (techniche) onderdelen die nodig zijn om de use-case te kunnen realiseren. Hiervoor zijn
verschillende bouwblokken nodig zoals data storage (gegevensopslag), code (transformatie en businesslogica), documentatie, monitoring en logging, security policies en onderdelen voor beheer.
Een dataproduct koppelt aan bronsystemen of aan andere dataproducten. Het dataproduct voegt
waarde toe middels nog niet eerder ontwikkelde business logica. Deze logica is goed beschreven,
beheer en onderhoud is ingericht en de kwaliteit en beschikbaarheid worden continue geborgd. Dat
ziet er schematisch zo uit:
Data Contract: Een datacontract definieert de voorwaarden waaronder een dataproduct afgenomen
kan worden. Denk hierbij aan hoe de data wordt aangeleverd (welk formaat), de kwaliteit van de data en hoe deze kwaliteit gegarandeerd wordt (met andere woorden wat voor controles worden er gedaan), de definities van datapunten, eigenaarschap en periodiciteit van verversen. Eventueel kunnen ook de kosten van het dataproduct opgenomen worden in het contract zodat deze doorbelast kunnen worden aan dataconsumenten.
Federatieve data governance: Zoals reeds benoemd is data governance cruciaal in de Data Mesh.
Data governance begint met het maken van heldere afspraken over hoe dataproducten en datacontracten worden opgezet. Begin met afspraken maken over hoe je data kan vastleggen en delen
binnen jouw organisatie. Bepaal hoe je definities kan vastleggen en bij wie je moet zijn als er
inhoudelijke vragen zijn over de data. Er komen ook steeds meer hulpmiddelen die hierbij kunnen
helpen. Denk bijvoorbeeld aan Azure PurView, Data Mesh Manager en DBT waar je dataproducten,
data contracten en zaken als eigenaarschap en definities kan vastleggen.
Waarom zou je kiezen voor een Data Mesh?
Bij het toelichten van de 4 peilers van de Data Mesh is misschien al duidelijk geworden wat een Data
Mesh aan voordelen biedt. De belangrijkste uitdaging die de Data Mesh probeert op te lossen is het
knelpunt van een centrale data team. Nu steeds meer bedrijven stevig inzetten op datagedreven
werken neemt de vraag naar dataproducten toe. De centrale datateams hebben het hierdoor ontzettend druk. Het duurt steeds langer om data beschikbaar te krijgen omdat de backlog groeit en groeit. Daarnaast er is er ook meer behoefte aan data uit ander soort bronnen waar data niet- of op
een andere manier gestructureerd is. Denk hierbij aan sensor en machine data of video en spraak. De
hoeveelheid van data neemt hierdoor ook significant toe (hierdoor is de term ‘big data’ ook
ontstaan). Door meer in te zetten op zelf-service kan je het centrale datateam ontlasten.
De dataconsument verwacht ook een kant- en klare dataproduct. De data engineer is al superdruk en
dan moet de data engineer ook nog eens in de tijd die hij over heeft het domein van de
dataconsument goed proberen te begrijpen om met een dataproduct te komen wat naadloos
aansluit op de wensen van de consument. Dit is bijna onmogelijk. Door de domein specialisten in
staat te stellen om zelf dataproducten te maken lossen wordt deze tweede uitdaging ook op.
Door de Data Mesh wordt de organisatie in staat gesteld om bij te blijven bij snel veranderende
omstandigheden in de markt en technologie. Dit is nodig om de ambitie om (meer) datagedreven te
gaan werken waar te kunnen maken. Ook helpt de Data Mesh om iedereen in zijn of haar kracht te
zetten. Dus een data engineer in het verzamelen van data en een domein specialist om relevante
informatie uit die data te halen.
Hoe start je dan vervolgens met een Data Mesh?
Allereerst is het verstandig jezelf de vraag te stellen of Data Mesh in jullie huidige situatie en met het
huidige volwassenheids niveau ook daadwerkelijk iets toevoegt. En dit is dan ook meteen een erg
lastige vraag om te beantwoorden, maar vanuit yellow arrow proberen we IT simpeler te maken. Dus
dat gaan we hier ook doen aan de hand van de volgende vragen:
- Hoeveel domeinen binnen jouw bedrijf kan je identificeren die sterk afhankelijk zijn van data
of waar data een duidelijke toegevoegde waarde kan hebben.
- Is er al een centraal datateam en vormt dit datateam een bottleneck bij dataoplossingen? Op
een schaal van 1 tot 10, waarbij 1 ‘nooit’ en 10 ‘altijd’ betekend. - Heeft data governance prioriteit binnen jouw organisatie? Met andere woorden is er
behoefte en inzicht in zaken als eigenaarschap, betekenis- of herkomst van data. Op een
schaal van 1 tot 10 waarbij 1 ‘geen idee wat data governance uberhaupt is’ en 10 ‘ja enorm
behoefte aan meer grip op data en datastromen’ betekend. - Hoe belangrijk is kwalitatief goede data voor het nemen van beslissingen binnen jouw
organisatie (van strategisch tot operationeel). Ook weer op basis van een schaal van 1 tot 10
waarbij 1 ‘beter slechte data dan geen data’ en 10 ‘betrouwbare en correcte data is cruciaal
voor onze operatie en de beslissingen die wij nemen’ betekend.
Tel de uitkomst van de vier vragen bij elkaar op. Scoor je minder dan 10 punten dan is Data Mesh
waarschijnlijk nu nog niet interessant voor jouw organisatie. Scoor je tussen de 10 en 30 punten dan
is het goed om over Data Mesh na te denken. Begin met verdiepen in de Data Mesh en waar mogelijk
pas al op kleinschalige manier concepten en best-practice toe. Scoor je boven de 30 punten dan is
ons advies om serieus met Data Mesh aan de slag te gaan, omdat jouw organisatie sterk kan
profiteren van de voordelen van de Data Mesh.
Word je al enthousiast over de Data Mesh en zie je de voordelen binnen jouw organisatie? Dat is
mooi! Wacht dan ook niet tot het ideale moment zich voordoet om te starten. De kans is klein dat er
überhaupt een ideaal moment komt. Ook hier geldt weer ga er vooral mee aan de slag, start klein
(maar denk groot) en kies een geschikt pilotproject. Advies is ook om met 1 domein te beginnen. Je
zult eerst een basis moeten neerzetten om later andere domeinen te kunnen laten aanhaken. Deze
basis bestaat uit de volgende onderdelen:
Maak een on-boardingsplan voor de zelf-service medewerkers: Daar worden vragen beantwoord als: Wat betekend zelf-service data binnen jouw organisatie? Welke skills moeten de zelf-service medewerkers hebben? En hoe worden de medewerkers opgeleid?
- Leg de spelregels vast van de Data Mesh: Wat is een dataproduct? Waar moet een
dataproduct aan voldoen? Wat zijn de standaarden en richtlijnen om deze dataproducten op
een juiste en uniforme manier te ontwikkelen. En hoe borgen we de kwaliteit? - Hoe gaat data gedeeld worden zowel binnen- als buiten domeinen? Hier komt ook het data
contract om de hoek kijken. Beschrijf wat een data contract is en hoe data contracten
worden afgesloten. - Wat betekend deze federatieve data governance voor jouw organisatie? Wat brengt dat voor
eisen met zich mee met betrekking tot het voorbrengingsproces van data? - Wat is de impact op het huidige dataplatform. Moet je jouw data architectuur aanpassen om
het zelf-service principe goed te kunnen ondersteunen. En moet er extra tooling komen om
bijvoorbeeld data contracten vast te leggen en zijn de juiste middelen en tools aanwezig om
deze federatieve data governance te kunnen voeren?
Vanuit Yellow Arrow hebben wij de kennis en ervaring om te ondersteunen bij het implementeren van een Data Mesh. Wil je hier graag meer over weten? Download hier de whitepaper.
Geef een reactie