De jaar 2000-kans

Pieter Wisse

Extra kosten voor een eventueel langere levensduur verdienen erkenning als verzekeringspremie.

Ik wil natuurlijk niemand nodeloos nerveus maken, maar heeft u al stilgestaan bij de jaar‑3000 problematiek? Vermoedelijk niet en laat ik daarom uw verbeelding even helpen. Veronderstel dat een programmeur voor de aanduiding van het millennium één bit benut. Daarmee is dat probleem van het jaar 2000 toch uit de wereld? En zo'n oplossing spaart geheugenruimte, nietwaar? Neem als eerste bitwaarde gewoon een '0' voor alle jaren van 1000 tot en met 1999. En een '1' voor de jaren erna tot en met 2999.

Inderdaad gaat dat opnieuw een hele tijd goed. Verder is dit uiteraard geen realistisch voorbeeld. Ik neem tenminste aan dat elk informatiesysteem, dat de overgang naar 1 januari 2000 overleeft, netjes vier 'volle' cijfers per complete jaaraanduiding telt. Maar is zelfs dàt geen uitstel? Duikt een vergelijkbaar probleem niet op wanneer het jaar 10.000 nadert?

Opzettelijk doe ik narrig over de kostbare tragikomedie die de titel '2000' draagt. Omdat huilen niet helpt, kunnen u en ik er maar beter om lachen. Maar wat ik serieus bedoel, is dat in het algemeen extra aandacht nodig is voor de levenscyclus van artefacten voor informatievoorziening. Zo'n serieuze benadering moet dus veel verder gaan dan een simpele slogan. Wie kent niet de roep om toekomstvaste informatievoorziening? Dat is echter propaganda. Want zoiets als toekomstvastheid is helemaal geen lineair oplopende maat. Het is helemaal niet zo dat een langere levensduur per definitie groeiend voordeel biedt. Waarop het neerkomt, is een optimale levensduur in relatie tot het doel waarvoor het instrumentarium dient. Menig programmeur van voorbije generaties dacht dat zijn werk ongetwijfeld vóór het jaar 2000 vervangen zou zijn. Waar dat uitgekomen is, valt zo iemand niets te verwijten. Veel van hun programmatuur moet echter nog operationeel blijven; daarvoor kozen zij dus verkeerd.

Eigenlijk is het ronduit flauw om uitsluitend die oude programmeurs te beschuldigen. De belanglijkste verantwoordelijkheid ligt elders. Ik vind dat de opdrachtgever expliciet moet aangeven, hoelang een bepaalde component voor informatievoorziening meemoet. Als die opdrachtgever dat niet uit zichzelf meedeelt — en dat is waarschijnlijk — moet de ingeschakelde dienst‑ of produktverlener hem vriendelijk maar dwingend tot een uitspraak uitnodigen. Het èchte probleem, vermoed ik, is dat zo'n leverancier de complexe implicaties van levensduur waarschijnlijk evenmin overziet. Dat werkt desastreus uit, want de relevante tijdhorizon vormt een wezenlijk uitgangspunt. Profesionals behoren er hun ontwerp en het vervolgens daadwerkelijk ontwikkeld gereedschap in sterke mate op af te stemmen, waarbij programmeurs slechts de rij van betrokken 'leveranciers' sluiten.

Wie er zelfs maar kort over nadenkt, beseft dat de beoogde levenscyclus belangrijke gevolgen heeft voor kosten en doorlooptijd van realisatie. Ditmaal lijkt me een rechtevenredig verband overigens wel redelijk. Dat wil zeggen, naarmate voor een component een langer leven gedacht is, groeien kosten en tijd die met realisatie gemoeid zijn. Dat gebeurt onder meer omdat beheervoorzieningen langer geldig moeten blijven. En de kans op grotere variëteit van gebruikers neemt toe, met hogere eisen aan bediening van dien. Voorts is er stellig een verhouding tussen levensduur en voorzieningen voor beveiliging, enzovoort. Dergelijke aspecten mogen domweg niet verborgen blijven, totdat één of andere programmeur zich geconfronteerd ziet met onvolledige specificaties. Noodgedwongen kiest hij dan voor een oplossing, zoals hijzelf die optimaal acht. Gelet op zijn specifieke referentiekader is dat dus weleens de verkeerde in het licht van de overkoepelende bedrijfsvoering. Nogmaals, dat valt zo'n programmeur slechts ten dele te verwijten. Meer schuld draagt de functionaris onder wiens verantwoordelijkheid de programmering gebeurt.

Voor de duidelijkheid die een karikatuur verschaft, keer ik terug naar de aanstaande cijferwisseling. Stel dat een opdrachtgever, daartoe met gedegen advies aangezet, met zijn gezonde verstand koos voor een levenscyclus die vóór 1 januari 2000 eindigt. Neem verder aan dat om allerlei (nieuwe) redenen het ooit ontwikkelde informatiesysteem nu langer nodig blijkt. Is het dan wel reëel om van een probleem te spreken, indien (bijvoorbeeld) de jaaraanduiding ontoereikend is? Ik ben het daar niet mee eens. Blijkbaar loont het om de levenscyclus met extra inspanningen te verlengen. Mijn idee is dat er veeleer een renovatie aan de orde is. Ik herhaal dat de perceptie draait om de oorspronkelijke schatting van de cyclus. Wie eerlijk is tegenover zo'n eerdere beslissing, ziet dan wellicht de kans ipv het probleem. Dit neemt niet weg dat talloze kansen natuurlijk al in de opzet van componenten, systemen en dergelijke berekend moeten zijn. Wie stelselmatig de schatting van levensduur overdrijft, komt minder vaak voor verrassingen te staan. Dat lijkt extra geld te kosten. Mijn advies luidt om zulke investeringen als een verzekeringspremie te beschouwen.

Met een concreet voorbeeld sluit ik af. Als uw database, programmatuur enzovoort ook ná het jaar 10.000 moeten functioneren, raad ik aan om van meet af aan vijf cijfers voor het jaartal te nemen. Redeneer zonodig door tot ná 100.000 enzovoort.