Wim Hendriksen was softwaremanager bij ASML en lector bij Fontys Hogeschool ICT. Nu beziet hij de ontwikkelingen vanachter de geraniums.

20 December 2018

De systemen die we de komende jaren gaan bouwen, zijn ordes groter en complexer dan we gewend zijn. Softwareontwikkelaars zijn ondertussen niet significant slimmer geworden. Alle hoop is gevestigd op het gezonde verstand van softwarearchitecten om de wereld een beetje overzichtelijk te houden. Hun vakgebied moet zich echter wel aanpassen aan de nieuwe realiteit; op dit moment is het nog niet goed genoeg, vindt Wim Hendriksen.

Als je aan een softwarearchitect vraagt om de architectuur van zijn systeem in een uurtje uit te leggen, dan krijgt hij dat niet voor elkaar. Waar ze in de bouwkunde een heel eind komen met kreten als ‘jugendstil’, ‘jaren dertig’, ‘postmodern’ of ‘Bossche School’, heb je in de software geen enkele classificatie. Waar iedereen het verschil weet tussen rock-’n-roll, blues en country, kan de softwarearchitect niet eens vertellen of een systeem een goede architectuur heeft of een slechte, en waarom dat zo is.

Er zijn geen woorden en er is geen grammatica om een softwarearchitectuur op abstract niveau te beschrijven. De getoonde plaatjes zijn meestal zo ongelofelijk complex met al die pijlen, blokken en kleuren dat geen mens er nog iets van begrijpt. Ook de plaatjesmaker zelf niet. Misschien kunnen we iets leren van andere vakgebieden zoals de bouwkunde en dat terugvertalen naar softwarearchitectuur.

Het Sydney Opera House is er precies uit komen te zien zoals Utzon het in een aantal simpele houtskoolstrepen op papier had gezet.

Utzon, Gaudí, Hundertwasser

De Deen Jørn Utzon deed in 1957 mee aan een prijsvraag voor de bouw van een nieuw operagebouw in Sydney. Waar de concurrenten dikke pakken papier inleverden, won Utzon de hoofdprijs met slechts één schets. Wat opvalt, is dat het gebouw er precies uit is komen te zien zoals hij het in een aantal simpele houtskoolstrepen op papier had gezet. Iedereen die betrokken was bij de bouw wist wat de bedoeling was.

Softwarearchitecten vervuilen een simpel model graag met allerlei onnodige details waardoor nieuwe bouwers juist niet meer kunnen zien wat de bedoeling was. Het Matlab-model dat je hebt na een week geeft de essentie van het systeem prima weer. Die essentie gaat vervolgens verloren omdat er steeds meer details bij komen. Tegen de tijd dat we executeerbare code kunnen genereren, is het model één grote warboel geworden waar een nieuweling nooit meer uitkomt. Die begint dus gewoon opnieuw. Conclusie: het gaat er niet om hoeveel je vastlegt, maar om de essentie die nodig is om het systeem minstens tien jaar te kunnen onderhouden.

Gaudí’s architectuurmodel voor de Sagrada Família is nog steeds te aanschouwen op de zolder van de Casa Milà.
Meer dan honderd jaar bouwen met vele generaties architecten en bouwvakkers heeft een verpletterend resultaat opgeleverd.

De Spanjaard Antoni Gaudí moest rond 1900 in Barcelona een kathedraal bouwen met heel slanke pilaren. Om zijdelingse krachten niet de kans te geven het gebouw uit elkaar te duwen, was het zaak om alle krachten precies door de palen te leiden. Daarvoor maakte hij een doeltreffend model van kettingen die ondersteboven aan een grondplaat hangen. Dit model is nog steeds te zien op de zolder van de Casa Milà.

Meer dan honderd jaar bouwen met vele generaties architecten en bouwvakkers heeft een verpletterend resultaat opgeleverd: de Sagrada Família. Er is weliswaar een immens verschil met het bewaarde model, maar de essentie staat fier overeind. Gaudí heeft niet geprobeerd om zijn architectuurmodel te verfijnen en daaruit het gebouw te genereren. Iedereen kon echter zien wat de bedoeling was en heeft zich daaraan gehouden.

