Introductie

Veel organisaties streven ernaar om “data-driven” te zijn. Dit heeft impact op de architectuur en organisatie van een bedrijf. Data werd altijd gezien als bijvangst, maar is tegenwoordig steeds belangrijker om goede beslissingen te kunnen nemen. De architectuur rondom data verandert ook qua mogelijkheden zoals data warehouse, data lakes en een nieuw paradigma genaamd data mesh. Deze blog geeft een introductie over dit data mesh concept en de impact op de architectuur en organisatie.

Waarom een nieuwe architectuur?

Een centraal data warehouse en/of een data lake levert in de praktijk toch niet altijd op wat een organisatie er van verwacht had. Opleveringen duren vaak lang, de kosten zijn hoog en de waarde uit de data is laag. Hiervoor zijn verschillende oorzaken aan te wijzen:

• Complexe ETL jobs
• Complexe data structuren
• Geen duidelijke beschrijvingen van de data beschikbaar
• Centraal team heeft de eigenaarschap van de data maar heeft vaak weinig business kennis
• Geen focus op data

Ook derde generatie data architecturen zoals cloud oplossingen en streaming oplossingen (zoals Kafka) leveren niet het gewenste effect. Dit werd ook onderkent door Zhamak Dehghani van ThoughtWorks in 2019 en zij opperde een nieuw architectuur paradigma: Data mesh

Wat is een Data mesh?

In de basis is een Data mesh gebaseerd op het alom bekende architectuur principe “strong-cohesion” en “loose-coupling”. Het is in feite object-georiënteerde-, domein gedreven- of microservices architectuur maar dan in het groot. Dit alles beschreven in een viertal principes:

• Gedistribueerde Domein Gedreven Architectuur
• Data als een product
• Zelf-service data infrastructuur als een platform
• Gefedereerde governance

In de volgende secties komen de verschillende principes kort aan bod.

Principe 1: Gedistribueerde Domein gedreven Architectuur

In de operationele systemen wordt vaak domein gedreven architectuur toegepast, maar de analytische data laag is meestal centraal. In een data mesh architectuur wordt de data ownership verplaatst naar de functionele domeinen. Zij zijn verantwoordelijk voor de kwaliteit van de data en deze data ook op een consumable manier beschikbaar te stellen. Het functionele domein weet vaak ook het beste hoe de data eruit ziet en wat de betekenis is. Ook de cleansing, deduplicatie en verrijking wordt door het domein zelf gedaan, ook weer omdat zij de data het beste kennen. Het domein is verder verantwoordelijk voor de Service Level Objectives die aan de data gesteld wordt.

Aangezien het domein verantwoordelijk is voor de data, sluit het volgende principe hier goed op aan: Data as a Product.

Principe 2: Data als een product

Als domein ben je verantwoordelijk voor de data en behandel je deze data als product(en) voor de consumers van de data. Je draagt zorg voor alle functionele- en non-functionele karakteristieken van de data zoals kwaliteit, beschrijvingen, vindbaarheid, veiligheid, betrouwbaarheid. Verder ben je als cross-functioneel team ook verantwoordelijk voor de code, pipelines, api’s en events gerelateerd aan de domein data. Hierdoor zullen er ook nieuwe rollen ontstaan binnen dit team zoals een Data Product Owner en zullen Data Engineers verschuiven van centraal naar lokale domein teams.

Aangezien het team ook verantwoordelijk is voor de code en infrastructuur resources, is het handig wanneer veelgebruikte resources makkelijk beschikbaar zijn voor de verschillende teams. Hiervoor is het derde principe belangrijk, namelijk een zelf-service data infrastructure as a platform.

Principe 3: Zelf-service data infrastructuur als een platform

Aangezien verschillende infrastructurele resources over de verschillende domeinen gebruikt worden, is een zelf-service platform noodzakelijk. Hierbij kun je denken aan data storage voor de opslag van data, streaming resources, api manager, data pipelines en een data catalogue voor de beschrijving en vinden van data sets. Merk op dat al deze services zijn domein agnostisch en bevatten nooit business functionaliteit. Een zelf-service betekent in dit geval dat niet het infra team nodig is, maar dat deze resources via services zelf kunnen worden aangevraagd en gebruikt. Dit maakt de toegang tot deze resources voor de teams makkelijker en sneller.

Data products moeten ook met elkaar samenwerken en dit heeft tot gevolg dat sommige zaken op centraal nivo moeten worden geregeld. Hiervoor is het laatste principe namelijk federated computational governance.

Principe 4: Gefedereerde governance

Sommige zaken zullen centraal moeten worden geregeld aangezien je bijvoorbeeld op analytisch nivo correlaties wilt kunnen vinden tussen data producten waarbij klant-nummers gebruikt worden als referentie. Ook op interface nivo is standaardisatie gewenst om interoperaliteit te garanderen. Hiervoor is globale standaardisatie nodig waarbij data product owners en platform product owners centraal afspraken maken. Het is soms balanceren welke zaken je lokaal in de domeinen oplost en welke zaken centraal. Het uiteindelijke doel van dit centraal orgaan is om de data producten samen te kunnen laten werken.

Conclusie

Zoals je merkt heeft een data mesh zowel een sterk technisch- als organisatorisch karakter, waarvoor een cultuuromslag nodig zal zijn in bepaalde organisaties. Uitdagingen die ik persoonlijk zie bij een data mesh:

• Inrichting cross-functionele teams
  Mensen zitten toch vaak graag bij gelijkgestemden of mensen zijn gewoonweg schaars (bv data engineers)
• Data beschikbaar stellen
  Het domein team zal ook data beschikbaar moeten stellen waarvan ze zelf niet 1-2-3 een voordeel hebben. Productontwikkeling en klantvriendelijkheid is hier echt noodzakelijk en het is verder kijken dan je eigen team
• Platform team de bottleneck
  Aangezien infra resources op een zelf-service manier beschikbaar gesteld moeten worden aan de verschillende domein teams kan het platform team een bottleneck worden. Dit kan wellicht worden opgelost door lokale domein developers ook in het platform team te laten meehelpen, aangezien zij vaak het beste de behoefte kunnen inschatten.

Wat mij in ieder geval bevalt aan het data mesh architectuur paradigma is dat de verantwoordelijkheid van de data bij de mensen ligt. Deze mensen hebben er vaak ook het meeste verstand en kennis van. Wanneer je bijvoorbeeld een database moet onderhouden zonder dat je weet voor welke business, en erger nog helemaal geen binding hebt met die business, dan staan mensen er toch anders in. Hetzelfde geldt voor andere technische implementaties die nodig zijn om de kwaliteit van de data te garanderen. Ik vind het een goede en logische ontwikkeling van data architectuur!

Een data mesh is een mooi architectuur paradigma dat we hier bij SynTouch ook toepassen op onze SIDAF (SynTouch Integratie- en Data Framework).