Rene Veldwijk

Dr René Veldwijk (1961) studeerde economie aan de VU Amsterdam met als specialisaties administratieve organisatie en informatica. Na zijn afstuderen ontwikkelde hij zich bij het softwarehuis van Raet als allround engineer en consultant en als specialist op het gebied van gegevensmodellering en ontwerp van flexibele systemen, een onderwerp waarop hij in 1993 promoveerde. Na een periode als manager R&D bij Raet richtte hij in 1996 FAA Partners op dat zich richt op de ontwikkeling en implementatie van flexibele administratieve systemen met eigen concepten. In Database Magazine publiceert hij sinds 1992 artikelen en columns over zowel techische onderwerpen als over de merkwaardige gedachten en toestanden in de ICT wereld.

Twaalf jaar terug werkte ik voor een organisatie die de uitkeringen verzorgde voor ambtenaren. Mijn opdracht was om software te bedenken waarmee gegevens gecontroleerd zouden worden gemigreerd van legacy systemen naar de nieuwe systemen. Het paradepaardje was een nieuw uitkeringssysteem dat werd gebouwd door een groot softwarehuis waarvan ik de naam hier niet zal noemen. De opdracht werd extra interessant toen bleek dat het nieuwe uitkeringssysteem slechts één tijdsdimensie ondersteunde en het oude systeem twee. In dit oude systeem kon worden vastgelegd hoe hoog iemands uitkering in een bepaalde maand was, maar ook wanneer dat gegeven was geregistreerd. Alle tabellen hadden in hun primaire sleutel zowel de maand van uitkering als het precieze tijdstip van vastlegging. Het resultaat is een uiterst complex systeem, maar het ding kon wel mutaties met terugwerkende kracht aan. De nieuwe machine kon dat dus niet en gegevens die met terugwerkende kracht waren gewijzigd konden daarom niet worden ondergebracht in het nieuwe systeem. Evenmin konden gegevens met terugwerkende kracht worden gewijzigd. Afijn, ik meldde het probleem, iedereen schrok en het project werd direct gestaakt. Een voor die tijd indrukwekkend bedrag van 17 miljoen gulden werd afgeschreven. Het softwarehuis kreeg een dagvaarding. En ik kon ook iets anders gaan doen, uiteraard zonder dat er een bedankje afkon. Wijze mensen houden hun mond in gevallen als deze.

Deze ervaring inspireerde me om in DB/M te beschrijven hoe je het verschijnsel tijd in een database moet verwerken en in 1997/1998 is er in DB/M dan ook een zestal samenhangende artikelen over dit onderwerp gepubliceerd. Samen met een extra artikel over het implementeren van tijdaspecten en twee artikelen over tijd van Steve Cannan werd dit pakket uitgegeven in een boekje dat werkelijk in no time was uitverkocht. En toen werd het stil. Voor Array, de uitgever van DB/M, is het publiceren van boekjes geen kernactiviteit en ook ik verdien mijn brood er niet mee. Toch werd Tijd in de Database net als het eerdere boekje Tien Geboden voor Goed Database Ontwerp onder database adepten een hit. Vrijwel zeker heeft dit ook te maken met het feit dat database ontwerp een vrijwel vergeten wetenschap is. Naast wat theorievorming over database ontwerp voor speciale doeleinden is het doodstil geworden in Nederland en daarbuiten. En ondertussen worstelt iedereen nog steeds met dezelfde database ontwerpproblemen van 15 jaar en nog langer geleden.

Tien jaren gingen voorbij en ik maakte geen carrière. Dat wil zeggen, ik bleef met mijn collega’s systemen ontwerpen en over ICT adviseren. Soms kwam ik het boekje tegen bij klanten. Zo was er een verzekeraar bij wie nieuwe medewerkers het ding verplicht moesten lezen om begrip te krijgen voor de grote complexiteit van hun systemen. Dat was leuk en vleiend. Soms ook gebruikten wijzelf het boekje om klanten en prospects uit valkuilen te houden. Zo kabbelde het allemaal voort – tot vorig jaar. Sindsdien lopen we opeens op tegen het ene na het andere geval aan van tijdgerelateerde ellende in systemen en projecten. ICT-dienstverleners zijn bezig om hun kennis over het omgaan met tijdaspecten kwijt te raken. Het lijkt haast op technologische achteruitgang. Dat kan ook best kloppen als je bedenkt dat ICT-opleidingen al een aantal jaren vrijwel niets meer doen aan databases en database-ontwerp. Professionals moeten net als twintig jaar geleden weer van de straat leren hoe ze een database moeten ontwerpen. En wat de problematiek van tijdaspecten betreft: je kunt buiten de wetenschappelijke wereld lang zoeken voordat je over dit onderwerp informatie vindt.

Het mooiste symbool: twaalf jaar na het flopproject waarmee ik deze column begon doet de opvolger van het softwarehuis weer een project voor de opvolger van de verzekeraar. En u raadt het al: wéér een flop want wéér een systeem dat niet kan omgaan met mutaties met terugwerkende kracht. Closure, zo noemen ze dat met een mooie Engelse term.

Maar het verhaal gaat verder. Deze maand begint in Database Magazine een artikelserie over de Polisadministratie, een nieuwe Nederlandse basisadministratie die vol zit met de meest nare tijdproblemen die de markt te bieden heeft. En als alles is gelukt dan treft u op de website van dit blad ook nog het uitverkochte Tijd in de Database boekje in elektronische vorm aan. Om het nog mooier te maken heeft de redactie ook ervoor gezorgd dat de eerdere Tien Geboden artikelserie ter beschikking is gesteld.

Het zou geweldig zijn als er in dit blad weer zoals vanouds aandacht zou worden besteed aan hardcore database ontwerp. Samen met mijn collega’s ga ik dit jaar aan de slag om alle interessante database-aspecten te bespreken van een in veel opzichten extreem systeem. Met dank aan de DB/M redactie kunt u die artikelen afzetten tegen eerdere schrijfsels die wat mij betreft nog even actueel zijn als toen ze werden geschreven. Ik hoop dat u het geheel zowel boeiend als nuttig zult vinden.