Architectuur: middel of kwaal?

3 augustus 2010

Vanaf het eerste gebruik van de term bestaan er uiteenlopende definities van ‘softwarearchitectuur’. Een interessante omschrijving komt van Martin Fowler, auteur van vele toonaangevende boeken en artikelen op ons vakgebied, en ook een van de opstellers van het Agile Manifesto in 2001. Hij stelt: ‘Architecture is the stuff that’s hard to change later.’ En in één adem voegt hij eraan toe dat je van dat spul beter zo weinig mogelijk kunt hebben.

Klaarblijkelijk wordt architectuur dus gezien als een sta-in-de-weg voor aanpasbaarheid van softwaresystemen. Als agile architect heb ik adaptiviteit hoog in het vaandel staan. Dat neemt echter niet weg dat ik mijn wenkbrauwen even optrok bij het lezen van Fowlers benadering van architectuur. Terecht wijst hij op de nadelen van rigide software, die in de eindfase van ontwikkeling nauwelijks nog is te veranderen. Inderdaad kan in zo’n situatie vaak met de vinger naar de toegepaste architectuur worden gewezen. Maar om dan de architectuurinspanning te decimeren met het argument dat je daarmee aan flexibiliteit wint, is onzin en zet de klok weer vele jaren terug.

Een goede architectuur is onmisbaar als je een complex, software-intensief systeem wilt bouwen. Punt. Voorwaarde is wel dat de architectuur voorziet in een zekere adaptiviteit, door middel van weloverwogen constructies die latere aanpassing van het systeem mogelijk maken. De vraag is alleen: met welk doel en in welke subsystemen ga je doelbewust veranderbaarheid ondersteunen? Want flexibiliteit als een algemene, niet nader gespecificeerde eis voor een softwaresysteem zet de deur wagenwijd open voor ineffectiviteit of zelfs onbeheersbaarheid in zowel proces als product. Het antwoord vraagt derhalve om een strategische benadering.

Tijdens de laatste bijeenkomst van de System Architecture Study Group van het Embedded Systems Institute hield Kees Schuerman, systeemarchitect bij Tomtom, zijn architectenpubliek voor dat je hiertoe het mature domein zal moeten scheiden van het innovatieve domein. Het mature domein is gebaseerd op bestaande hardware, dwingende standaarden of andere OEM-eisen, en in die context is aanpasbaarheid meestal onnodig, en dus verspilling. Het innovatieve domein is daarentegen nog grotendeels onontgonnen terrein, en vraagt dus om adaptiviteit. En in een beetje complexe omgeving krijg je dat niet voor elkaar zonder de juiste maatregelen in de architectuur. Dit is de essentie van wat ik zelf een agile architectuur noem.

Op implementatieniveau vertaalt deze vraagstelling zich naar de mate van onderlinge samenhang van softwaremodules. Een hoog niveau van afhankelijkheid komt adaptiviteit meestal niet ten goede. Daarnaast speelt ook de flexibiliteit van de interfaces een rol, aangeduid met weak en strong typing. Typing heeft te maken met de restricties die de gebruikte programmeertaal oplegt aan de uitwisselbaarheid van data. Bij weak typing kunnen onder de motorkap datatypes worden geconverteerd, met als resultaat een bredere inzetbaarheid van de module.

Op zoek naar een hoog niveau van aanpasbaarheid zou je zeggen: bingo! Maar de inzet van weak typing ter bevordering van adaptiviteit en onafhankelijkheid van softwaremodules maakt deze ook kwetsbaarder. De interface van dergelijke modules kan verschillend worden geïnterpreteerd door ontwikkelaars die gezamenlijk aan een systeem werken. Bovendien kan het gedrag in een volgende versie van de software aanzienlijk zijn gewijzigd, bij gelijkblijvende signatuur van de interface. Conclusie: weak typing alleen toepassen in het innovatieve domein, onder toezicht en begeleiding van een architect.

Erik Philippus

Terug naar overzicht