Er was eens… een tijd wanneer je een monoliet kon aanwijzen.
Hij had een herkenbare vorm:
- Een repository waar niemand aan durfde te raken
- Een databankschema dat laag voor laag was gegroeid doorheen de jaren, zonder dat iemand de lagen had bedacht
- Een implementatieproces dat vroeg om een rustige vrijdagavond, een stevige dosis moed en een rollback-plan afgedrukt op papier
- …
Sinds we zijn overgestapt op microservices en cloudplatformen (onder andere), was het verhaal eenvoudig: we hadden de monoliet nu definitief in stukken gebroken, met kleinere services, duidelijkere grenzen, onafhankelijke deployments, losse koppelingen…
In veel opzichten hebben we ook effectief vooruitgang geboekt. Systemen zijn meer modulair geworden en de leveringssnelheid is toegenomen. Sommige vormen van complexiteit zijn inderdaad verminderd. Tenminste op codeniveau. Maar er gebeurde nog iets anders, meer geleidelijk. Software was niet langer een systeem in de enge zin. Het is een ecosysteem-van-systemen geworden.
Niet één codebase, maar tientallen. Niet één databank, maar meerdere dataopslagplaatsen, datastromen, gedeelde data lakes. Niet één implementatie-pijplijn, maar een platform dat honderden daarvan coördineert. Niet slechts beperkt tot de primaire processen waarvoor het systeem is gebouwd, maar ook voor vele secundaire processen – die dashboards, inzichten en rapporten voeden. Voeg daarbij nog identiteitsproviders, SaaS-componenten, beveiligingstools, compliance-controles, observability stacks, SDK’s van leveranciers, cloud-native services…
Lokaal en individueel bekeken, lijkt het niet op een monoliet. Maar collectief gedraagt het systeem zich als een verbeterde versie van een monoliet.
In de architectuurdiagrammen valt het niet op. Vakjes zijn vakjes, lijnen zijn lijnen, niets is wazig en niets is vaag. Wel valt het op in discussies over verandering: hetzij opzettelijk omdat een bepaald onderdeel functioneel moet evolueren, hetzij per ongeluk omdat de geweldige technologische beslissing van gisteren de nachtmerrie van vandaag is. Een ogenschijnlijk kleine wijziging in een data-contract, die plots afstemming tussen drie teams vereist. Een upgrade van een gedeelde platformcomponent, die regressietests activeert in het halve landschap. Een wijziging in een eenvoudige cloud-configuratie die impact heeft op diensten die voorheen nooit rechtstreeks met elkaar communiceerden. Een veiligheidsvereiste die zich door lagen van abstracties verspreidt en ervoor zorgt dat de mooie vierkante architecturale vakjes en lijnen eruitzien als een kleutertekening.
Niemand ziet, begrijpt, beheert of bezit nog het ‘geheel’. Toch is dit ‘onzichtbare geheel’ een beperkende factor voor iedereen.
Koppelingen zijn niet verdwenen. Ze zijn gemigreerd en verplaatst van interne codeafhankelijkheden naar afhankelijkheden tussen diensten, platforms en leveranciers. Wat vroeger methode-calls waren, zijn nu API-contracten geworden. Wat vroeger in het collectief geheugen zat, is gedegradeerd tot gedeelde individuele assumpties.
In de oude monoliet stapelde de complexiteit zich op binnen de toepassing en binnen de ‘box’. Tegenwoordig hoopt deze zich op in de relaties tussen componenten. In een spinnenweb dat bestaat uit spinnenwebben.
We spreken over autonome teams. We ontwerpen afgebakende contexten. We meten het aantal services en de implementatiefrequentie. Allemaal nuttige indicatoren. Maar autonomie draait niet om het aantal repository’s. Het draait om het vermogen om zonder hindernissen te evolueren.
Wanneer betekenisvolle verandering nog steeds vraagt om choreografie en onderhandelingen over organisatorische grenzen heen, hebben we de monoliet niet geëlimineerd. We hebben hem gedistribueerd en hij leeft nu op het ecosysteemniveau.
Dit is geen pleidooi tegen decompositie, losse koppelingen of gedistribueerde systemen. Al deze zaken blijven noodzakelijk en zijn volkomen waardevolle benaderingen. Maar het verschuift de last van technische complexiteit, naar systemische complexiteit en verandert lokale duidelijkheid in globale onderlinge afhankelijkheid. Ik denk dat niemand echt klaar stond om dat te beheren.
De architecturale vraagstukken veranderen daarom in:
- Waar eist verandering dat meerdere teams op één lijn zitten?
- Waar dwingen gemeenschappelijke definities tot afstemming tussen de teams?
- Waar beperken gemeenschappelijke datastructuren onafhankelijke evoluties?
- Waar gaan we ervan uit dat iedereen met hetzelfde woord ook hetzelfde bedoelt?
- Waar verandert een “standaard” in een afhankelijkheid?
- Waar worden platform- of serviceteams de poortwachters van de vooruitgang?
- Waar nemen keuzes op het vlak van cloud, technologie, ontwerp of leveranciers in alle stilte elke mogelijkheid voor een terugkeer weg?
- Waar zorgt een lokale verbetering voor globale neveneffecten?
- Waar gaat de foutherstel-modus voorbij de grenzen van de organisatie?
Wanneer uw antwoord op deze vragen iets anders is dan ‘nooit’, dan is het waarschijnlijk tijd om dit verder te onderzoeken en u daarbij af te vragen, ‘waarom’?
We hebben de zichtbare monoliet misschien doen verdwijnen. Maar het spinnenweb dat ervoor in de plaats is gekomen, verdient minstens evenveel aandacht.
Dit is een ingezonden bijdrage van Dirk Deridder, CTO bij Smals. Het werd geschreven in eigen naam en neemt geen standpunt in namens Smals. Ben je geïnteresseerd om bij te dragen aan projecten en diensten met een positieve impact op de samenleving? Raadpleeg dan ons uitgebreide jobaanbod en ontdek hoe jij het verschil kunt maken.