Modelleren is communiceren; deel 2 van 2

Welkom terug bij Data met impact. Ik ben Jeroen Buisman, en dit is het tweede deel van mijn verhaal over modelleren als communiceren.

Mocht je hier binnenvallen zonder deel één gehoord te hebben: luister daar dan eerst even naar, want dit is echt het vervolg. In het kort kwam het hierop neer: een datamodel is een boodschap, niet alleen een technisch kunstje, en we zijn de drie lagen langsgegaan waarin die boodschap vorm krijgt: de naamgeving, de structuur en de betekenis.

In dit tweede deel bouwen we daarop voort. We kijken naar de taal die om het model heen zit, naar wat het je nou eigenlijk oplevert, naar de rol van AI, en naar de mens.

Tot nu toe heb ik het gehad over het model zelf. De tabellen, de velden, de structuur, de betekenis. En ik wil nu iets bespreken dat minstens zo belangrijk is.

Het model is niet het enige wat je achterlaat. Er is ook de taal waarmee je het model gebruikt en beschrijft. De query waarmee je de gegevens ophaalt. De code waarin je je logica giet. De documentatie, of het gebrek daaraan. En dat alles communiceert net zo hard als het model zelf.

Een query, even kort uitgelegd, is de opdracht waarmee je gegevens uit de database opvraagt. En je kunt zo’n opdracht op twee manieren schrijven. Je kunt ‘m zo opschrijven dat een ander ‘m kan lezen als een verhaal, met heldere namen en een logische opbouw. Of je kunt ‘m zo opschrijven dat hij werkt, en verder niemand er ooit nog iets van snapt, inclusief jijzelf over drie maanden.

Maar het gaat verder dan die losse query. Het gaat ook over consistentie tússen je queries. Dat de onderdelen van een query altijd op dezelfde plek staan, in dezelfde volgorde. Dat je aliassen, de korte bijnamen die je aan tabellen en velden geeft, helder en steeds hetzelfde zijn. Dat de opbouw herkenbaar is, query na query. En dat dat geen toeval is, maar een werkafspraak, iets wat je als team afspreekt en waar je je aan houdt, zodat de een direct de query van de ander kan lezen, zonder zich er eerst doorheen te worstelen.

Datzelfde geldt ook voor de manier waarop je je laadproces inricht, het proces waarmee je data uit je bronnen haalt, bewerkt en in je datawarehouse zet. Hoe dat is ingericht, waar wat gebeurt, op welke manier: ook dat is communicatie. Dat op een consistente manier doen, met stappen die op een vaste manier zijn gelabeld, eigenlijk net als het tabellen en velden zijn die je een naam geeft, zorgt er voor dat je geen tijd kwijt bent aan begrijpen hóe het gebeurt, maar je als ontwikkelaar kan concenteren op wát er gebeurt, op de logica.

En daar speelt een mooie afweging. Het is een goed uitgangspunt in software-ontwikkeling om code te schrijven die één ding doet, en ook echt alléén dat. Maar, soms wil je je logica op één plek hebben. Want een ingewikkelde berekening is veel makkelijker te begrijpen als je ‘m in één keer op je scherm ziet staan, dan wanneer je steeds heen en weer moet springen tussen tien plekken om te snappen wat er nou eigenlijk gebeurt. Het is een afweging tussen herbruikbaarheid van componenten, en alles op één plek houden zodat het eenvoudiger leesbaar is; en voor mij valt het dan toch regelmatig de kant op van de leesbaarheid.

En hier wil ik echt een punt van maken: die leesbaarheid is geen extraatje. Het is geen luxe voor als je tijd over hebt. Het is onderdeel van de modellering zelf. Want de volgende persoon die jouw werk moet begrijpen, leest niet alleen je tabellen. Hij leest je queries, je laadproces, je documentatie. Dat is allemaal samen de boodschap. Een prachtig consistent model met onleesbare queries eromheen is als een keurig geschreven brief in een handschrift dat niemand kan ontcijferen.

Datzelfde geldt voor documentatie. Ik weet het, documentatie heeft een saai imago. Maar documentatie is gewoon: hardop opschrijven wat je anders impliciet laat. Het is de aantekening bij de boodschap. Waarom heb ik deze keuze gemaakt? Wat is hier de uitzondering, en waarom? Dat hoeft geen boekwerk te zijn. Eén goede zin op de juiste plek kan de volgende persoon een halve dag uitzoekwerk besparen.

Nu hoor ik je misschien denken: dit klinkt als heel veel zorgvuldigheid, en zorgvuldigheid kost tijd. Klopt dat?

Ja, deels. Het kost vooral denkwerk aan de voorkant. En dat denkwerk is niet niks, dat zei ik al over die ene goede naam. Duidelijk communiceren is moeilijker dan onduidelijk communiceren, dat is in taal zo en in datamodellen ook.