Er is een immens verschil tussen model en gerealiseerd gebouw, maar de essentie staat fier overeind.

Softwarearchitecten zijn tegenwoordig druk in de weer met modelgedreven ontwikkeling, terwijl de softwarebouwvakkers gewoon nog coderen. Fout! Softwarearchitecten moeten architectuur bedrijven op het juiste abstractieniveau en er dan met hun tengels van afblijven. Software-engineers moeten die architectuur verfijnen en met mdd-tools software genereren en testen. Zolang tachtig procent van de ontwikkelaars deze tools niet kunnen gebruiken, is mdd nog niet productierijp.

Softwarearchitectuur wringt ook behoorlijk met Agile. Omdat pas in een heel laat stadium bekend is wat de software allemaal moet doen, loopt de architect het hele project minstens één sprint achter op de implementatie. De best haalbare architectuur ziet er dan uit als het Hundertwasserhaus in Wenen: een organisch gegroeid geheel met weinig samenhang. De Oostenrijkse kunstenaar en architect Friedensreich Hundertwasser maakte gebruik van voorhanden materialen en liet het gebouw stukje bij beetje ontstaan. Steeds kwam er weer een nieuw stukje bij, aan of op.

Softwarearchitecten zullen iets moeten verzinnen om voor te gaan lopen op de ontwikkelaars, want anders gaat het niet goed met de –abilities. Door hun architectuur op abstracter niveau te beschrijven, kunnen ze het systeem de baas blijven. Anders verdwijnen er zomaar dragende muren uit het softwaregebouw en stort de zaak in.

Met Agile ziet de best haalbare architectuur eruit als het Hundertwasserhaus in Wenen: een organisch gegroeid geheel met weinig samenhang.

Legacy

De meeste softwareprojecten leven langer dan de gemiddelde architect erbij betrokken blijft. De nieuwe architect zit met zijn handen in het haar; zijn voorgangers hebben hun dagen vooral pratend en niet schrijvend doorgebracht en bewogen lucht kun je een jaar later niet meer teruglezen. Het beetje dat er op papier staat, is te complex om te begrijpen. Dus begint de nieuwkomer helemaal opnieuw, waarbij hij zijn nieuwe architectuur weer mondeling uitdraagt aan de hand van een paar plaatjes met veel pijlen en blokjes.

Net als de vorige keren is het team helaas niet in staat om de al gemaakte software in zijn geheel om te bouwen naar de nieuwe architectuur. De stukken die niet voldoen, heten vanaf dat moment ‘legacy’. Met een mooie strik eromheen wordt deze code een no-goarea en iedereen prutst zijn nieuwe functionaliteitjes er aan de buitenkant tegenaan. Dat gebeurt niet op de meest elegante manier, maar op basis van het beperkte inzicht in de legacycode. Het architectuurmodel is daar niet tegen bestand, waardoor het project snel bergafwaarts gaat. Het is net of de nog te bouwen torens van de Sagrada Família niks te maken willen hebben met het kettingenmodel, en negeren wat er in de onderste veertig meter al is neergezet.

Er mogen wat minder orthogonale interfaces in zitten, maar als herkenbaar is wat de bedoeling was, weet een nieuwe architect in elk geval waar hij zich mee bezig gaat houden.

Een softwarearchitect dient zijn werk goed over te dragen en ervoor te zorgen dat zijn opvolger het bestaande architectuurmodel als uitgangspunt neemt. Er mogen wat minder orthogonale interfaces in zitten, maar als herkenbaar is wat de bedoeling was, mag hij trots zijn. Zijn opvolger weet dan in elk geval waar hij zich mee bezig gaat houden. Dat beperkt de hoeveelheid rework door een incompatibele nieuwe architectuur, waardoor code ook minder kans krijgt om legacy te worden.

Dit is echter niet alleen de verantwoordelijkheid van de architect; het hele team heeft de dure plicht om alle bestaande software en documentatie aan te passen aan de nieuwe architectuur. Dat hoeft niet meteen, maar moet wel gestructureerd. Ook software-engineers en managers die accepteren dat er legacycode ontstaat in hun systeem moeten zich diep schamen.

Edited by Nieke Roos