Falen in slow motion
Bedrijfskritische systemen gaan zelden echt dood. Ze verstarren.
Elk kwartaal wordt het iets duurder om eraan te komen. Releases veranderen van routine in ritueel, en daarna in risico. Aan de randen verschijnen workarounds: hier een spreadsheet, daar een handmatige stap, een schaduwproces dat niemand durft te documenteren. En dan komt het stille kantelpunt: de organisatie gaat zich aanpassen aan het systeem, in plaats van dat het systeem zich aanpast aan de organisatie.
De onderzoekers van Ink & Switch beschrijven dit treffend in hun essay over malleable software. Moderne software werd ons beloofd als klei, iets wat we naar believen konden hervormen, maar kwam uiteindelijk als een apparaat: gesloten, af, gebouwd op afstand. Als het gereedschap niet meer past, is het de workflow die moet buigen.
En hier zit het ongemakkelijke deel: dit gebeurt niet alleen met kant-en-klare producten. Ook je eigen maatwerksysteem, het bedrijfskritische systeem dat juist speciaal voor jouw organisatie is gebouwd, kan veranderen in precies zo'n apparaat. Niet omdat iemand daar bewust voor kiest, maar omdat niemand bewust voor iets anders kiest. Ondertussen raakt de oorspronkelijke ontwerpintentie langzaam uit beeld, totdat niemand meer durft te veranderen wat niemand nog volledig begrijpt.
En een bedrijfskritisch systeem dat niet meer kan veranderen, heeft eigenlijk al gefaald, ook al draait het nog steeds. De gevolgen zijn alleen nog niet op de balans verschenen.
Future-proof is geen voorspelling
Toekomstvast wordt vaak verkeerd begrepen als een gok op de toekomst: kies het juiste platform, de juiste leverancier, het juiste paradigma, en je zit veilig. Maar niemand voorspelt de toekomst goed. Regelgeving verandert. Bedrijven fuseren. Markten keren om. AI verandert de economie van software in real time. Kies je disruptor, of een ander kiest hem voor jou.
Toekomstvast betekent iets bescheidener en tegelijkertijd veel waardevollers: het moet goedkoop zijn om het mis te hebben.
Amazon gebruikt hiervoor het begrip two-way door: een beslissing waar je doorheen kunt lopen en ook weer op terug kunt komen. Een toekomstvast systeem is niet een systeem dat op alles heeft geanticipeerd. Het is een systeem waarin de meeste beslissingen uiteindelijk two-way doors blijken te zijn, waarbij een verkeerde keuze je een sprint kost, geen complete herschrijving, en waarin je alleen voor de paar deuren die maar één kant op openen de tijd neemt voor een zorgvuldige afweging.
Daar is architectuur daadwerkelijk voor bedoeld. Niet voor diagrammen, niet voor governance-theater, maar voor het veranderen van one-way doors in two-way doors en het vlak houden van de kosten van verandering over de tijd.
Expliciete contracten tussen componenten, zodat teams kunnen bewegen zonder elkaar te verrassen. Scheidslijnen op de plekken waar verandering het meest waarschijnlijk is, zodat een nieuwe requirement morgen in één module terechtkomt in plaats van in twaalf. Events als duurzaam vastgelegd bewijs van wat er is gebeurd, zodat nieuwe consumers kunnen aansluiten zonder opnieuw over het verleden te hoeven onderhandelen. Versioning als strategie, niet als excuus achteraf. Onderdelen die je kunt vervangen zonder een harttransplantatie.
Niets hiervan is gratis. Scheidslijnen, contracten en discipline rondom versioning kosten je op dag één allemaal iets. Dat is de premie van de verzekering, en je ontdekt pas wat die polis waard was op de dag dat de toekomst het niet met je eens is.
Stewart Brand merkte ooit op dat de gebouwen waar mensen van gaan houden, gebouwen zijn die zich aanpassen aan hun bewoners, gebouwen die leren. Hetzelfde geldt voor systemen. De systemen waar een organisatie van gaat houden, zijn nooit de perfecte systemen. Het zijn de systemen die bleven leren.
"Een toekomstvast systeem is niet een systeem dat nooit verandert. Het is een systeem dat nooit heeft geleerd om bang te zijn voor verandering."
AI verhoogt de inzet
Er gaat een verleidelijke gedachte rond: met AI-ondersteunde softwareontwikkeling, wie heeft er dan nog architectuur nodig? We genereren ons er gewoon uit.
Fred Brooks legde decennia geleden al uit waarom dat niet werkt. Het moeilijke deel van software was nooit het schrijven van de code. Dat noemde hij accidental complexity. Het moeilijke deel is het bedenken van het ontwerp: de essential complexity. AI verlaagt de kosten van het eerste en raakt het tweede nauwelijks.
Ink & Switch gebruiken voor hetzelfde punt een treffend beeld: AI inzetten voor softwareontwikkeling binnen een gesloten ecosysteem is alsof je een briljante chef-kok naar een foodcourt brengt. Het enige wat iedereen kan doen, is iets van het menu bestellen.
In een rigide architectuur neemt AI de beperking niet weg. Het produceert sneller meer rigiditeit.
Maar draai het om: in een goed gearchitectureerd systeem wordt AI een echte force multiplier. De architectuur bepaalt of al die nieuwe snelheid zich opstapelt en steeds meer waarde oplevert, of uiteindelijk instort onder zijn eigen gewicht.
Architectuur is in het tijdperk van AI dus niet minder belangrijk geworden. Het is het verschil geworden tussen versnelling en opstopping.
Hoe wij bouwen
Bij Infodation bouwen we al meer dan vijftien jaar aan bedrijfskritische systemen. We hebben gebouwd in telecom, energie en logistiek. Lang genoeg om de verstarde systemen van anderen te hebben geërfd, en lang genoeg om te weten hoe we onze eigen systemen flexibel houden.
Daarom zetten we architectuur vóór code. Contracten vóór integraties. We oefenen migraties totdat ze saai worden. We doen niet aan big bang. We bouwen niet voor eenmalig gebruik. We bouwen systemen die kunnen leren.
Als je systeem inmiddels begint voor te schrijven hoe je organisatie moet werken, in plaats van andersom, dan is dat geen onderhoudsprobleem.
Dat is een architectuurgesprek dat de moeite waard is.
