20131117-210418.jpg
Deze week mag ik een cursus geven over software-architectuur. Dat is een tak van sport die vooral bij grote bedrijven wordt bedreven. Als een groot software-systeem (denk aan een website zoals Marktplaats, of internetbankieren) wordt ontwikkeld dan wordt er eerst een ontwerp gemaakt. Daarbij wordt nagedacht over wat het systeem moet doen, en over hoe dat systeem intern moet werken. Software-architectuur gaat een stap verder: dat gaat niet over hoe de software werkt, maar over hoe goed de software werkt. Het gaat niet over functionaliteit, maar over kwaliteit. Over snelheid, betrouwbaarheid en veiligheid, bijvoorbeeld. Dat is wat de gebruiker van de software ervaart. Maar het gaat ook over kwaliteiten die alleen het bedrijf zelf zal ervaren. Bijvoorbeeld: schaalbaarheid (hoe reageert het systeem op een plotselinge toename van het aantal gebruikers), flexibiliteit (hoe moeilijk is het om wijzigingen in het systeem aan te brengen), of onderhoudbaarheid (hoeveel moeite moet er worden gedaan om het systeem in de lucht te houden).

Het grappige is dat er grote overeenkomsten zijn met de architectuur die we allemaal kennen: die van gebouwen. Een paar jaar geleden vond ik in een mooie boekwinkel in Kopenhagen een boekje met de naam “101 Things I Learned In Architecture School” (Matthew Frederick). Wijze lessen van en voor architecten. Grappige tekeningen, met bondige verklaringen. Ik wil er hier een paar noemen, en laten zien hoe ze ook van toepassing zijn op software-architectuur.

Architects are late bloomers.
De meeste architecten zijn op hun best rond hun vijftigste. Er is ervaring nodig om een goeie architect te zijn. Dat geldt ook voor software-architecten. Ze zijn als jonkie begonnen als programmeur, en zijn als ze goed zijn daarna ontwerper geworden. En als ze heel goed zijn mogen ze architect worden. Je ziet het aan de cursisten: ouder, wijzer, soms zelfs in pak. Jawel, en dat voor een programmeur.

No design system is or should be perfect.
Imperfecties kunnen een gebouw verrijken, of menselijker maken. Uitzonderingen op de regel zijn soms beter dan de regel zelf. Bij software-architectuur geldt: maak het zo goed als economisch verantwoord is. Niet zo slecht dat je klanten weglopen, maar ook niet zo goed dat je het niet terugverdient. Soms is het voor een bedrijf goedkoper om zich te verzekeren tegen de schade van eventuele fouten, dan om die fouten bij voorbaat op te lossen. (Denk daar maar eens aan als je een probleem hebt met een website.)

Less is more.
Geen toelichting nodig. Overdaad schaadt. Ook in de software geldt: hou het eenvoudig. Hoe complexer, hoe meer kans op problemen. In (o.a.) de software-industrie noemen we dit principe: KISS (Keep It Simple, Stupid).

A proper building grows naturally, logically, and poetically out of all its conditions.
De beste software ontstaat iteratief. Er wordt een eerste versie gemaakt, met zo weinig mogelijk functionaliteit. Daardoor leer je wat je eigenlijk wilt, of wat er mooi bij zou aansluiten. Dan verander of maak je dat. Da’s de tweede iteratie. Waardoor je vervolgens weer op nieuwe ideeën wordt gebracht. De tijd dat we eerst heel lang gingen nadenken voor we de eerste letter op papier zetten is voorbij. Je denkt wel eerst na, maar op een gegeven moment begin je met bouwen. En daarbij moet je vooral blijven nadenken.

Tot slot mijn favoriet:
An architect knows something about everything. An engineer knows everything about one thing.
Dat sluit goed aan bij mijn eigen manier van denken. Liever in de breedte dan in de diepte. Ik weet niet alles, ik weet van alles een beetje. Nou ja, van bijna alles een beetje. Of is het toch: van een beetje een beetje? De evaluaties die de cursisten mogen geven aan het eind van de week zullen het me leren.

Advertenties