Maar daar staat veel tegenover. Veel meer dan je op het eerste gezicht zou denken, want de winst zit niet op één plek, hij zit overal een beetje, en dat telt op.

Laten we beginnen bij de tijd. In een helder model hoeft niemand die na jou komt nog uit te zoeken hoe het in elkaar zit. Geen middagen meer kwijt aan het reconstrueren van wat een veld betekent, geen mailtjes naar de collega die het ooit gebouwd heeft, geen voorzichtig aftasten of je wel de goede tabel te pakken hebt. De nieuwe collega is in een dag aan de slag in plaats van na drie weken. En jijzelf, over een half jaar, leest je eigen werk en begrijpt het meteen, in plaats van dat je je eigen sporen moet navlooien als een detective. Al die uren die anders in uitzoeken verdwijnen, gaan nu naar het werk waar het echt om draait.

Dan de fouten. Een groot deel van de fouten in rapportages komt niet doordat iemand niet kan rekenen, maar doordat hij uitging van een verkeerde aanname. Hij dacht dat dit veld iets anders betekende dan het deed. In een helder model zijn er veel minder van die aannames nodig, want het staat er gewoon. Minder verkeerde aannames betekent minder fouten, en minder fouten betekent minder kostbaar herstelwerk achteraf, en minder beslissingen die op een wankel cijfer zijn genomen.

En dan is er nog iets, en dat verbindt deze aflevering met waar deze podcast eigenlijk steeds over gaat: vertrouwen. Niet bij de eindgebruiker, dat is een ander verhaal, maar tussen de bouwers onderling. In een team waarin het model klopt, durft iedereen op elkaars werk voort te bouwen zonder alles te dubbelchecken. En zodra dat vertrouwen er een paar keer doorheen is gezakt, omdat de cijfers elkaar tegenspraken, omdat een aanname verkeerd bleek, gaat iedereen weer alles zelf controleren. En dan ben je precies de snelheid kwijt die je dacht te winnen. Vertrouwen bouw je traag op en breek je snel af, ook in een datamodel.

Tel het bij elkaar op: minder uitzoektijd, minder fouten, minder herstelwerk, meer vertrouwen, en straks ook nog een betere uitgangspositie voor AI. Dat is geen vaag voordeel ergens in de toekomst. Dat is iedere week winst, voor iedereen die met dat model werkt.

En dan nu: AI.

Want je zou kunnen denken: met al die slimme AI-tools van tegenwoordig, maakt het straks toch niet meer uit hoe netjes mijn model is? Dan zoekt de AI het toch wel voor me uit? Nou, ik denk dat het precies andersom is. Ik denk dat juist in het AI-tijdperk een helder en duidelijk ontwerp, heldere queries, een doordachte structuur, eenduidige betekenissen, alles waar ik het vandaag over heb gehad, belangrijker wordt dan ooit.

En dat zit zo. Een AI weet niets uit zichzelf. Een AI weet alleen wat je ‘m vertelt. Dat is de context: alles wat de AI op dat moment voor zich heeft om mee te werken. En als je een AI, een zogeheten coding agent, een agent die met je code en je datamodel aan de slag gaat, op pad stuurt in een rommelig model, dan gebeurt precies hetzelfde als bij die nieuwe collega van het begin van deze aflevering. Alleen erger.

Want stel je voor dat je elke keer tegen die AI moet zeggen: nee, hier heet dat veld zus, maar twee tabellen verderop heet het zo. Of: ja, dat veld heet wel datum, maar er staat eigenlijk een datum mét tijd in. Behalve in die ene tabel, daar is het echt een datum. En: let op, opname betekent hier iets anders dan daar. Dan voel je wel aan dat dat misgaat. Je bent de hele tijd aan het corrigeren, aan het bijsturen, aan het uitleggen wat er eigenlijk had moeten staan. En een AI vraagt niet eens netjes na zoals een mens dat doet. Een AI neemt aan, en gaat door. Met een zelfvertrouwen waar je u tegen zegt, en in de verkeerde richting.

In een helder model gebeurt het omgekeerde. De AI leest je naamgeving, ziet het patroon, “snapt” de structuur, vindt de definities, en kan er meteen goed mee werken. Net als die nieuwe collega die na één dag productief was. Alles wat een model leesbaar maakt voor een mens, maakt het ook bruikbaar voor een AI. Een goed gecommuniceerd model is goede context. En goede context is precies waar een AI op draait.

En daar zit volgens mij de echte verschuiving. De teams die hun fundament op orde hebben, die helder en consistent gebouwd hebben, díé teams gaan vooroplopen met de toepassing van AI in hun werkproces. Niet omdat ze de slimste tools hebben, want die tools heeft iedereen, maar omdat hun model, én alles er omheen, op orde is en de AI er dus mee uit de voeten kan. En de teams die het niet op orde hebben, die zullen merken dat AI hun rommel niet opruimt, maar er bovenop nog een laag rommel aan toevoegt. Sneller, en met meer zelfvertrouwen, maar niet beter.

