Modelleren is communiceren; deel 1 van 2

We gaan het in deze aflevering over iets hebben wat door veel mensen als iets saais wordt beschouwd: modelleren.

Modelleren is het bouwen van een datamodel. Hoe de gegevens worden opgeslagen, oftewel: de tabellen, de velden, de structuur waarin je de gegevens van een organisatie vastlegt. Dat roept het beeld op van een ontwikkelaar achter een scherm, die in stilte een database in elkaar zet.

Maar in deze aflevering van de podcast zal ik laten zien dat modelleren eigenlijk communiceren is. Op het moment dat je een datamodel bouwt, ben je de hele tijd aan het communiceren. Met je collega’s. Met de mensen die later met dat model verder moeten. En, ook niet onbelangrijk, met jezelf over een half jaar.

Welkom bij Data met impact. De podcast over de zin en onzin van data, mensen en techniek. Ik ben Jeroen Buisman, en met InfoReports help ik organisaties in het maatschappelijk domein om grip te krijgen op hun informatie.

Bij het schrijven van het script bleek al snel dat het onderwerp te groot is voor één aflevering, tenminste, als ik vast wil houden aan de episodelengte van ongeveer 20 minuten. Ik heb het dus opgeknipt in twee afleveringen, die wel tegelijkertijd uitkomen. In dit eerste deel kijken we naar het modelleren zelf. In het tweede deel kijken we naar alles eromheen, en naar wat het je nou eigenlijk oplevert.

Deze aflevering wordt op sommige momenten wat technischer dan je tot nu toe in deze podcast van me gewend bent. Ik ga het hebben over velden, over datatypes, over naamgeving. Mocht je één van die mensen zijn die daarbij in slaap valt, of die normaal gesproken meteen afhaakt bij dit soort begrippen: blijf even hangen. Want ik beloof je dat het nergens over de techniek op zich gaat. Het gaat steeds over iets daarachter, iets wat voor iedereen herkenbaar is. Je hoeft geen ontwikkelaar te zijn om dit te kunnen volgen, en juist als je géén ontwikkelaar bent heeft het onderwerp een paar interessante inzichten.

Dus. Modelleren is communiceren. Let’s go!

Stel je voor: er komt een nieuwe collega bij een BI-team. Een goeie, ervaren ontwikkelaar. Ze krijgt toegang tot het datawarehouse, en gaat aan de slag.

En dan gebeurt er iets interessants. Want hoe snel die collega productief is, hangt eigenlijk niet af van hoe goed ze is. Het hangt af van het model waar ze in terechtkomt. Als we die ontwikkelaar in twee verschillende situaties, met twee verschillende datawarehouses, zouden neerzetten, krijgen we ook twee eindsituaties.

In het ene datawarehouse is ze na een dag aan het werk. Ze bekijkt de tabellen, ziet hoe alles heet, herkent het patroon, en kan voorspellen waar ze dingen zal vinden nog voordat ze gekeken heeft.

In het andere datawarehouse is ze na drie weken nog steeds aan het puzzelen. Waarom heet dit veld hier zus, en twee tabellen verderop zo? Betekent dit allebei hetzelfde, of net niet? Ze durft niks aan te nemen, is steeds heen en weer aan het zoeken, en de helft van de tijd weet de persoon die ze het vraagt het zelf ook niet meer.

Wat is hier aan de hand? Die nieuwe collega probeert iets te begrijpen. Ze probeert te begrijpen wat er bedoeld wordt met het model. En in het ene model wordt haar dat helder verteld. In het andere model moet er heel veel uitgezocht worden voordat duidelijk is hoe het werkt.

En daar heb je het. Dat model is een boodschap. De bouwers van dat model hebben geprobeerd iets duidelijk te maken, en die nieuwe collega is de ontvanger. In het ene geval is de boodschap aangekomen. In het andere geval is hij blijven steken.

Hou dat beeld even vast, want daar komen we steeds op terug. Een datamodel heeft een zender en een ontvanger. En net als bij elk gesprek kan wat je bedoelt wel of niet overkomen.

Laat ik even preciezer maken waarom ik dit communicatie noem, en niet bijvoorbeeld “netjes werken”.

