Softwarearchitectuut-tuut-tuut

Wat opvalt is dat alles wat onder het label software
architectuur valt het goed doet in het bedrijfsleven,
terwijl onderhoud minder in de belangstelling staat.
Een voorbeeld:  bij internationale conferenties over
onderhoud en beheer die in Nederland neerstrijken moet
je de Nederlandse deelnemers uit het bedrijfsleven met
een vergrootglas zoeken, terwijl het grootste probleem
bij het houden van een internationale software architectuur
conferentie in Nederland was dat we niet genoeg rugzakjes
van de sponsor hadden om aan iedereen uit te delen.

Onderhoud en beheer is een onderwerp waar iedereen aan
doet en niemand over praat.  Eigenlijk het omgekeerde
van het weer:  daar praat iedereen over, maar vrijwel
niemand doet er aan.  Software architectuur is net als
het weer:  daar praat iedereen over, maar slechts weinigen
doen er werkelijk aan.  Het begint al met wat software
architectuur behelst.  Weet u het?

Overal is een website over, dus ook over de definitie
van software architectuur.  Daarin kun je een bonte
verzameling vinden van dit illustere begrip.  Als je door
die lijst heen bent kun je alleen nog maar denken:
software architectuut-tuut-tuut.  Er zijn vele definities,
de ene nog langer en uitgebreider dan de andere.  En er
zijn kennelijk hele volksstammen die achter dit begrip
aanlopen zonder te beseffen wat het betekent.  Maar wat
is nu eigenlijk software architectuur?  Een korte definitie
is als volgt:  software architectuur is dat gedeelte van
de software dat je het moeilijkste kunt veranderen.  Met
andere woorden, de software architectuur legt de blauwdruk
voor de veranderbaarheid van het systeem.  Hoe beter er
is nagedacht over de veranderbaarheid, hoe langer het
systeem up-to-date gehouden kan worden, en hoe beter
functionele aanpassingen uitvoerbaar zijn, en blijven.
De software architectuur is er ten behoeve van een zo
effectief en efficient mogelijk operationeel bestaan.

Net als bij civiele architectuur kan een muur architectureel
relevant zijn, maar het kan ook een scheidingsmuurtje
zijn dat je wel of niet kunt plaatsen al naar gelang de
mogelijk veranderende behoefte om kameroppervlak uit te
ruilen tegen kameraantal.  Als je daarentegen een dragende
muur hebt bedacht op een plek waar je kamers voor ruimte
wilt ruilen, loop je tegen de architecturele grenzen van
het gebouw aan, en lukt het je maar heel mondjesmaat om
die verandering door te voeren.  Uiteraard is het de taak
van de architect te achterhalen of het wel of niet relevant
is of kan worden om ruimte voor aantallen kamers te kunnen
uitruilen.

Dit soort trade-offs heb je ook met software.  De software
architectuur legt in feite vast welke zaken er flexibel
moeten blijven, en welke zaken niet hoeven te veranderen.
Daarbij hebben we de voor de hand liggende zaken zoals
de programeertalen, het operating system, de opdeling in
componenten, standaarden, etc.  Maar er zijn ook minder
in het oog springende zaken.  Vergelijk het maar eens
met asbest.  Toen niemand nog wist dat eternietplaten zo
gevaarlijk waren, werd dit asbesthoudende materiaal
veelvuldig gebruikt.  Maar nu kunnen we gebouwen maar
heel lastig aanpassen als we plekken raken waar asbest
in zit.

Er bestaat ook zoiets als software asbest.  Een voorbeeld:
in een systeem is het BTW tarief hard uitgecodeerd.
Overal waar het BTW tarief nodig is, staat het getalletje
hard vermeld.  Tsja, als je het dan moet veranderen, dan
zul je dat overal moeten doen.  En wanneer ben je klaar?
Zit het nog ergens verborgen in een of andere database
entry?  Een gebed zonder end.  Het BTW tarief heeft dan
de karakteristieken van een dragende software muur
gekregen.  Als je daarentegen het BTW tarief overal
symbolisch had weergegeven en op maar 1 plek een harde
waarde had gegeven, dan was het BTW tarief meer als
scheidingswandje geimplementeerd.  Dan kun je zonder
problemen het tarief aanpassen, de zaak opnieuw compileren,
en klaar is Kees.

Nu blijkt het verdomd lastig om software flexibel te
krijgen waarvan we (soms achteraf) vinden dat het dat
ook hadden moeten wezen; inclusif zaken als hardgecodeerde
BTW tarieven.  Deels ligt dat aan de gebruikte programeertalen,
maar deels ligt het ook aan een gebrek aan kennis van de
software architect met betrekking tot onderhoud en beheer.
Kennis over software asbest doe je vooral op als je je
als software architect gaat verdiepen in de zegeningen
die je software architectuur heeft voortgebracht in de
operationele fase.  Dan kun je grote hoeveelheden onbedoelde
maar wel geimplementeerde software asbest aantreffen, en
de kunst is nu om dat zoveel mogelijk voor te zijn.  Nu
is de realiteit dat onderhoudsprogrammeurs om software
asbest heen moeten programmeren, en in sommige gevallen
zelfs aan asbestverwijdering moeten doen.  Daarom is het
thema van de volgende conferentie over onderhoud die naar
Nederland komt ook:  de software architectuur van bestaande
systemen.  U bent van harte uitgenodigd.

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.  Hij schrijft      
maandelijks een column in AG II.  Deze tekst is 
copyright SDU.  Niets van deze uitgave mag zonder
schriftelijke toestemming van de uitgever worden
overgenomen of worden gepubliceerd.