Architectuurdoelen staan niet op zichzelf, maar volgen uit businessdoelen. In de praktijk is dat verband vaak helemaal niet duidelijk en wordt ook niet als zodanig herkend. Integendeel, architectuur krijgt maar al te vaak een eigen status, met eigen regels en wetten, die de wensen van de business danig in de weg kunnen zitten. Het is daarom belangrijk om steeds opnieuw te bedenken waarom architectuur nodig is en waarmee zij zich moet bezighouden. Het architectuurproces zal zich vooral moeten richten op het wegnemen van belemmeringen voor onderhoud.
Schattingen van de kosten van onderhoud lopen uiteen van 60 procent tot zelfs meer dan 90 procent van de totale kosten van een software systeem (inclusief bouw). Dat betekent dat de kosten van systeemonderhoud twee keer tot bijna tien keer zoveel zijn, vergeleken met de bouwkosten.
Het is dus verstandig om de aandacht te richten op het onderhoud, want hoe langer een systeem bestaat of zou moeten bestaan, des te belangrijker is aandacht voor de onderhoudsfase.
.
Architectuur als essentie
Architectuur is de essentie van een systeem en biedt het meeste weerstand bij veranderingen. Dit vind je ook terug bij gebouwarchitectuur. Laten we eens een vergelijking maken tussen gebouwarchitectuur en ict-architectuur:
Als we de artistieke kant buiten beschouwing laten, bepaalt gebouwarchitectuur onder meer materialen, (basis-)constructies en fundering van een gebouw. Kortom, alles wat nodig is om een gebouw neer te zetten dat geruime tijd zal blijven bestaan. Gebouwarchitectuur is gericht op de constructie, het behoud, toekomstvastheid, stevigheid. Het is vrijwel onmogelijk om een goed gebouw te bouwen zonder architectuur.
Dit ligt heel anders bij ict-architectuur. Het is best mogelijk om een systeem te bouwen zonder architectuur te bedrijven. Meestal gaat dat nog snel ook: snel even iets in elkaar knutselen, bijvoorbeeld een prototype(!). Alle gewenste eigenschappen van dat moment zijn aanwezig, maar… o wee als er nieuwe wensen moeten worden gerealiseerd.
Architectuur en onderhoud
Ook wat betreft onderhoud zijn er grote verschillen tussen gebouwen en ict. Onderhoud aan een gebouw bestaat uit het wegnemen of herstellen van slijtage. Een simpel schuurtje (weinig architectuur) is prima te onderhouden. De betekenis van onderhoud van ict is heel anders, zelfs enigszins misleidend: het gaat hier niet over het herstellen van slijtage, immers, software bestaande uit bits en bytes is nu eenmaal niet onderhevig aan slijtage. Het gaat wel over kleine of grotere wijzigingen van de software in kwestie. En het aanbrengen van deze wijzigingen is veel moeilijker bij een systeem dat gebouwd is zonder een fatsoenlijke architectuur. Ict-architectuur heeft veel meer te maken met onderhoud en veel minder met constructie: een toekomst-vast systeem is een systeem dat kan mee-veranderen met de toekomst.
Businesswaarde van architectuur
Een systeem met een goede architectuur is gemakkelijker aan te passen. Daarnaast zijn de kosten van onderhoud (=aanpassing) veel hoger dan die van bouw. De businesswaarde van architectuur is nu direct duidelijk: het minimaliseren van onderhoudskosten!
Een goed architectuurproces moet zich dus richten op een systeemontwerp dat het minste weerstand biedt tegen toekomstig verwachte veranderingen. Dit kun je zelfs nog ruimer zien:
Een goed architectuurproces moet zich richten op alles wat weerstandsdrempels tijdens onderhoud kan voorkomen! En onder alles valt het systeemontwerp, infrastructuur, documentatie en niet te vergeten het voortbrengingsproces zelf.
Hoe kunnen we dit in praktijk brengen?
Wat haalbaar zou moeten zijn is een evenredigheid tussen business- en Iictverandering: hoe groter de verandering van businessproces, des te groter is de te verwachten verandering van de ict die dit proces ondersteunt. En omgekeerd: voor een kleine businessverandering zou ook slechts een kleine ict-wijziging nodig moeten zijn.
Grofweg kunnen twee situaties worden onderscheiden. Ten eerste zijn toekomstige ontwikkelingen nauwelijks voorspelbaar (veel risico's). Het is dan verstandig om een architectuur neer te zetten die klaar is voor diverse scenario's: (zeer) gemakkelijk configureerbare systemen die met een handomdraai klaar zijn voor (bijna) elke nieuwe situatie. Dat is misschien wel duur, maar de (meeste) risico's zijn gedekt. In de tweede situatie zijn toekomstige ontwikkelingen wel goed voorspelbaar (weinig risico's). Dan is het een goed idee om de toekomstige wereld mee te nemen in de requirements van vandaag. Dit kan riskant zijn: mogelijk worden er dingen bedacht die helemaal niet relevant blijken te zijn in de werkelijke toekomst.
Voorbeelden
Hoe omgaan met hergebruik van componenten? We moeten ons de vraag stellen: wat gaat ons het meeste dwars zitten bij een verandering: het feit dat er deelsystemen afhankelijk zijn van de hergebruikte component of het feit dat min of meer dezelfde functionaliteit in verschillende systemen is geïmplementeerd?
Waar verwachten we de meeste verandering: In de (deel-)systemen waar veel andere (deel )systemen van afhankelijk zijn? Dan moeten we ten minste zorgen voor heldere en onveranderlijke interfaces, ofwel een duidelijk interface contract.
Hoe uitgebreid en gedetailleerd moet systeemdocumentatie zijn?
Opnieuw de vraag: wat kost het minste moeite bij een verandering? Het uitzoeken van de precieze details van een systeem, waarbij direct de softwareverandering kan worden bewerkstelligd, of:
het controleren in hoeverre de gedetailleerde systeembeschrijving in overeenstemming is met het systeem zelf, het bijhouden van de gedetailleerde beschrijving van dat systeem samen met de daadwerkelijke softwareverandering? De balans kan bij het ene systeem doorslaan naar meer en betere documentatie en bij het andere systeem naar nauwelijks documentatie, hoogstens een overzicht.
Dit soort vragen moeten niet eenmalig gesteld worden, maar telkens opnieuw bij elk systeem ter ondersteuning van beslissingen voor nieuwe (business) wijzigingen.
Architectuur hoeft zich niet te richten op het ontwerpen van een keurig systeem dat aan alle gangbare architectuurprincipes voldoet. Het is veel gemakkelijker om beslissingen te toetsen aan vragen als: welke problemen gaat dit opleveren als er iets verandert? Welke drempels ga ik opwerpen voor onderhoud? Aangezien de meeste kosten van een systeem in onderhoud zitten, zal een architectuurproces het meeste businesswaarde opleveren als het zich voornamelijk bezighoudt met het voorkomen en wegnemen van drempels voor verwachte toekomstige veranderingen.
Theo, Ik ben het helemaal eens met je stelling. Hoe krijgen we nu de opdrachtgevers ook zo ver dat ze dit gaan inzien en niet bij de ontwikkeling van de eerste versie voor een dubbeltje op de eerste rang willen zitten?
“Het is vrijwel onmogelijk om een goed gebouw te bouwen zonder architectuur. Dit ligt heel anders bij ict-architectuur.” Misschien, hoewel ik dat niet meteen zou onderschrijven. Toepassingen ontwikkelen zònder architectuur levert echter programma’s op als gebouwen met het (ICT) ontwerp van een schuurtje . . .
Misschien aardig om de “architectuur graal” (of zoeken daarnaar) eens uit het oogpunt van het te ondersteunen (primaire) proces te bekijken?
@Alexander: Dit artikel was mijn eerste stap 🙂
@Dick: Natuurlijk moeten we architectuur (of beter: ICT in het algemeen) alleen uitvoeren ter ondersteuning van het primaire proces.
Mijn punt is dat je best een stuk software zonder architectuur kunt bouwen dat wel de ondersteuning voor dat primaire proces biedt, maar dat je al vrij snel in de problemen gaat komen als de software moet worden aangepast (software met het ontwerp van een schuurtje!). Als het project groot genoeg is, ga je dat moment al tijdens het project meemaken.