Vermijd het Hier-en-nu denken als het om data gaat!
In een tijd waarin steeds meer organisaties datagedreven (willen gaan) werken wordt het data-engineering vak steeds belangrijker. Bij data-engineering denk ik aan het maken van een doordacht ontwerp en het vervolgens bouwen van een dataproduct, zoals een BI-oplossing. Dit ontwerp moet niet alleen voldoen aan de huidige eisen, maar ook voorbereid zijn op toekomstige veranderingen. Hier ligt dus een spanningsveld. Maar al te vaak constateer ik dat binnen dataprojecten de voorkeur gaat naar korte termijn winst. Ik noem dit vaak (licht smalend, ik geef het toe) het Hier-en-nu denken.
Verder lijkt het wel, met de opkomst van AI, machine learning en steeds toegankelijker rapportage en analyse tools, of data architectuur en data modelling aan belang hebben ingeboet. Echter een goed doordacht datamodel staat nog altijd aan de basis van goede datakwaliteit, wat op zijn beurt essentieel is voor betrouwbare informatieproducten. Het is niet zo dat een informatieproduct automatisch van goede kwaliteit wordt zodra er maar genoeg complexe bewerkingen op inconsistente onderliggende data worden losgelaten. Bovendien zijn deze complexe bewerkingen meestal afkomstig uit een of andere bouwdoos en zodat diep begrip ervan niet noodzakelijk is. Als de data waarmee gewerkt wordt van matige kwaliteit is, zal deze matige kwaliteit slechts worden uitvergroot door er een hoop bewerkingen op los te laten.
Enkele voorbeelden van het Hier-en-nu denken:
Voorbeeld 1
Als een BI oplossing nog in de kinderschoenen staat, niet investeren in een robuuste architectuur van je datawarehouse maar het “lekker simpel houden” wat vaak neerkomt op een enkele datamart met daarin een starscheme dat rechtstreeks uit een bronsysteem gevuld wordt. Misschien voldoet deze eenvoudige oplossing nu, maar er wordt vergeten dat in de toekomst eisen en omstandigheden kunnen veranderen Misschien komen er wel meer datamarts voor verschillende gebruikersgroepen die deels gebaseerd zijn op dezelfde data. Misschien komt er wel een nieuw bronsysteem bij of verandert het huidige bronsysteem. Alle laadlogica (historie bewaren, data integreren, business rules toepassen, etc.) lekker compact bundelen en verweven op een punt is dan meestal geen goed idee.
Voorbeeld 2
Op dit moment bekende datakwaliteitsproblemen hardcoded in de ETL van het datawarehouse op lossen. Bijvoorbeeld: Klant met klantnummer 123456 staat ook in het bronsysteem geregistreerd onder nummer 444444. In de ETL is daarom een regel opgenomen dat alle orders die in de bron gekoppeld zijn klant 123456 in het datawarehouse moeten worden gekoppeld aan klant 444444. Dat er morgen weer andere klanten dubbel geregistreerd blijken te zijn, zijn dan zorgen voor morgen.
Voorbeeld 3
ETL code slordig opzetten. Geen aandacht schenken aan leesbaarheid van je code. Bijvoorbeeld slechte layout van programmacode, SQL statements met subqueries in subqueries in subqueries, het gebruik van SELECT * en natuurlijk nergens commentaar.
Zeg nu zelf: Welke code debug je het liefst?
Dit…
..of dit?
Als je voor voor de lekkere compacte optie 1 gaat ben je dus zelf onderdeel van het probleem. 😉
Maar alle gekheid op een stokje, dit soort rommel komt echt tergend vaak voor.
Voorbeeld 4
Ook het meerdere malen definiëren van eenzelfde bewerking is vaak uiting van het Hier-en-nu denken. Zie onderstaand eenvoudige voorbeeld waarin de berekening voor gemiddelde omzet (GemOmzet) op twee plaatsen is gedefinieerd in de ETL voor een datawarehouse.
Enkele tips ter bestrijding van het Hier-en-nu denken
Kijk in je glazen bol
De eerste tip ligt voor de hand: Kijk niet alleen naar de nu geldende requirements maar in te schatten welke eisen er in de toekomst gesteld gaan worden aan je dataoplossing. Zeker als een organisatie net begint met de transitie naar datagedrevenheid is de BI omgeving vaak nog lekker overzichtelijk. Maak het jezelf in het begin niet onnodig te moeilijk maar probeer in ieder geval voor te sorteren voor het moment dat er complexere eisen gesteld gaan worden. Dit geldt voor alle betrokkenen, van data-architect tot ontwikkelaar.
Smeed één wapen voor alle gevechten
Denk generiek. Vervang hardcoded regels waarin id’s letterlijk genoemd worden door een generieke aanpak. Het bovenstaande voorbeeld 2 van de klant die dubbel geregistreerd staat in de bron zou je bijvoorbeeld kunnen oplossen door een van-naar mapping tabel aan te leggen en deze vervolgens gebruiken in de ETL gebruiken om de vertaalslag te definieren. Toekomstige dubbele registraties kan je dan inregelen door een extra record aan de mapping tabel toe te voegen. Geen onderhoud aan je code nodig!
Wees dodelijk consequent
Pak soortgelijke zaken op soortgelijke wijze aan. Wees consistent. Dit komt de onderhoudbaarheid overdraagbaarheid van je oplossing ten goede. Neem nooit shortcuts, hoe verleidelijk dat ook is. Een shortcut is namelijk een uitzondering, en die zul je dus moeten gaan onthouden, overdragen en een speciale afwijkende behandeling geven. Dat willen we dus niet!
Verdeel en heers
Bouw een dataarchitectuur met meerdere lagen, ieder met hun eigen functie (segregation of concerns). In ieder geval moet daar inzitten: een staging laag, een dataintegratielaag en een informatielaag (je datamarts en andere voorbewerkte datamodellen toegespitst op wat je informatieproducten vereissen) een informatieproductlaag (zoals dashboards, BI rapportages, data exports tbv dataanalyse etc).
Voorzie je architectuur, zover mogelijk stroomopwaards altijd van een genormaliseerde datalaag ter vermijding van redundantie.
Houd het droog
Hang het DRY principe aan. Dit staat voor Don’t Repeat Yourself. Dit is een fundamenteel principe binnen softwareontwikkeling dat stelt dat elk stukje kennis (zoals een berekening, functie of business rule) slechts op één plek in de codebase mag bestaan. Voordeel is dat als in de toekomst wijzigingen noodzakelijk blijken in de bestaande logica, je deze maar op een plek hoeft door te voeren. Kortom: Herhaling in code is de vijand van schaalbaarheid en onderhoudbaarheid. Bekijk ter illustratie eens hoe de code uit voorbeeld 4 kan worden herschreven volgens het DRY principe:
Regeer met ijzeren hand
Plaats een spin in het web. Zorg ervoor dat een klein slagvaardig team van minstens twee personen (ivm continuiteit) in de organisatie het overzicht houden over de dataarchitectuur en de implementatie met een mandaat om in te grijpen waar nodig. Klinkt dit dictatoriaal? Absoluut. Maar laten we eerlijk zijn: systeemontwikkeling is geen democratie. Je wilt geen architectuur waarin iedere ontwikkelaar zijn creatieve ei kwijt kan. Consistentie en een strakke visie zijn geen luxe, maar pure noodzaak. Een strak geleid data-ecosysteem voorkomt dat je over een paar jaar een digitale ruïne moet proberen te renoveren. De spin heft zijn scepter, zwaait met je ER-diagrammen en regeert met rechtvaardige, maar ijzeren hand.
😉