Jan van Til

Data quake of data ache?

Jan van Til

De hedendaagse organisatie is voortdurend in formatie – en haar informatie, dat kan niet anders, is daarmee dus óók onafgebroken in formatie. Niet alleen wat omvang en inhoud betreft, maar (juist) ook qua organisatie, qua structuur. Met name dat laatste stelt ons voor steeds nijpender problemen. Want de houdbaarheid van een eens gekozen organisatie verstrijkt steeds sneller. Onophoudelijk en onvermoeibaar speuren we naar werkelijke en duurzame samenhang in onze datalandschappen. En de jongste ‘solution’ op dat vlak is de zgn. data lake.

Onze eens zo stabiele wereld, de wereld van vaste en vertrouwde organisatie, structuren en verhoudingen … die wereld wordt alsmaar beweeglijker. Het bestaande verweekt a.h.w. waar je bij staat en loopt even later als zand tussen je vingers door – hoe steviger je greep erop, hoe sneller je met lege handen staat.

Vrijwel niets blijft nog lang hetzelfde en organisatie van informatie zou die beweeglijkheid als vanzelf moeten volgen. Maar dat gebeurt niet – ik zie het tenminste (nog) nergens. Onze IT-systemen kunnen de verlangde dynamiek niet of nauwelijks bijbenen. De time-to-market van veranderingen valt alsmaar slechter uit terwijl de markt haar keel schor schreeuwt om agility, om alignment, om snelheid enzovoort.

Dat kan zo niet doorgaan. Voor onze informatie moeten we daarom op zoek naar kwalitatief àndere structuren. Structuren waarmee techniek de nog altijd toenemende dynamiek weer soepel kan bijbenen. Structuren die a.h.w. automatisch mee-ademen met onze steeds sneller wisselende leef- en werksituaties. Mensen willen meer dan ooit vlot kunnen beschikken over actuele en voor hen relevante informatie van situationeel heldere betekenis. M.a.w. over action-able informatie: informatie die mensen met vertrouwen aanzet tot trefzekere actie!

Geen datawarehouse die ons dat gaat brengen. Data marts, wellicht? Nee, idem dito. En data lakes? Gaan data lakes ons wel een heuse stap verder brengen – voor een data quake zorgen? Data lakes lijken wel een breuk met het verleden in te houden. Uit hetgeen ik erover lees, begrijp ik dat besef is doorgebroken dat de doelen waarvoor mensen informatie nodig hebben niet langer op voorhand duidelijk hoeven te zijn.

Logisch! Want wie weet vandaag de dag nog welke problemen en vraagstukken zich morgen aan ons voor zullen doen? In een tot-en-met beweeglijke wereld wordt dat een steeds moeizamer onderneming. Just-In-Time èn First-Time-Right in een turbulente omgeving. Dàt zijn de vlaggen die prominent en hoog in top wapperen in wind van dagelijkse dynamiek.

Twee vragen borrelen naar de oppervlakte:

1. Hoe organiseren (modelleren) we de variërende, veelvormige en continu binnenstromende informatie in een data lake?

2. Hoe komen we op basis van een dergelijke organisatie tot ontsluiting van informatie die past bij het scala aan bekende en (nog) onbekende problemen/vraagstukken die zich aan ons voordoen?

Een reactie erop zou kunnen zijn: “Kom op zeg, zo ingewikkeld is het nu toch ook weer niet?!”, en vanuit dergelijke ontkenning laten we onze data gewoon in zoiets als een modern en geavanceerd hadoop-cluster binnenstromen … en vestigen onze hoop op geavanceerde technologie en de kennis en kunde van onze design thinkers en intellligent data scientists. Dan zijn we er toch?

Ja en nee. Op die manier wordt een data lake al heel snel een data swamp – boordevol met infarct bevorderende dataproppen van allerhande snit en makelij … een swamp waarin ook onze data scientists zich na verloop van tijd als drenkelingen ontpoppen – luid schreeuwend om reddingsboeien en andere hulpmiddelen. Nee, we zullen onze data scientists een noodzakelijk handje moeten helpen en komen niet onder de gestelde vragen uit. Ja, we zullen onze achterstand op het gebied van organisatie van informatie moeten erkennen èn inhalen! Kunnen we het aantal doorbraken ná de ontwikkeling van de zgn. normaalvormen – rond 1970; zo’n 45 (!) jaar geleden – niet met grootst gemak op de vingers van één hand tellen?

Hoe voorkom je chaos in een magazijn? Door voortdurend kraakhelder te hebben welke elementen van welke toeleveringen waar precies in het magazijn terecht moeten komen. Kortom: weten wat je in huis hebt en waar het staat. De enige manier om snel, efficiënt en trefzeker te kunnen leveren.

Hoe zien toeleveringen in het geval van een magazijn a la data lake er uit? Als brokken data volgens-bepaald-model. En dat (data)model heeft veel weg van het vloerplan van het magazijn van het toeleverende systeem. Dat systeem bevat daarnaast natuurlijk ook de nodige (magazijn)instructies. Instructies die bepalen hoe dat vloerplan/model door het toeleverende systeem wordt gelezen en beschreven.

