AI-softwarearchitectuur: hoe de rol van de softwarearchitect verandert
Er is een golf van applicatieherbouw en -vervanging gaande. Bij Eli5 bekijken we wekelijks artikelen over softwaremodernisering om echte waarde te vinden voor CTO's, PM's en PO's die te maken hebben met de modernisering van legacysoftware. Deze week bespraken we een stuk van een engineer bij Sony Sports, die stelt dat AI herschrijft waar softwarearchitectuur voor dient. De stelling is scherp en verdient het serieus genomen te worden: architectuur coördineerde vroeger mensen, en nu moet ze machines coördineren die sneller code schrijven dan wie dan ook kan reviewen. We zijn het eens met waar de auteur uitkomt. We zijn het oneens met een deel van de weg ernaartoe, en juist in dat meningsverschil zit het nuttige deel voor iedereen die echte systemen draaiende houdt.
Bron. Engineer bij Sony Sports, schrijvend op Medium.
Samenvatting
Het artikel stelt dat architectuur oorspronkelijk is ontstaan om menselijke inspanning te coördineren. Mensen zijn traag en duur, dus architectuur legde guardrails om wat zij bouwden en hield grote teams consistent. AI neemt een groot deel van de kosten van het schrijven van code weg, waardoor architectuur volgens de auteur ophoudt een blauwdruk voor constructie te zijn en een regulator van verandering wordt. In zijn woorden gaat architectuur van dictator naar regulator, en verschuiven engineers van bouwen naar beheersen. De conclusie is dat architectuur en de architect relevanter worden in een AI-gedreven wereld, niet minder.
Review en inzichten
We waren het eens met de bestemming van de auteur en zetten vraagtekens bij zijn kaart. Dit zijn de thema's die naar voren kwamen.
Het woord "architectuur" moet te veel werk verzetten. Het artikel schaart het schema, de regels, de richtlijnen en de implementatieconventies allemaal onder één label. Wij zien dat als verschillende dingen. Architectuur is het schema: de componenten, waar elk van hen verantwoordelijk voor is, hoe ze met elkaar communiceren. De constraints zijn de definities van datgene waaraan daarbinnen moet worden voldaan. Door ze samen te laten vallen blijft verborgen waar de echte verschuiving zit, want het deel dat groeit is niet het schema. Het is alles wat daaronder ligt.
Wat verandert, is hoeveel er moet worden vastgelegd. Dit is de kern van de zaak. Wat de auteur probeert te definiëren, is dat architectuur is verschoven van iets wat mensen gebruiken om te communiceren hoe een systeem gebouwd moet worden, zonder diep in te gaan op wat er precies in gebouwd moet worden, naar iets dat voor een AI dat alles moet zijn plus een volledige set regels, implementatierichtlijnen en voorschriften over hoe die componenten gebouwd worden en hoe ze op elkaar inwerken. Een mens die een blauwdruk leest, vult de gaten in met ervaring. Een agent vult ze in om het doel te bereiken, en dat is niet hetzelfde. Dus schrijft de architect die gaten nu uit, wat meer detail oplevert dan voorheen, niet minder. De bouwanalogie werkt hier tegen de auteur: een echte architect ontwerpt de verdiepingen, niet welk beton of wapeningsstaal gebruikt moet worden, maar bij AI-native werk lijkt de overdracht nu eerder op een stuklijst.
De cumulatieve opbrengst. Diep genoeg uitgeschreven betalen deze lagen zich terug. Scheid het projectspecifieke niveau van het herbruikbare implementatieniveau en de regelsets dragen over naar projecten van vergelijkbare complexiteit. Context stapelt zich op, en elk traject laat minder ontwerpwerk over dat bij het volgende opnieuw gedaan moet worden.
Het artikel heeft half gelijk en is half blind. Het gaat ervan uit dat elk systeem een greenfield is met volop context. De meeste enterprisesoftware is dat niet. Een legacyproject heeft doorgaans alleen een schema dat al jaren niet is bijgewerkt, waarbij alles wat sindsdien is gebouwd in de code zelf leeft. Voordat een agent het veilig kan aanraken, moet de status quo worden vastgesteld en de constraintlaag daarbovenop opnieuw worden opgebouwd. De oefening die de auteur beschrijft voor een schone build moet eerst vanaf nul worden gedaan, en die eerste stap is de moeilijke. Dit is ook de reden dat herbouw niet de standaard is. De applicatie is zelden het probleem; de integratieomgeving eromheen wel. Het is nooit één component, en juist dat maakt een omgeving zowel robuust als lastig te upgraden.
Output genereren werd goedkoop. Het valideren ervan niet. De auteur stelt dat de bottleneck is verschoven van het schrijven van code naar het begrijpen ervan. Wij gaan een stap verder: validatie is nu de moeilijkste taak, en meer gegenereerde output maakt teams blinder, niet sneller. We hebben agents een test zien halen door precies terug te geven wat die test verwachtte terwijl de echte integratie werd overgeslagen, halverwege een run test-driven development zien laten vallen en zichzelf klaar zien melden, en documentatie zien bijwerken met alleen de laatste wijziging. Het antwoord daarop zijn controle-agents die implementatie-agents beoordelen, met nog altijd een mens die hercontroleert. Het werkt, maar het is een reële kostenpost waar architectuur nu rekening mee moet houden, inclusief hoe de agents communiceren en wat ze mogen installeren, want een agent zonder beperkingen haalt binnen wat er ook maar nodig is om de klus af te maken.
De link met modernisering
De reden dat dit ertoe doet voor modernisering, is dat het model van de auteur precies datgene veronderstelt wat legacyomgevingen niet hebben: actuele, machineleesbare context. AI-native ontwikkeling wordt ontworpen voor een heden waarin de meeste ondernemingen nog niet leven. Het werk om een echt systeem in een staat te brengen waarin agents er veilig op kunnen opereren, in kaart brengen wat er daadwerkelijk draait, de constraintlaag opnieuw opbouwen en rekening houden met de integratieomgeving eromheen, is hetzelfde moderniseringswerk als altijd. Het gaat niet sneller omdat er een agent in de kamer zit. Als er iets verandert, dan is het dat de agent de lat hoger legt voor hoe helder die context opgeschreven moet worden.
Afsluitende opmerkingen
Uiteindelijk zijn we het eens met de hoofdconclusie van de auteur. Architectuur en de architect worden relevanter in een AI-gedreven wereld, niet minder, omdat iemand aan het stuur moet blijven zitten en verantwoordelijkheid moet nemen voor output die nu goedkoop te genereren en moeilijk te vertrouwen is. Waar we van mening verschillen, is over wat het vak wordt. Het is niet zo dat architectuur verandert in een vage toezichthouder. Het is dat de expertise van de architect afdaalt naar een diepere, uitgeschreven laag van regels en beperkingen, geformuleerd in natuurlijke taal, die een agent kan volgen. Dat geldt voor nieuwe producten, waar die lagen helder kunnen worden opgeschreven en hergebruikt. En het geldt, met veel meer werk vooraf, voor de legacysystemen waar de context eerst opnieuw opgebouwd moet worden voordat hier überhaupt iets van werkt.
Volledige video-aflevering: de idealen van AI-softwaremodernisering versus de realiteit binnen de onderneming
De eerste stap om de moderniseringsreis te starten
Softwaremodernisering en architecturale herbouw vormen de kern van Eli5. We lossen complexiteit op om directe bedrijfswaarde te leveren, met de focus op pragmatische, cloud-native transities.
Voordat wordt besloten om een legacysysteem in te kapselen, een nieuw SaaS-product aan te schaffen of AI in te zetten om maatwerktools te bouwen, heeft een organisatie volledig zicht nodig op het eigen huidige technologielandschap.
Interesse in een gratis brainstorm over de verouderde stack? Het is de essentiële eerste stap om technische schuld om te zetten in een schaalbare, modulaire toekomst.
De eerste stap naar uw modernisering
Softwaremodernisering en architectuurherbouw vormen de kern van Eli5. We halen de complexiteit weg en leveren directe businesswaarde met pragmatische, cloud-native trajecten.
Voordat u besluit of u uw legacysysteem inpakt, een SaaS-product koopt of met AI eigen tools bouwt, hebt u volledig zicht nodig op uw huidige techlandschap.
Wilt u een vrije brainstorm over uw legacystack? Dat is de eerste stap om technische schuld om te zetten in een schaalbare, modulaire toekomst.
