Sinds wanneer klopt je dataplatform niet meer? Een governance-checklist

Made with AI

De meeste dataplatforms gaan niet met veel kabaal onderuit, ze takelen langzaam af. Hier een workaround, daar een schemawijziging, een nieuw team met andere eisen dat wordt vastgeschroefd aan een architectuur die voor iets anders is ontworpen.

Tegen de tijd dat de symptomen zichtbaar zijn, trage pipelines, steeds meer uitzonderingen, een datateam dat meer tijd kwijt is aan onderhoud dan aan bouwen, is het oorspronkelijke ontwerp allang verdwenen. Wat overblijft, is een opeenstapeling van beslissingen die onder tijdsdruk zijn genomen, de meeste destijds redelijk.

De juiste vraag is niet "moeten we opnieuw bouwen?" maar "begrijpen we wat we hebben?" Deze checklist helpt die vraag te beantwoorden.

Het signaal dat er iets is veranderd

Het vroegste teken dat een platform zijn ontwerp is ontgroeid, is meestal niet technisch. Een datateam dat opziet tegen bepaalde tickets, een engineer die weet welke delen van het systeem je beter kunt mijden, of een productmanager wiens verzoeken steeds langer duren dan verwacht.

Deze signalen gaan vooraf aan de technische symptomen. Het loont om erop te letten voordat ze duur worden.

Acht vragen om je dataplatform te stellen

Zorg voor antwoorden op deze vragen voordat je aan een architectuurreview begint:

1. Kun je elke pipeline in het platform uitleggen aan iemand die hem niet heeft gebouwd?
2. Wanneer heb je voor het laatst iets veranderd en wist je zeker dat er niets anders door zou breken?
3. Gebruiken alle teams die over dezelfde metric rapporteren dezelfde definitie?
4. Zijn je datacontracten gedocumenteerd: wat je ontvangt, wat je transformeert, wat je oplevert?
5. Weerspiegelt de architectuur van het platform hoe het bedrijf data vandaag gebruikt, of hoe het data gebruikte toen het platform werd ontworpen?
6. Als een bron eerder in de keten verandert, hoe kom je daarachter: proactief, of pas als er iets breekt?
7. Kan je datateam het volledige beeld binnen een week overdragen aan een nieuwe engineer?
8. Welk percentage van de tijd aan het platform gaat naar onderhoud en welk naar nieuwe functionaliteit?

Zijn de antwoorden ongemakkelijk, dan is dat nuttige informatie.

Wat de antwoorden laten zien

De vragen hierboven brengen meestal een van drie situaties aan het licht. De eerste is te overzien: het platform is gezond, maar de documentatie heeft het tempo niet bijgehouden. De oplossing is een sprint die draait om documentatie in plaats van code.

De tweede is lastiger: de architectuur heeft technische schuld opgebouwd die documentatie niet kan oplossen. Kernpipelines zijn niet ontworpen voor de huidige volumes. Belangrijke transformaties zijn ongedocumenteerd en kwetsbaar. De oplossing vraagt om een migratieplan.

De derde komt het meest voor: een mix van beide. Sommige delen van het platform zijn solide. Andere worden bij elkaar gehouden door kennis in de hoofden van mensen en workarounds. De taak is ze duidelijk van elkaar te scheiden.

Wat je doet voor de volgende sprint

Voordat de volgende sprint begint, breng je in kaart waar het platform staat ten opzichte van wat het bedrijf ervan nodig heeft. Die inventarisatie hoeft niet uitputtend te zijn. Zelfs een ruwe kaart van wat solide is, wat kwetsbaar is en wat onbekend is, verbetert het planningsgesprek.

De teams die dure revisies van hun dataplatform voorkomen, zijn niet de teams die nooit problemen hebben. Het zijn de teams die problemen vroeg opmerken, op het moment dat ze nog te overzien zijn. Weet je niet waar je moet beginnen? Praat met ons datateam.