Als je een datamodel bouwt, leg je niet alleen vast dát iets zo is. Je legt ook, of je het nu wilt of niet, een bedoeling vast. Je kiest een naam voor een veld, en in die naam zit jouw idee van wat erin hoort. Je kiest een structuur, en in die structuur zit jouw idee van hoe de werkelijkheid in elkaar zit. Iemand die later naar je model kijkt, leest die keuzes. En probeert daaruit op te maken wat jij bedoelde.

Dat is communicatie in de meest letterlijke zin. Er is een zender, dat ben jij op het moment van bouwen. Er is een boodschap, dat is het model. En er is een ontvanger, dat is iedereen die er later mee werkt. En zoals bij alle communicatie geldt: het is niet de zender die bepaalt of het gelukt is. Het is de ontvanger. Je kunt nog zo goed weten wat je bedoelde, als de ander het niet begrijpt, is de boodschap niet overgekomen.

Dat betekent dat een datamodel dat technisch helemaal klopt, alsnog zijn doel kan missen. De gegevens kunnen kloppen, de queries kunnen werken, de rapporten kunnen de juiste getallen geven, en toch kan het model niet doen wat het zou moeten doen. Namelijk: een ander helpen begrijpen wat er is vastgelegd, en waarom. Een model dat alleen de maker kan navertellen, doet zijn werk maar half.

Denk even terug aan die nieuwe collega die drie weken zat te puzzelen. Het model wérkte. De cijfers klopten. Het was alleen onleesbaar voor iemand anders. En dus deed het, als manier om iets over te brengen, niet wat het zou moeten doen.

Als modelleren communiceren is, dan is de eerstvolgende vraag: tegen wie heb je het eigenlijk?

Ik wil trouwens even precies zijn over tegen wie ik het in deze aflevering heb. Er zijn mensen voor wie modelleren echt een vak is. Die hebben dit allemaal allang door, voor hen is goede communicatie in een model een tweede natuur. Die hoef ik niets te vertellen.

Maar daar heb ik het niet over. Ik heb het over iets wat ik in de praktijk veel te vaak zie. Onduidelijkheden en inconsistentie in software en database-ontwerp. Een professionele ontwikkelaar die uitstekend kan programmeren, maar gewoon geen kaas heeft gegeten van goede modellering. Iemand die “even” iets aanbouwt op wat er al staat, zonder zich af te vragen of het past bij de rest. En organisaties waar niemand toezicht houdt op hoe de losse ontwikkelaars het voor hun eigen stukje doen. Iedereen bouwt zijn eigen deel keurig consistent, intern klopt het, maar over het geheel is er geen samenhang. Eilandjes, elk logisch op zichzelf, die samen een doolhof vormen.

Dáár wil ik het over hebben. En voor die situaties helpt het om je af te vragen: voor wie leg ik dit eigenlijk vast?

Want het gaat bijna nooit mis omdat iemand alleen voor zichzelf bouwt. Het gaat mis omdat een ontwerper, simpel gezegd, niet verder kijkt dan zijn neus lang is. Omdat hij denkt: dit is toch duidelijk genoeg. Of: dat staat wel in de documentatie. Op het moment van bouwen zit het allemaal helder in zijn hoofd, en dan voelt het vanzelfsprekend. Maar dat hoofd is er straks niet meer bij. En de mensen die er wél bij zijn, hebben dat heldere beeld nooit gehad.

Voor wie doe je het dan wel? Voor de collega naast je, en voor de ontwikkelaar die er over een jaar bij komt en die jij misschien nooit ontmoet. Die moeten jouw werk kunnen oppakken, aanpassen, uitbreiden, zonder dat jij ernaast zit om het uit te leggen. En je doet het voor jezelf, over een half jaar. Als je allang vergeten bent waarom je iets zo gebouwd hebt. Ik durf wel te zeggen dat ik mijn eigen werk van een jaar geleden soms lees als dat van een vreemde. En dan ben ik blij, heel blij, als die vreemde duidelijk heeft opgeschreven wat hij bedoelde.

En nu wordt het wat technischer.

Laten we beginnen bij de buitenste laag van een model, het eerste wat een ander ziet: de naamgeving. Hoe heten je tabellen en je velden? Een veld, voor wie dat woord niet dagelijks gebruikt, is gewoon een kolom in een tabel. Eén soort gegeven, bijvoorbeeld een geboortedatum, of een patiëntnummer.

