Een gedistribueerde data-architectuur is vooral een kwestie van (anders) organiseren

De teams hebben vaak te weinig tijd om aan alle verzoeken te kunnen voldoen, laat staan om data die aanwezig is binnen alle domeinen van de organisatie goed te leren begrijpen. Er is een alternatief dat sterk in opkomst is: de gedistribueerde data-architectuur, ook wel bekend onder implementatievormen als Data Mesh of Data Fabric. Maar hoe werkt een gedistribueerde data-architectuur? Wat is ervoor nodig? En hoe begin je ermee?

Data Mesh en Data Fabric

Laten we beginnen met Data Mesh en Data Fabric: feitelijk zijn dit twee verschijningsvormen van gedistribueerde data-architecturen.

• Data Fabric is een meer technische oplossing die zich richt op het verbinden van verschillende databronnen, op een geïntegreerde en naadloze manier, op basis van metadata. Hierdoor wordt data makkelijker toegankelijk en bruikbaar over de gehele organisatie.
• Data Mesh is een meer organisatorische aanpak die draait om een aantal principes, waarvan ‘data-as-a-product’ de belangrijkste is. Dit wil zeggen dat een domein verantwoordelijk is voor het beschikbaar stellen van analytische data als een product. Als je iets als product levert, moet je er ook voor zorgen dat dat product goed is, dat het aan bepaalde kwaliteitscriteria voldoet en dat je het product ondersteunt.

Waar in een centrale data-architectuur alle data in een organisatie op één centrale plek wordt verzameld, gaan beide verschijningsvormen van gedistribueerde data-architecturen ervan uit dat data kan worden beheerd waar deze ontstaat – bij verschillende afdelingen in de organisatie. Trouwens, ook al wordt het beheer van data gedecentraliseerd, data kan nog altijd op een centrale infrastructuur worden aangeboden aan gebruikers vanaf een centrale plek, zoals een datacatalogus of een zogeheten experience plane. Het voordeel van deze manier van werken is dat datateams veel minder functionele kennis hoeven te hebben, omdat data wordt beheerd bij de afdelingen die er de meeste kennis van hebben.

Grootste verandering is organisatorisch

Een andere uitdaging waar gedistribueerde data-infrastructuren een oplossing voor bieden, is modulariteit, vertelt Hans Geurtsen, Area Lead Data & AI bij Info Support: “Data die afkomstig is uit verschillende domeinen, kan soms hetzelfde genoemd worden, maar iets totaal anders betekenen. Een goed voorbeeld hiervan uit mijn eigen ervaring, is een verzekeringsmaatschappij waarin vaak werd gesproken over hitratio: de kans dat het uitbrengen van een offerte ook leidt tot een verkoop. Dat kun je uitdrukken in geld, in percentage en aantallen. Er zijn meerdere manieren om dat te berekenen. Het leek alsof iedereen hetzelfde ermee bedoelde, maar als je goed doorvroeg, dan bleek dat eigenlijk helemaal niet zo te zijn. De marketing-, sales- en de aftersalesafdeling hadden allemaal een verschillende definitie. Een gedistribueerde aanpak maakt het een stuk makkelijker om daarmee om te gaan.”

Ownership by Design

De belangrijkste verandering voor organisaties die overstappen op een gedistribueerde data-infrastructuur zijn dan ook niet technisch, maar organisatorisch van aard. Veel afdelingen krijgen er rollen en verantwoordelijkheden bij. In lijn met het ‘data-as-a-product’ principe, waarbij een domein verantwoordelijk wordt voor het leveren van analytische data als een product, moet een afdeling zelf een aantal dingen gaan doen die nu nog onder de verantwoordelijkheid vallen van centrale datateams.

“Er komt inderdaad meer verantwoordelijkheid te liggen bij verschillende domeinen”, aldus Hans. “En dat kan weerstand oproepen. Mensen denken dat ze opeens meer moeten doen dan wat ze tot nu toe hebben gedaan.”

De beste manier om de eerste stap te zetten richting gedistribueerde data-architecturen is dan ook ‘klein beginnen’. “Je hoeft niet meteen een geheel gedistribueerde architectuur te hebben. Het is slimmer om met één domein te beginnen waarvan je weet dat men positief staat tegenover het concept. Als je bewezen hebt dat het concept binnen één domein werkt, kun je de positieve feedback uit dat domein gebruiken om een volgend domein mee te krijgen. Zo creëer je draagvlak voor de domeinen waar men wat terughoudender is.”

Overstappen gaat eenvoudiger als het gaat om een nieuwe oplossing. “In dat geval kun je het ownership by design-principe toepassen”, aldus Hans. “Als je bijvoorbeeld een oplossing bouwt voor een HR-proces, dan maak je de HR-afdeling vanaf het begin al verantwoordelijk voor zowel het invoeren als het valideren van data, maar ook het analyseren of inzichtelijk maken van data voor de rest van de organisatie – een taak die nu nog vaak bij een centraal datateam ligt.”

De verwachte toekomstige groei van de hoeveelheid data maakt overstappen op een gedistribueerde data-infrastructuur steeds meer aantrekkelijk en zelfs noodzakelijk: “We gaan de komende jaren een golf aan AI-toepassingen zien, die ons steeds meer data oplevert, naast brondata ook gegenereerde data als uitkomsten van AI-modellen. Doorgaan op de huidige manier kan gewoon niet. De tip die ik aan bedrijven wil geven, is om hier echt naar te gaan kijken. Ga hierover nadenken en zorg dat je klaar bent voor die golf die eraan zit te komen.”