Hoe wordt zo’n brok data-volgens-bepaald-model verwerkt in een data lake? Een data lake is niets anders dan een groot, general purpose magazijn met een eigen vloerplan annex magazijninstructies. Zo’n binnenkomend brokje data-volgens-bepaald-model wordt conform passende magazijninstructies geanalyseerd tot … algemeen bruikbare elementen. De aldus geïdentificeerde elementen worden conform vloerplan op de juiste plek in het general purpose magazijn geplaatst.

Waarom moet een data lake een eigen vloerplan hebben? Wat is er mis met de vloerplannen van onze bestaande systemen? Voor de systemen zoals we ze tot op de dag van vandaag ontwerpen en bouwen, geldt heel sterk dat de vloerplannen steeds volledig ingestoken zijn op specifieke en vooraf bekende problemen. Ook zijn ze vaak precies op maat gemaakt met het oog op het bereiken van heel specifieke, vooraf gestelde doelen. In het geval van een data lake kennen we de problemen en/of gebruiksdoelen niet (goed) en daarom is een general purpose vloerplan nodig. Want alleen op die manier kan een data lake alle mogelijke doelen dienen, alle mogelijke problemen helpen oplossen zonder dat deze op voorhand bekend moeten zijn.

Hoe zien leveringen vanuit een magazijn a la data lake er uit? Vanuit het eigen vloerplan annex magazijninstructies levert een data lake data o.b.v. zoiets als een data-catalogus. Die catalogus bevat een opsomming van alle beschikbare elementen inclusief gebruiksmogelijkheden en -voorwaarden. Klanten shoppen via de catalogus in de data lake en voegen alle benodigde elementen (mits gerechtigd) toe aan hun winkelwagen. Na het passeren van de kassa combineren/verwerken klanten hun verworven elementen in het eigen systeem tot de gewenste informatie annex presentatie t.b.v. invulling van eigen doeleinden.

Hoe ziet een vloerplan van een data lake er uit? Zo’n vloerplan is een netwerk, of, nog wat algemener gesteld, een systeem. Een systeem van onderling gerelateerde virtuele plekjes-op-de-vloer (knooppunten in het netwerk/systeem). Op z’n allersimpelst (metaforisch) voor te stellen als een enkele kerstboom; een stam-en-takken structuur. Als data-elementen gelden de ballen, de sterren, de engeltjes, de piek etc. – deze elementen hangen aan de uiteinden van de takjes (de plekjes-op-de-vloer). Navigeren naar een element ‘loopt’ over de stam-en-takken structuur van de kerstboom. Toeleveringen van data zorgen voor het steeds verder optuigen van de kerstboom. Het bekijken/bewonderen van (gedeelten van) de (kerstboom)versiering komt overeen met shoppen annex het leveren van setjes data-elementen.

Wat stellen we ons voor bij magazijninstructies? Grofweg zijn er drie groepen instructies: Innemen, Plaatsen en Leveren van data.

Innemen. Er wordt alleen van erkende bronnen annex modellen data ingenomen. Na controle en acceptatie vindt …

Plaatsen. … opslag van de data plaats volgens het eigen vloerplan. De opgeslagen data wordt vervolgens gerelateerd aan het generieke vloerplan van het data lake. De data-catalogus wordt bijgewerkt op basis waarvan …

Leveren. … verzameling (shopping list) en levering (kassa) van data plaatsvindt.

Waarom zou een toeleverancier nog zelf z’n data (bij)houden? Met een data lake, zoals zojuist beschreven, is dat, inderdaad, niet langer noodzakelijk. Wanneer toeleveranciers (grote delen van) hun data (gefaseerd) zouden willen afstoten naar een data lake … kunnen we op termijn volledig overstappen op het generieke vloerplan van een data lake. Negatieve effecten als duplicatie, inconsistentie, gebrekkige kwaliteit, vage betekenissen, alsmaar stijgende ontwikkel- en beheerlasten, verslechterende time-to-market enzovoort … kunnen op een dergelijke manier nòg effectiever worden bestreden. Het data lake werkt dan immers steeds meer als een robuuste infrastructuur voor bedrijfsinformatie.

Wat is het belang van de data-catalogus? Zo’n catalogus is een wezenlijk onderdeel van een data lake en wordt continu en parallel aan de binnenkomst-en-verwerking van data bijgewerkt. Welke data? Wat is de herkomst? De kwaliteit? De reden voor verzameling? Wie is eigenaar? Wie zijn de (potentiële) gebruikers? Wat zijn de gebruiksvoorwaarden? Wat is het toepassingsbereik? enzovoort.

Zo’n data lake staat/valt, als ik het goed begrijp, met een goed doordacht vloerplan annex magazijninstructies. Klopt dat? Dat is de spijker op z’n kop! Zonder goed doortimmerd vloerplan en nauw ermee verweven magazijninstructies komt een data lake – hoe goed bedoeld ook – niet van de grond. Zo’n lake verzand al vlot in een swamp en wordt een data ache.