Goede communicatie in je model was altijd al verstandig. In het AI-tijdperk wordt het een voorsprong.

Als dit allemaal zo logisch is, waarom gaat het dan in de praktijk zo vaak mis?

Deels omdat niet iedereen het belang ervan ziet. Ik zou willen dat ik kon zeggen dat elke ontwikkelaar dit snapt, maar dat is gewoon niet zo. Er zijn er een hoop die het niet doorhebben, of die het simpelweg niet interesseert. Voor hen is een model af als het werkt, en wat een ander er later mee moet, dat is dan een zorg voor later.

En zelfs waar mensen het wél snappen, gaat het mis, want consistentie is een afspraak tussen mensen, en afspraken slijten. Er komt tijdsdruk, en je wijkt een keertje af. Er komt een nieuwe collega die het anders gewend was. Er komt een tool die zijn eigen conventies meebrengt. Stuk voor stuk kleine, begrijpelijke dingen. En elk apart is het geen ramp. Maar consistentie is nou juist iets waarbij het gemiddelde niet telt. Een model dat voor negentig procent consistent is, voelt voor de lezer niet als negentig procent betrouwbaar. Het voelt als 100% ONbetrouwbaar, want hij weet nooit of hij nu in de betrouwbare negentig procent zit of in de rommelige tien. Dus controleert hij toch alles maar weer. En dan ben je het hele voordeel kwijt.

Afwijken van afspraken is trouwens op zich niet erg. Soms is er een goede reden om het ergens ánders te doen. Maar dan gelden er twee voorwaarden. De afwijking is onderbouwd, je weet waaróm. En de afwijking is opgeschreven. Een beredeneerde, vastgelegde uitzondering is gewoon onderdeel van het verhaal, daar communiceer je over. Een stille uitzondering, waar de volgende lezer op struikelt zonder dat er gewaarschuwd is, dat is een valkuil. Alleen moet je wel zorgen dat het bij uitzonderingen blijft.

De meeste inconsistentie ontstaat niet uit onwil, maar uit niet-weten. Wie op zijn eerste dag de afspraken van het huis uitgelegd krijgt, communiceert vanaf dag één in dezelfde taal als de rest.

En daarom is mijn belangrijkste advies niet technisch, maar menselijk. Maak consistentie iets waar je het als team over hebt. Leg je conventies vast op één vindbare plek. Bespreek afwijkingen, onderbouw ze, schrijf ze op. En spreek elkaar erop aan, zoals je elkaar ook aanspreekt op een vergeten afspraak. Dat is geen controle. Dat is samenwerken aan dezelfde boodschap.

We komen aan het einde.

Ik begon deel één met een uitspraak die misschien een beetje gek klonk: modelleren is communiceren. Ik hoop dat hij nu minder gek klinkt. Want alles wat we besproken hebben, de naamgeving, de datatypes, de structuur, de betekenis van een woord, de leesbaarheid van je queries, je laadproces, je documentatie, dat is allemaal hetzelfde ding. Dit ben jij, die iets probeert over te brengen aan iemand anders.

En die iemand anders, dat is de collega die na je komt, de ontwikkelaar die je nooit zult ontmoeten, en jijzelf over een half jaar. Voor hen bouw je. En als je écht vaart wil maken met AI: dat consistente model gaat je helpen.

En begrijp me goed, dat doe je niet om aardig te zijn. Dit is geen kwestie van netjes je spullen opruimen omdat dat zo hoort. Een goed gecommuniceerd model levert je iets op, en niet zo’n beetje ook. Een collega die na een dag aan de slag is in plaats van na drie weken. Cijfers die elkaar niet tegenspreken, en die dus vertrouwd worden. Een team dat op elkaars werk durft voort te bouwen zonder alles dubbel te checken. En een voorsprong op het moment dat je AI op je data wilt loslaten. Dat is geen vriendelijkheid. Dat is gewoon beter werk, dat zich terugbetaalt.

Dus als ik dit hele verhaal, beide delen, in één zin moet samenvatten: consistentie is niet alleen maar “netjes werken”, het is de investering die zichzelf terugverdient, elke keer dat iemand na jou met je werk verder moet.

Want onthoud: een goed antwoord begint altijd met een betere vraag.

Bedankt voor het luisteren. Vond je deze aflevering iets om over door te denken? Deel hem dan met iemand die ook aan datamodellen bouwt, of er juist mee moet werken. En wil je weten hoe wij bij InfoReports bouwen? Kijk dan op inforeports.nl. Tot de volgende keer.