Architectuur is geen doel: durf ook nee te zeggen

In bijna iedere organisatie komt er vroeg of laat een moment waarop een nieuwe architectuurstijl wordt aangedragen als oplossing voor bestaande problemen. De overstap naar microservices, event-driven architecturen of serverless platformen wordt dan gepresenteerd als de volgende logische stap. Vaak met de beste bedoelingen. Soms ook omdat andere organisaties ermee lijken te slagen.

Maar voordat je de eerste architectuurdiagrammen gaat tekenen, is er een belangrijkere vraag die gesteld moet worden:

Welk probleem proberen we eigenlijk op te lossen?

Dat klinkt misschien vanzelfsprekend, maar in de praktijk blijkt dat verrassend vaak niet het startpunt van de discussie te zijn.

Wanneer techniek het zicht belemmert

Architectuurkeuzes worden regelmatig besproken alsof het puur technische beslissingen zijn. Alsof de keuze voor een architectuurstijl vergelijkbaar is met het kiezen van een programmeertaal of database.

In werkelijkheid raken architectuurbeslissingen veel meer dan alleen technologie. Ze bepalen hoe teams samenwerken, waar verantwoordelijkheden liggen en hoe wijzigingen door een organisatie bewegen. Juist daarom ontstaat er vaak teleurstelling wanneer een nieuwe architectuur niet de verwachte resultaten oplevert.

Niet omdat de technologie slecht is. Maar omdat het echte probleem ergens anders zat.

Organisaties die worstelen met lange doorlooptijden, trage besluitvorming of hoge onderhoudslasten ontdekken vaak dat de oorzaak niet in hun softwarearchitectuur ligt. Veel vaker gaat het om onduidelijk eigenaarschap, teams die afhankelijk zijn van elkaar voor iedere wijziging of domeinen die nooit echt scherp zijn afgebakend.

Een nieuwe architectuur lost dergelijke vraagstukken niet automatisch op.

Complexiteit verdwijnt niet

Een van de grootste misverstanden rondom moderne architectuurstijlen is dat ze complexiteit zouden verminderen. Dat doen ze meestal niet. Ze verplaatsen die complexiteit.

Een monoliet kent bijvoorbeeld uitdagingen rondom schaalbaarheid en onafhankelijke deployments. Een microservice-landschap lost daar mogelijk een deel van op, maar introduceert tegelijkertijd nieuwe vraagstukken rondom observability, netwerkcommunicatie, security, monitoring, versionering en eventual consistency.

De totale hoeveelheid complexiteit wordt daardoor niet per definitie kleiner.

De vorm verandert.

Dat is geen probleem zolang die nieuwe vorm van complexiteit beter aansluit bij de uitdagingen die je organisatie heeft. Maar wanneer een architectuur wordt ingevoerd zonder duidelijk probleem dat ermee opgelost wordt, ruil je bekende problemen vaak in voor onbekende problemen.

Dat is zelden vooruitgang.

Architectuur volgt organisatie

Een andere reden waarom architectuurtransities mislukken, is dat organisaties onderschatten hoe nauw softwarestructuren verbonden zijn met teamstructuren.

Je kunt technisch gezien een systeem opsplitsen in twintig microservices, maar als iedere wijziging nog steeds langs dezelfde architect, dezelfde product owner of hetzelfde centrale team moet, dan ontstaat er weinig echte autonomie.

Het systeem ziet er misschien modern uit, maar de organisatie werkt nog steeds hetzelfde.

Daarom is het verstandig om architectuur niet los te zien van organisatorische vraagstukken. Wie is eigenaar van een domein? Welke beslissingen mag een team zelfstandig nemen? Waar zitten de afhankelijkheden tussen teams? En zijn die afhankelijkheden technisch of organisatorisch van aard?

Vaak levert het beantwoorden van die vragen meer op dan het tekenen van een nieuw architectuurplaatje.

De kracht van een besliskader

De meest succesvolle architectuurkeuzes die ik in de praktijk zie, beginnen vrijwel nooit met een oplossing. Ze beginnen met criteria.

Welke kwaliteitseigenschappen zijn belangrijk? Is snelle time-to-market cruciaal? Verwachten we sterke groei? Hebben we meerdere autonome teams? Zijn compliancy-eisen een bepalende factor? Welke operationele kennis is aanwezig binnen de organisatie?

Wanneer die vragen beantwoord zijn, ontstaat er een kader waarbinnen keuzes gemaakt kunnen worden. En soms leidt dat tot microservices. Soms tot event-driven architectuur. En soms juist tot de conclusie dat een goed opgebouwde modulaire monoliet voorlopig de meest verstandige keuze is.

Die laatste conclusie wordt opvallend vaak onderschat. Niet omdat ze technisch minder interessant is, maar omdat ze minder spectaculair klinkt.

Waarom nee zeggen soms de beste architectuurbeslissing is

Architectuur heeft voor een deel ook iets van discipline. Nieuwe technologieën zijn interessant. Nieuwe patronen kunnen veel voordelen bieden. Maar niet iedere trend is relevant voor iedere organisatie. En niet ieder technisch probleem vraagt om een fundamenteel andere architectuur. Juist daarom is het vermogen om “nee” te zeggen zo belangrijk.

Nee tegen een complex platform dat nog niet nodig is. Nee tegen een architectuurstijl waarvan de nadelen groter zijn dan de voordelen. Nee tegen het kopiëren van keuzes die bij grote techbedrijven werken, maar niet aansluiten bij jouw schaal, teams of uitdagingen.

Dat is niet conservatief. Dat is professioneel architectuurwerk.

Tot slot

Architectuur is geen doel op zichzelf. Het is een middel om organisatiedoelen te ondersteunen en software beter beheersbaar te maken. Wie zich uitsluitend richt op technologie loopt het risico symptomen te bestrijden in plaats van oorzaken.

Daarom is de belangrijkste architectuurvraag vaak niet: “Welke architectuur moeten we kiezen?”

Maar:

“Welk probleem proberen we eigenlijk op te lossen?”

Pas wanneer dat antwoord helder is, wordt duidelijk of een nieuwe architectuur werkelijk nodig is. En soms blijkt de beste architectuurbeslissing verrassend eenvoudig te zijn: niets veranderen.