En naamgeving is precies waar de eerste communicatie plaatsvindt. Want de naam van een veld is het eerste, en vaak het enige, wat vertelt wat erin zit.

En een goede naam bedenken is soms het moeilijkste deel van het hele ontwerp. Het kan de meeste tijd kosten. Je zit te zoeken naar het ene woord dat precies, of in ieder geval: goed genoeg, dekt wat erin zit, niet te breed en niet te krap. En het belang ervan is groot, want die naam is wat alle anderen na jou gaan lezen, en wat aangeeft wat de bedoeling is van die tabel, van dat veld.

En namen kunnen de lezer op het verkeerde been zetten. Bijvoorbeeld omdat ze te vaag zijn, en of juist te precies.

Te vaag, dat is een veld dat gewoon bedrag heet. Bedrag. Ja, dank je. Bedrag waarvan? Afhankelijk van de context kan dat van alles betekenen. De naam klopt, er staat echt een bedrag in, maar hij vertelt je net niet genoeg om er zonder nadenken op te kunnen vertrouwen. Of een veld dat datum heet, terwijl er drie verschillende datums in het spel zijn: de datum van aanvraag, de datum van behandeling, de datum van facturering. Welke is dit? Dat staat er niet, dus dat moet je maar net weten, of uitzoeken. Helemaal leuk wordt het als je een tabel hebt met drie datums, waarbij er één behandeldatum heet, de volgende factuurdatum, en de derde gewoon “datum”. De preciesheid van de twee andere velden, tegenover de vaagheid van de laatste.

En dan het omgekeerde: namen die te precies zijn. Dat klinkt gek, want preciezer is toch beter? Niet altijd. Stel je noemt een veld, ik noem maar wat, bedrag_inclusief_21_procent_btw. Heel duidelijk, op dit moment. Tot het btw-tarief verandert, of tot er ook regels in komen met een ander tarief. Dan staat er een naam die een belofte doet die niet meer klopt, en dat is bijna erger dan een vage naam, want hij liegt met grote stelligheid. Een naam die te strak op één situatie is vastgepind, breekt zodra de situatie verandert.

De kunst zit dus in het midden. Een naam die genoeg zegt om geen vragen op te roepen, maar niet zo specifiek is dat hij zichzelf de das omdoet zodra de wereld verandert. En ja, dat is moeilijk. Dat is precies waarom je er soms een half uur op zit te broeden.

Goede naamgeving is dus eigenlijk hetzelfde als je aan je woord houden, en je woorden zo kiezen dat de ander ze niet verkeerd kán begrijpen. En merk je wat hier gebeurt? We hebben het over veldnamen, maar eigenlijk hebben we het over betrouwbaar en helder zijn in wat je zegt. Dit is communicatie. Het komt eigenlijk neer op: “Zeggen wat je bedoelt, en bedoelen wat je zegt”.

Een laag dieper zit iets subtielers: het datatype.

Elk veld in een database heeft een type, dat zegt wat voor soort waarde erin mag. Een getal, een stuk tekst, een datum. Klinkt als een technisch detail, maar het is eigenlijk opnieuw een belofte aan de lezer. En hier kun je net zo goed onduidelijk zijn als bij een naam.

Neem het verschil tussen een datum en een datum-met-tijd, in vaktaal date en datetime. Die lijken op elkaar, maar ze zijn niet hetzelfde. Als ik een veld “datum” noem, maar er staat eigenlijk een datum mét tijd in, dan klopt de naam niet helemaal met de inhoud. En iemand die ermee rekent, krijgt net andere uitkomsten dan hij verwacht. En dat is dan omdat het woord en de werkelijkheid niet goed op elkaar aansluiten.

Of een tijd in een tekstveld (kom ik ook vaak tegen). Een getal-waarde in een tekstveld. Iets wat alleen maar een geheel getal kan zijn, in een veld dat decimalen ondersteunt. En zo kan ik nog wel even doorgaan. Elke keer komt het er op neer dat het type van het veld niet afgestemd is op de inhoud ervan, en dat werkt fouten in de hand. Want als je een veld “Aantal” noemt, en het het type tekst laat zijn, dan is de kans groot dat er een keer iets in komt te staan wat géén getal is; en ik kan je zeggen, dat is niet leuk voor berekeningen.

