Architectuur: middel of kwaal?

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.