Sources onder audit regime/H1>
Het is heel normaal dat een accountant de boeken
controleert.  Dit om fraude, risico's en andere
zaken zoveel mogelijk voor te zijn in het belang
van iedereen.  We zijn daaraan gewend en handelen
daar ook naar.

Eigenlijk is het ridicuul dat source code over
het algemeen niet onder een dergelijk audit
regime staat.  Neem de stemcomputer.  Is
stemfraude mogelijk?  Gaan stemmen verloren?
Komen ze foutief door?  Allemaal zaken die je
echt wilt weten, maar actiegroepen moeten de
politiek daar aan de haren bijtrekken.

Of neem de sources van banken en verzekeraars.
Is er fraude van binnenuit?  Een aardig voorbeeld
daarvan was een programmeur die elke maand geld
over liet maken naar de giroloterij.  Omdat
die laatste uit oogpunt van de privacy geen
mededelingen doet over haar rekeninghouders
kon je gratis gokken op kosten van de zaak.

Of het halve Griekse parlement dat werd
afgesluisterd via de telefooncentrale die op
ingenieuze wijze was aangepast door onbekenden.
Klassieke controle- en audittechnieken laten
hier verstek gaan, en er is over het algemeen
niets voor in de plaats geregeld.

Naast deze klassieke voorbeelden maak ik in de
praktijk ook heel andere gevolgen mee van gebrek
aan een audit regime op bedrijfskritische
sources.  In feite realiseren Raden van Bestuur
en Raden van Commissarisen zich totaal niet
dat dat hun levensaders in source code zijn
uitgedrukt.  Zonder enige reden te hebben om
aan de eigen boekhouders te twijfelen is het
toch de normaalste zaak van de wereld dat er
een onafhankelijke controle van de boeken
plaatsvindt.  Zo niet bij sources.  Maar ook
die moet je regelmatig controleren, en ook dat
zou de gewoonste zaak van de wereld moeten
zijn.

Wat voorbeelden.  Programmeren leidt in het
beste geval tot legacy.  De vraag is of je dat
proces niet haarscherp in de gaten moet houden.
Het gaat immers om de continuiteit van de
business.  Als je ineens met legacy geconfronteerd
wordt, is het probleem je vaak al boven het hoofd
gegroeid.  Dat kun je voor wezen met audits.
En daar kun je dan naar handelen.

Bij outsourcing kun je het meemaken dat er een
vendor-lock ingebouwd wordt zonder dat je daar
erg in hebt.  Op die manier kom je niet of
nauwelijks meer van ze af wat een zeer ongezonde
financiele en technische afhankelijkheid
betekent.  Ware het niet beter om dit bij eerste
optreden gespot te hebben en tijdig maatregelen
genomen te hebben?  "Do the audit!"

Knip-en-plakwerk van programmeurs door frequente
wijzigingen die onder hoge druk, ja ook van de
bestuurders, zijn doorgevoerd waarbij alle
software engineering discipline uit het oog is
verloren levert korte termijn soelaas maar op
de lange termijn drama's op.  Zou je de code
niet op gezette tijden moeten doorlichten zodat
je niet ineens voor uiterst pijnlijke voldongen
feiten gesteld wordt waardoor de tent gesloten
kan worden omdat de investeringen die nodig
zijn niet gepleegd kunnen worden?

Of goed bedoelende maar op cruciale punten
incompetente programmeurs, testers, ontwerpers,
en architecten die dag-in dag-uit aan de
bedrijfskritische systemen sleutelen.  In
softwareland is er schijnbaar een blind vertrouwen
dat degenen die eraan werken het ook wel zullen
weten.  Maar waarom eigenlijk?  We zien toch
continu problemen met IT-investeringen en
operationele risico's die zich materializeren?

Dat vertrouwen moet je verdienen, middels een
audit regime.  Het ene na het andere bizarre
algoritme vliegt je om de oren zodra je in dat
soort code gaat speuren.  Een voorbeeld:  in
een-en-hetzelfde systeem tref je zomaar een
dozijn verschillende algoritmes aan voor dezelfde
functionaliteit waarvan tevens een aantal foutief.
Of functionaliteit worden zo stompzinnig
uitgeprogrammeerd dat het complete performance
bottlenecks blijken.  Of men is de programmeertaal
niet machtig en gebruikt verkeerde constructies
om functionaliteit uit te programmeren die met
kennis van zaken simpel en elegant valt op te
lossen.

Vroeger hield ik zelf een stupidorium bij waarin
een bloemlezing van code listings waarvan de
haren je te bergen rezen.  Tegenwoordig is er
thedailywtf.com waar mensen codefragmenten
plaatsen waar de honden geen brood van lusten.
Ondanks dit stukje zelfreigigend vermogen, is
het belangrijk om de source code, en het
voortbrenginsproces onder een audit regime te
plaatsen.

De praktijk is momenteel dat bestuurders geen
idee hebben dat dit deel uitmaakt van goed
IT-bestuur.  Substantiele veranderingen vallen
of staan bij inzicht in de totale boedel, die
inventariseer je middels een audit.  Algehele
vernieuwing moet je echt afwegen ten opzichte
van de huidige situatie, die je dan dus moet
Rontgenen.  Maar ook gewoon een status rapport
over de kwaliteit brengt issues aan het licht
die tot venijnige problemen kunnen uitgroeien;
tenzij je tijdig maatregelen neemt.  Of controle
op outsourcing: doet men geen vreemde dingen,
en zijn de rekeningen die ze sturen ergens op
gebaseerd?

Bestuurders hebben baat bij de juiste bit-to-board
aggregaten zodat er geen code-lijken in de kast
blijven zitten.  Als de basis van de belangrijkste
productiemiddelen namelijk kreupel is, gaat de
hele organisatie vanzelf struikelen en niemand
die begrijpt waarom.  Totdat je de beerput die
source code heet opentrekt.

X

Meer weten over de wondere wereld van ICT
in Jip en Janneke taal? Ga dan naar de
knipselkrant van Chris Verhoef

Prof. dr Chris Verhoef is hoogleraar informatica
aan de Vrije Universiteit in Amsterdam en
wetenschappelijk adviseur voor overheid en
bedrijfsleven.  Hij schrijft regelmatig een
column in AG II.  Hij is te bereiken via email:
x@cs.vu.nl.  Deze tekst is copyright SDU.  Niets
van deze uitgave mag zonder schriftelijke
toestemming van de uitgever worden overgenomen of
worden gepubliceerd.