Het gaat ook over namen die nét te onnauwkeurig zijn. Noem je een veld “datum”, of “moment”? Want dat zijn twee verschillende dingen. Een moment is een punt in de tijd, een datum is een hele dag. En het voorbeeld wat toch een beetje mijn stokpaardje is: het verschil tussen “tot” en “tot en met”. Loopt een periode tot de eerste van de maand, of tot en met de eerste? Dat scheelt een dag. En over die ene dag zijn al ontelbare rapporten de mist in gegaan, omdat de een “tot” bedoelde en de ander het las als “tot en met”.

Die onduidelijkheid is alsof je een op zich correct woord net verkeerd in een zin gebruikt: grammaticaal klopt het, maar de ander begrijpt iets anders dan je bedoelt.

Daarnaast zijn er de grotere structuurkeuzes. Neem iets simpels: het adres van een patiënt. Wat doe je als dat verandert, als iemand verhuist? In het ene deel van je model kun je ervoor kiezen om de hele geschiedenis te bewaren: je ziet dan netjes dat iemand eerst hier woonde en daarna daar. In een ander deel kun je ervoor kiezen om het oude adres simpelweg te overschrijven: dan zie je alleen waar iemand nu woont, en is het verleden weg.

Allebei kan prima, het hangt ervan af wat je nodig hebt. Maar stel dat je in het ene deel van je model van adressen de historie bewaart (bijvoorbeeld van patiënten), en in het andere deel overschrijft (bijvoorbeeld van huisartsen), zonder dat dat ergens duidelijk is. Dan komt er iemand die een berekening maakt over hoe mensen door de tijd verhuisd zijn, en dat relateert aan de huisarts op dat moment. Hij krijgt een antwoord. Het ziet er compleet uit. Maar het klopt niet, want ineens zien we hele rare combinaties van huisadres van de patiënt, en waar de huisarts zit.

Dat is het probleem met een inconsistente structuur. Je vertelt je lezer twee verschillende verhalen over hoe je model in elkaar zit, en hij moet elke keer opnieuw uitvogelen welk verhaal hier geldt. En als hij het verkeerd gokt, merkt hij dat vaak niet eens.

Een consistente structuur is als een tekst met een vaste opbouw. Je weet waar je de dingen kunt vinden, omdat ze altijd op dezelfde plek staan, en op dezelfde manier zijn opgeschreven. Een inconsistente structuur dwingt je om elk hoofdstuk opnieuw te leren lezen.

En dan de binnenste laag. De betekenis. Wat bedoelen we eigenlijk met de woorden die we gebruiken, en doen we dat overal op dezelfde manier?

Ik geef weer het voorbeeld dat ik vaker gebruik, omdat het zo lekker herkenbaar is: het woord opname. In een ziekenhuis lijkt dat een volstrekt helder begrip. Iedereen weet toch wat een opname is? Maar vraag het aan drie mensen, en je krijgt drie net iets andere antwoorden. De een denkt: een opname, dat is een patiënt die blijft slapen, minstens één nacht. De ander zegt: nee, ook iemand die ‘s ochtends komt en ‘s avonds weer naar huis gaat is opgenomen geweest. En een derde denkt: als dezelfde patiënt binnen een week terugkomt, is dat dan een nieuwe opname, of nog steeds dezelfde? Allemaal redelijk. Niemand heeft ongelijk. Maar het zijn wel drie verschillende verwachtingen bij hetzelfde woord.

En zolang die verwachting onuitgesproken blijft, gaat iedereen er gewoon mee aan de slag, in de veronderstelling dat de rest hetzelfde bedoelt. De een bouwt zijn deel van het model met de ene opvatting van opname, de ander met een andere. Niemand zegt het hardop, want het voelt zo vanzelfsprekend dat het overbodig lijkt om het te benoemen.

Stel, in een model komt op meerdere plekken een veld voor dat opnamenummer heet. Mooi, denk je, overal dezelfde naam, dat is consistent. Maar dan blijkt: op de ene plek is het echt gevuld met het opnamenummer. Op de volgende plek staat er eigenlijk het casenummer in (whatever that is). En weer ergens anders staat er de identificatie van een periode binnen de opname. Drie keer hetzelfde woord. Drie totaal verschillende betekenissen.

