Ga je een nieuw datawarehouse ontwikkelen? Laat dan de standaarden en kleine details los. Het succes valt of staat met de functionaliteit die nodig is voor jouw architectuur. Bij het keuzeproces voor de juiste tooling speelt automation een sleutelrol.
Data automation tools kunnen bijvoorbeeld voorzien in functionaliteit voor de naamgevingsconventies, codepatronen en zelfs lagen, dus waarom zou je dan het wiel opnieuw uitvinden? Niet de standaarden, maar de juiste tools gaan je helpen om succesvol een modern datawarehouse te ontwikkelen.
Tijdrovend en gecompliceerd
Het ontwerpen van een nieuwe datawarehouse-architectuur wordt vaak als een tijdrovend en gecompliceerd proces gezien. En eerlijk gezegd is dat het ook. Er moeten een hoop beslissingen worden genomen, diverse componenten naast elkaar bestaan en met elkaar worden geïntegreerd. De architectuur moet aansluiten op de eisen en ook nog eens praktisch realiseerbaar en toekomstbestendig zijn.
In mijn jaren als data-architect en daarvoor, in mijn rol van consultant, merkte ik dat er veel tijd wordt besteed aan standaarden. En dat is helemaal prima. Maar deze standaarden vertegenwoordigen het verkeerde niveau van detail en worden op het verkeerde moment geschreven.
De ontwikkeling van een nieuwe datawarehouse-architectuur begint met het in kaart brengen van alle eisen. Dat begint met de waarom-vraag. Wellicht kom je om in de datasilo’s. Of misschien herinnert je bestaande datawarehouse je aan iets uit ‘Stranger Things’. Of heb je simpelweg nog geen datawarehouse. Er zijn tal van legitieme redenen om de inzet van een (nieuw) datawarehouse te overwegen.
Data vault
Zodra je duidelijkheid hebt over het waarom, kun je beginnen na te denken over het ‘waar’. Deze vraag is met de opkomst van meervoudig gestructureerde data, data lakes in het algemeen, belangrijk. Maar in het bijzonder door de opkomst van data warehousing in de cloud. De kans is groot dat je overweegt om je data in de cloud onder te brengen. Maar vergeet in dat geval niet om ook de waarom-vraag te stellen. De cloud biedt weliswaar aantrekkelijke voordelen, maar brengt mogelijk ook onnodige complexiteit en kosten met zich mee.
Dit brengt ons bij het ‘hoe’. Het beantwoorden van die vraag begint met de keuze van een referentie-architectuur zoals data vault, data lake en sinds kort ook data mesh of een hybride variant. Ook hier is de waarom-vraag van toepassing. Regelmatig kiezen organisaties zonder goede reden voor data vault. Alles waar je voor kiest moet echter waarde aan de architectuur toevoegen, omdat dit anders (wederom) alleen maar voor onnodige complexiteit en kosten zorgt.
Spiksplinternieuw
Op dit punt aangekomen beginnen we een idee te krijgen van hoe het datawarehouse eruit zal zien. Maar wat tot dusver nog niet is besproken, is de toolset. En daar is een goede reden voor: de tools moeten ondersteuning bieden voor de/het gekozen platform(s) en architectuur/architecturen. Want wat heb je aan een tool als je Snowflake wilt gebruiken terwijl die tool alleen ondersteuning biedt voor Synapse? Precies. Het was niet mogelijk om in een eerder stadium onderzoek te doen naar tools. Kunnen we wachten tot later?
Goed, je zou ervoor kunnen kiezen om elk detail van je spiksplinternieuwe architectuur vast te leggen en te beginnen met het specificeren van standaarden zoals naamgevingsconventies en lagen, ontwikkelings- en implementatieprocessen en codepatronen. Het resultaat? Een tot in de puntjes gedocumenteerde architectuur. Je zult al snel merken dat veel tools op dat punt zijn gediskwalificeerd omdat ze geen ondersteuning bieden voor al je standaarden.
Automatisering in plaats van perfectie
Kies daarom eerst een tool. En specifieker: kies een moderne tool voor data-automatisering. Die zal ingebouwde standaarden bieden en in de meeste gevallen toereikend zijn. Perfect ook? Nee. Streef niet naar technische perfectie, dat is nooit het doel. Het belangrijkste is dat je architectuur en tools de mogelijkheid bieden op uiterst gestandaardiseerde, krachtig presterende en stabiele wijze nieuwe pijplijnen naar het datawarehouse te creëren.
Daarnaast moet je zorgen voor flexibiliteit voor de data engineers die innovatieve logica ontwikkelen voor de uitgaande interfaces en informatie aanleveren aan front-end tools zoals Tableau en Power BI. Klinkt bekend in de oren? Jazeker, we hebben het hier over dataops.
Naamgevingsconventies en codeprincipes zijn absoluut nodig, en moeten bovendien zijn gestandaardiseerd. Maar er is geen reden om voor het ontwerp van je datawarehouse het wiel opnieuw uit te vinden en dat vervolgens op je fabrieksstandaard auto te plaatsen. De standaardwielen zullen toereikend zijn voor minimaal negentig procent van de rit, en je zult altijd in staat zijn om ruimte te bieden voor de uitzonderingen.
Definieer een ecosysteem en architectuur die op je eisen aansluiten, omarm de standaarden van de tool die je voorkeur geniet en richt je focus op het stroomlijnen van processen. Iedereen zal eraan gewend raken. Beloofd.
Rudyard Kipling’s Six honest serving men van 5W1H lijken de basis te vormen van verhaal. Punt is dat de miljoen hoe’s en de twee miljoen waar’s tot zeven miljoen waarom’s leiden door het probleem van de context. Fijn dat de auteur eerst een hamer kiest om vervolgens alles als een spijker te zien maar het begint bij definiëring van de vraagstelling van de verschillende wie’s. Wie hebben er belang bij een datawarehouse concept?
Dat is uiteraard helemaal correct! Een datawarehouse oplossing ga je niet voor de lol neerzetten, daar ligt altijd minimaal één business case (met belanghebbenden) aan ten grondslag. Voor de focus/context van het artikel is de “wie” buiten beschouwing gelaten en wordt het verhaal opgepakt nadat het besluit om een datawarehouse te bouwen al genomen is. Ik moet zeggen dat ik in mijn loopbaan ook nog niet heb meegemaakt dat er geen case en/of eindklant is. Wel wordt die soms uit het oog verloren, iets wat je kunt voorkomen door te blijven vragen “waarom”.
Als er veel geld mee gemoeid gaat, komen de six serving men vanzelf, alleen zijn ze niet zo honest.
Of de business case eerlijk is of niet hangt – zoals Rudyard Kipling stelt – grotendeels af van de verwachtingen want sommigen willen passende antwoorden. Waarom zou je een datawarehouse willen als iedereen in het blauwe water van een datalake springt?
Nu weet ik wat antwoorden te bedenken die niet passend zijn maar wel heel overtuigend omdat er ook nog zoiets is als de administratieve last van wet- en regelgeving. Het bij elkaar knippen en plakken van de bewijslast is vaak niet erg overtuigend als de ‘chain of custody’ niet klopt. En deze wordt veelal bepaald door het proces welke je digitaal kunt stempelen, bijvoorbeeld met een date-time-stamp of allerlei ‘blockchain’ alternatieven.
Het Engelse woord ‘honest’ kent namelijk een bredere uitleg dan alleen maar eerlijk en de data(c)ops moeten de integriteit van het proces bewaken door niet alleen de kwaliteit van de data zeker te stellen maar ook door ervoor te zorgen dat er geen giftige mengsels gemaakt worden middels de moderne datasynthese van Power BI e.d. want het zoeken naar passende antwoorden op basis van vooringenomenheid leidt tot een grotere argwaan aangaande moderne datawarehouses.