Dat is veel verraderlijker dan drie verschillende namen voor hetzelfde. Want de naam belóóft je iets, en die belofte wordt gebroken zonder dat je het ziet. Je leest “opnamenummer”, je gaat ervan uit dat dat overal hetzelfde betekent. Een veldnaam is namelijk een contract. Een belofte, een afspraak. Hier staat dit, en niet iets anders. En aan dat contract moet je je houden, anders is het geen afspraak meer maar een valstrik.

En of je nou kiest voor opnamenummer of bijvoorbeeld voor opname_id, dat maakt voor die belofte niet uit. Je mag kiezen wat je wilt. Als je maar kiest, je eraan houdt, en datzelfde woord overal hetzelfde laat betekenen.

En dan, veel later, komt het naar boven. Het ene rapport telt twaalfhonderd opnames. Het andere telt er dertienhonderdvijftig. En allebei hebben ze gelijk, ieder binnen zijn eigen opvatting. Maar de gebruiker die beide rapporten op zijn bureau krijgt, ziet twee verschillende waarheden, en vertrouwt daarna geen van tweeën meer.

Let op wat hier de oorzaak is. Het is niet dat er ergens fout gerekend is. Die verschillende getallen zijn het symptoom. De échte oorzaak ligt een laag dieper: er is nooit afgesproken wat opname betekent. En dat is een belangrijk inzicht, want het betekent dat een woord als opname geen vaststaand ding is dat ergens in de werkelijkheid ligt te wachten tot je het opraapt. Het is een afspraak. Een keuze die je met elkaar maakt. Maak je die keuze niet expliciet, dan maakt iedereen ‘m stilletjes voor zichzelf, net even anders, en niemand die het doorheeft.

Dat is de diepste vorm van miscommunicatie. Niet een veld met een onduidelijke naam, niet een rommelige structuur, maar een woord waarvan iedereen denkt dat de betekenis vanzelf spreekt, terwijl die in werkelijkheid nooit is vastgelegd. En juist omdat iedereen denkt dat ze het over hetzelfde hebben, controleert niemand het. De aanname van gedeelde betekenis is precies wat de controle in de weg staat.

Hoe waarborg je dat dan? Niet, en dit is belangrijk, met een technische truc. Je kunt niet automatisch laten controleren of de inhoud van een veld wel klopt met de bedoeling, want de bedoeling staat nergens in het systeem. Die zit in de hoofden van mensen. Waarborgen begint dus bij het expliciet maken van wat impliciet was. Spreek af wat opname betekent, schrijf het op, op één vindbare plek, en zorg dat er iemand eigenaar van is, iemand die het bewaakt en bij wie je terecht kunt als je twijfelt. En leg die definitie vervolgens op één plek vast in je model, zodat alle rapporten dezelfde bron gebruiken in plaats van dat iedereen zijn eigen variant bouwt.

Dat is meer werk dan even snel een berekening maken. Maar het is precies het werk dat ervoor zorgt dat je over een woord niet meer hoeft te discussiëren, omdat je het één keer goed hebt afgesproken. En iedereen die daarna rekent, rekent hetzelfde, omdat ze hetzelfde bedoelen.

Dit was het eerste deel. We hebben gezien dat een datamodel een boodschap is, met een zender en een ontvanger. En we zijn de drie lagen langsgegaan waarin die boodschap vorm krijgt: de naamgeving, waar je je aan je woord houdt. De structuur, waar je één verhaal vertelt over hoe je model in elkaar zit. En de betekenis, waar je expliciet afspreekt wat een woord eigenlijk inhoudt, in plaats van iedereen zijn eigen verwachting te laten invullen.

Maar daarmee zijn we er nog niet. Want het model zelf is niet het enige wat je achterlaat. Er is ook de taal eromheen: je queries, je code, je documentatie. En dan is er de vraag die er onder dit alles ligt: wat levert het je nou eigenlijk op, al die zorgvuldigheid? En wat heeft het met AI te maken? Daarover gaat deel twee.

Onthoud in elk geval dit: een goed antwoord begint altijd met een betere vraag.

Tot in deel twee.