Wereldwijd hoofd van de oplossingenarchitectuur bij AWS deelt zijn model voor AI-gestuurde modernisering

Saurabh Shrivastava is wereldwijd hoofd van de oplossingenarchitectuur en vooruitgeschoven engineering bij Amazon Web Services, waar hij zich richt op agentische AI en modernisering van ondernemingen.

We spraken met Saurabh om meer te weten te komen over de nieuwe engineeringmodellen die hij gebruikt in zijn werk bij AWS. Dit is wat hij deelde.

AI verantwoord industrialiseren

Ik ben een leider op het gebied van technologie- en AI-transformatie met meer dan 20 jaar ervaring in het helpen van ondernemingen om complexe technologische veranderingen om te zetten in schaalbare bedrijfsresultaten. Mijn loopbaan heeft me geleid langs engineering, enterprise-architectuur, productgerichte praktijkengineering, cloudtransformatie en nu agentische AI- en softwarefabrieksmodellen bij AWS.

Eerder in mijn loopbaan heb ik grootschalige bedrijfsplatforms gebouwd en geleid binnen telecom, retail, toeleveringsketens, fintech en R&D-omgevingen. Daardoor heb ik veel waardering gekregen voor systeemdenken, betrouwbaarheid, integratiecomplexiteit en de realiteit van technologie op ondernemingsschaal beheren.

Bij AWS breidde mijn rol zich uit van het helpen van klanten bij het moderniseren van infrastructuur en applicaties tot het leiden van wereldwijde oplossingenarchitectuur en vooruitgeschoven engineeringinitiatieven gericht op AI, modernisering en agentische platforms. Ik heb samengewerkt met bedrijfsleiders, partners, productteams en engineeringteams om van strategie en experimenten over te stappen naar beheerde, productierijpe platforms.

AI is niet langer zomaar een nieuwe technologische golf. Het verandert de manier waarop organisaties software bouwen, medewerkers werken, klanten contact hebben en technologieorganisaties moeten opereren. De echte leiderschapsuitdaging bestaat niet alleen uit het selecteren van modellen of tools. Het gaat om het creëren van het operationele model, de architectuur, governance, het talent en de productdiscipline die nodig zijn om AI op verantwoorde wijze te industrialiseren.

AWS-oplossingenarchitectuur leiden

Als wereldwijd hoofd van de oplossingenarchitectuur en FDE leid ik AWS' wereldwijde organisatie voor oplossingenarchitectuur en vooruitgeschoven engineering, gericht op agentische AI-platforms, modernisering van ondernemingen en cloudtransformatie op productieschaal.

De organisatie opereert op ondernemingsschaal en werkt samen met grote wereldwijde klanten, strategische partners, productteams, gespecialiseerde engineeringteams en regionale veldorganisaties. De architecturale reikwijdte is breed: AI/ML-platforms, agentische workflows, fundamenten voor data en analytics, modernisering van applicaties, cloudgebaseerde infrastructuur, beveiliging, governance en met partners geïntegreerde oplossingen.

Wereldwijd geef ik leiding aan, ondersteun en beïnvloed ik meer dan 200 specialisten, partner-engineers en technologische leiders in het veld. Het werk is zeer complex, omdat we geen geïsoleerde demo's bouwen. We helpen ondernemingen om van vroege AI-ideeën en businesscases voor modernisering over te stappen naar herhaalbare, veilige, productierijpe platforms die kunnen worden opgeschaald over bedrijfsonderdelen, markten en klantomgevingen heen.

Ons implementatiemodel combineert vooruitgeschoven engineering, wereldwijde platformmechanismen, door partners geleverde implementatie en feedbacklussen tussen product en veld. Mijn team bouwt herbruikbare blauwdrukken, referentiearchitecturen, demonstraties voor bestuurders, technische draaiboeken, governancepatronen en samenstelbare oplossingsmodellen die de toepassing versnellen en tegelijkertijd kwaliteit, beveiliging en operationele discipline handhaven.

Waarom een model met vooruitgeschoven engineering essentieel is voor AI

Vorig jaar introduceerde ik een model met vooruitgeschoven engineering voor AI-gestuurde modernisering.

In het cloudtijdperk beschikten we over herbruikbare referentiearchitecturen, oplossingsblauwdrukken, implementatiepatronen en controlepunten voor governance. Deze waren noodzakelijk, maar onvoldoende voor AI. Klanten hadden nog steeds moeite om van POC naar productie te gaan, omdat het moeilijkste werk plaatsvond binnen hun daadwerkelijke omgeving: data, applicatielandschap, codecomplexiteit, beveiligingsbeperkingen en operationeel model.

Daarom introduceerde ik een FDE-mechanisme waarbij engineers veel dichter bij de daadwerkelijke werklasten van de klant worden ingezet. In plaats van van buitenaf advies te geven, werkt het FDE-team met de data, code, architectuur en leveringsteams van de klant om kandidaten voor modernisering te identificeren, bruikbare middelen te bouwen en de eerste werklast naar productie te brengen.

Ik introduceerde ook een eenvoudig 3-3-3-model: 3 dagen voor ontdekking, 3 weken voor beoordeling en 3 maanden om de eerste werklast naar productie te brengen. Hierdoor kregen bestuurders een duidelijk traject van AI-ambitie naar meetbare waarde.

De impact was aanzienlijk. Klanten konden hun moderniseringstraject 2x tot 4x versnellen, de kosten met maximaal de helft verlagen en verder gaan dan demo's naar gerealiseerde ROI. Belangrijker nog: het veranderde het gesprek met bestuurders. AI was niet langer een zijexperiment; het werd een praktisch middel om echte werklasten te moderniseren, de productiviteit van engineers te verbeteren en meetbare bedrijfswaarde te creëren.

Sneller moderniseren zonder vertrouwen te verliezen

Ik gebruik AI intensief om technisch inzicht, patroonherkenning en engineeringcapaciteit te versnellen, maar ik delegeer de verantwoordelijkheid niet aan AI.

In complexe ondernemingen is de bedrijfsvoering vaak gebaseerd op tientallen jaren oude code, technische schuld, niet-gedocumenteerde afhankelijkheden en ingebedde bedrijfsregels. In die omgeving hebben we zowel deterministische als probabilistische benaderingen nodig. Je kunt niet uitsluitend vertrouwen op probabilistische AI-ontdekking wanneer je bedrijfskritische systemen probeert te begrijpen.

Voor code-ontdekking, het extraheren van bedrijfsregels, afhankelijkheidsanalyse, het in kaart brengen van functionaliteit en de beoordeling van de huidige situatie geef ik de voorkeur aan een meer deterministische aanpak. We hebben traceerbaarheid, herhaalbaarheid, bewijs en vertrouwen nodig in wat het systeem doet. AI kan helpen door analyses samen te vatten, te clusteren en te versnellen, maar de basis moet bestaan uit verifieerbare feiten uit code, logboeken, gegevensstromen, runtimegedrag en architectuurbewijs.

AI wordt krachtiger bij werk rond de toekomstige situatie: het genereren van moderniseringsopties, het voorstellen van nieuwe architecturen, het definiëren van servicegrenzen, het ontwikkelen van migratiepatronen, het schrijven van code, het genereren van tests en het versnellen van de implementatie. Dat onderdeel kan probabilistischer zijn, omdat AI opties kan verkennen en de engineeringcapaciteit kan vergroten.

Maar zelfs daar blijft de uiteindelijke beslissing bij de mens. Verantwoordelijke engineers en leiders moeten architectuurkeuzes, de beveiligingsstatus, productiegereedheid, compliancerisico's, de impact op klanten en afwegingen rond investeringen valideren.

Mijn model is dus: deterministische ontdekking, door AI versnelde ontwerp- en implementatie, en door mensen aangestuurde validatie. Met die combinatie kunnen we sneller moderniseren zonder vertrouwen, controle of verantwoordelijkheid binnen de onderneming te verliezen.

De nadelen van AI in engineeringwerkprocessen

Saurabh deelt

Kosten zijn niet het enige nadeel (van AI). AI kan ook een vals gevoel van vertrouwen creëren als teams het zonder governance gebruiken.

Het grootste positieve resultaat was dat AI de weg van ontdekking naar productie aanzienlijk verkortte wanneer het werd ingebed in een gedisciplineerd engineeringwerkproces.

AI versnelde ook het begrijpen van code, het extraheren van bedrijfsregels, afhankelijkheidsanalyse, het genereren van tests, documentatie en moderniseringsplanning. Het verminderde de tijd voor handmatige analyse, waardoor engineeringteams zich meer konden richten op architectuurbeslissingen, validatie en productiegereedheid.

Maar AI kan heel snel erg duur worden als teams geen rekening houden met de economie van inferentie. In grote ondernemingen met miljoenen gebruikers kunnen de tokenkosten van geavanceerde modellen oplopen tot miljoenen dollars als elke interactie zonder optimalisatie afhankelijk is van externe fundamentele modellen van derden.

Een les is dat AI-architectuur ook kostenarchitectuur moet omvatten. Voor sommige werklasten zouden ondernemingen zelf gehoste of door de cloud gehoste inferentie met GPU's of versnellers moeten evalueren, waaronder opties zoals vLLM op cloudinfrastructuur. Dit geeft meer controle over kosten, latentie, gegevensgrenzen en de strategie voor het aanbieden van modellen. Technieken zoals KV-caching, continue batchverwerking, kwantisering en kerneloptimalisatie kunnen het GPU-gebruik aanzienlijk verbeteren en de inferentiekosten verlagen.

Kosten zijn niet het enige nadeel. AI kan ook een vals gevoel van vertrouwen creëren als teams het zonder governance gebruiken. Risico's zijn onder meer een onvolledig begrip van code, verzonnen afhankelijkheden, onvoldoende testdekking, beveiligingslekken en teams die te snel van prototype naar productie gaan.

Waarom AI moeite heeft met modernisering van verouderde systemen van begin tot eind

AI heeft de meeste moeite wanneer teams het vragen om technische oordelen te vellen zonder voldoende systeemcontext.

Een veelvoorkomend voorbeeld is modernisering van legacy-systemen. AI kan code samenvatten, migratie-ideeën genereren en zelfs snel nieuwe code produceren. Maar in grote ondernemingen reikt de werkelijke complexiteit verder dan de code. Het gaat om tientallen jaren aan bedrijfsregels, niet-gedocumenteerde integraties, batchtaken, gegevensafhankelijkheden, operationele uitzonderingen, beveiligingsbeperkingen en organisatorisch eigenaarschap. Als je AI vraagt om die omgeving te moderniseren met slechts een gedeeltelijk beeld, kan het zelfverzekerde maar onvolledige antwoorden produceren.

Productierijpheid is een ander gebied waarop AI moeite heeft. AI kan zeer snel prototypes maken, maar veel prototypes worden niet automatisch veilige, observeerbare, veerkrachtige en kostenefficiënte productiesystemen. Teams onderschatten soms het werk dat nodig is voor testen, governance, incidentrespons, monitoring, modelevaluatie, gegevenskwaliteit en levenscyclusbeheer.

Hoe ingenieurs producten kunnen verbeteren en tegelijkertijd inferentiekosten en betrouwbaarheid beheersen

Hier is een voorbeeld van een groot platform voor het creëren van media- en marketingcontent, waar AI gebruikers helpt om op ondernemingsschaal van intentie naar voltooide digitale middelen te gaan.

De workflow begint wanneer een gebruiker beschrijft wat die wil maken: een campagne voor een productlancering, een uiting voor sociale media, een verkooppresentatie, een videofragment of een gelokaliseerd marketingmiddel. AI interpreteert de intentie van de gebruiker, waaronder doelgroep, indeling, toon, merkrichtlijnen, vereiste middelen, kanaalbeperkingen en nalevingsvereisten.

Van daaruit gebruikt het platform een agentgestuurde workflow. Eén agent haalt door het merk goedgekeurde sjablonen, logo's, lettertypen, kleuren en campagnemiddelen op. Een andere genereert teksten en creatieve varianten. Weer een andere stelt indelingen voor. Nog een andere controleert merknaleving, toegankelijkheid, beleid en inhoudsveiligheid. Een laatste orkestratielaag stelt de uitvoer samen tot bewerkbare middelen en leidt deze door goedkeurings- of publicatieworkflows.

Op deze schaal kreeg engineering niet alleen te maken met uitdagingen op het gebied van modelkwaliteit, maar ook met inferentie-economie, latentie, betrouwbaarheid en governance. Het team optimaliseerde een zeer grootschalige inferentieomgeving met ondersteuning voor ongeveer 10.000 rekenknooppunten en circa 80.000 GPU's. De architectuur combineerde GPU-capaciteit van meerdere cloudproviders en goedgekeurde externe partijen en verbond deze omgevingen via een hybride netwerklaag. Hierdoor kon het platform werklasten flexibel plaatsen op basis van kosten, latentie, beschikbaarheid en gegevenslokaliteit.

Het team implementeerde ook een meer gedisciplineerde strategie voor het aanbieden van modellen. In plaats van elk verzoek naar het duurste grensverleggende model te sturen, leidde het platform verzoeken door naar modellen die geschikt waren voor het doel, waaronder open modellen zoals Kimi en Qwen, aangeboden via geoptimaliseerde uitvoeringsomgevingen zoals vLLM en patronen in Ollama-stijl. Het team paste ook technieken voor inferentie-optimalisatie toe, waaronder KV-caching, continue batching, kwantisatie, geheugenoptimalisatie en afstemming op kernelniveau, om het GPU-gebruik te verbeteren en kosten te verlagen.

Mensen hielden op de belangrijkste beoordelingsmomenten de controle. AI genereerde opties, deed indelingen aan de hand, schreef teksten en versnelde de productie, maar de gebruiker of merkeigenaar keurde het uiteindelijke middel goed. Engineeringteams waren verantwoordelijk voor de beveiligingsmaatregelen: beveiliging, gegevenstoegang, modelselectie, observeerbaarheid, latentie, kostenbeheersing, veiligheidscontroles en terugkoppelingslussen.

Het resultaat was een AI-werkstroom die onderdeel werd van de productervaring, in plaats van slechts een intern productiviteitshulpmiddel. De tijd van idee tot middel werd verkort, personalisatie verbeterde, goedgekeurde merkcomponenten werden vaker hergebruikt en er ontstond een terugkoppelingslus waarin gebruikersbewerkingen en betrokkenheidsgegevens toekomstige aanbevelingen verbeterden. Tegelijkertijd gaf de architectuur het bedrijf aanzienlijk meer controle over inferentiekosten, betrouwbaarheid en governance.

Waarom AI-uitrol een productgerichte mentaliteit vereist

De uitrol van AI-hulpmiddelen draait minder om het gebruik van hulpmiddelen en meer om het veranderen van het operationele model van engineering.

Aanvankelijk denken veel organisaties dat de uitdaging bestaat uit engineers toegang geven tot programmeercopilots, programmeerassistenten, model-API's of interne AI-platforms. Dat helpt, maar het is niet genoeg. Zonder duidelijke patronen gebruiken teams AI inconsistent. Sommigen gebruiken het alleen voor het genereren van code. Anderen gebruiken het voor documentatie. Sommigen vertrouwen er te veel op. Weer anderen vermijden het omdat ze onzeker zijn over beveiligings-, intellectuele-eigendoms- of kwaliteitsrisico's.

Als ik opnieuw zou beginnen, zou ik de AI-engineeringworkflow nog eerder definiëren: waar AI wel en niet moet worden gebruikt, welk bewijs vereist is, wat mensen moeten beoordelen en hoe de uitvoer wordt getest, beveiligd en naar productie wordt bevorderd.

Dit zou enkele problemen hebben voorkomen. Ten eerste hadden we inconsistent gebruik binnen teams kunnen verminderen. Ten tweede hadden we misplaatst vertrouwen in door AI gegenereerde code of analyses die er correct uitzagen, maar onvoldoende context bevatten, kunnen voorkomen. Ten derde hadden we de kosten eerder kunnen beheersen door vanaf het begin modelroutering, tokenbudgettering, caching en governance voor inferentie te implementeren. Ten vierde hadden we betere herbruikbare patronen kunnen creëren in plaats van elk team zijn eigen aanpak te laten bedenken.

De belangrijkste les is dat de uitrol van AI een product- en platformmindset vereist. Je hebt enablement, vangrails, waarneembaarheid, kostenbeheersing, beveiligingsbeoordeling, herbruikbare prompts en agents, evaluatiepatronen en duidelijke menselijke verantwoordelijkheid nodig. Anders verhoogt AI de activiteit zonder altijd de engineeringkwaliteit of bedrijfswaarde te verhogen.

Waarom de SDLC de AI-DLC moet worden

Saurabh deelt

CTO’s zouden de softwareontwikkelingslevenscyclus zelf actief opnieuw moeten ontwerpen.

CTO's zouden de softwareontwikkelingslevenscyclus zelf actief opnieuw moeten ontwerpen. Ik zie dit als een overgang van de traditionele SDLC naar AI-DLC, een door AI versterkte ontwikkelingslevenscyclus voor het tijdperk van agentische AI.

Bij de traditionele SDLC volgen we vaak lineaire fasen: vereisten, ontwerp, ontwikkeling, implementatie en ondersteuning. Dat werkte redelijk goed toen het hoofddoel was om deterministische software te bouwen via gestructureerde overdrachtsmomenten. Maar met AI, en vooral met agentische AI, wordt de levenscyclus iteratiever en compacter.

Ik vereenvoudig AI-DLC tot drie belangrijke fasen: begin, constructie en exploitatie.

• In de beginfase helpt AI bij verkenning, codebegrip, het extraheren van bedrijfsregels, afhankelijkheidsanalyse, het verduidelijken van vereisten, risico-identificatie en het plannen van de doeltoestand.
• In de constructiefase ondersteunt AI bij architectuuropties, service-ontleding, het genereren van code en tests, documentatie, beveiligingsbeoordelingen, infrastructuurpatronen en de uitvoering van modernisering.
• In de exploitatiefase ondersteunt AI waarneembaarheid, incidenttriage, feedbacklussen, modelevaluatie, kostenoptimalisatie, governance en continue verbetering.

Het belangrijke punt is dat AI-DLC niet simpelweg SDLC is met een codeerassistent erbij. Het is een opnieuw ontworpen operationeel model voor engineering. Het integreert AI-agents, deterministische verkenning, menselijke validatie, beveiligingspoorten, productiegereedheid en kostenbeheer in één workflow.

Hoe ontwikkelteams veranderen door AI

AI heeft ontwikkelteams verschoven van rolgebaseerde, sequentiële uitvoering naar meer geïntegreerde, resultaatgerichte teams.

In het verleden organiseerden we ons rond afzonderlijke rollen: architecten, applicatie-ontwikkelaars, data-engineers, DevOps, beveiliging, QA en operationeel beheer. Die rollen blijven belangrijk, maar AI verkort de levenscyclus en vermindert de waarde van lange overdrachtsmomenten. De best presterende teams zijn meer crossfunctioneel en staan dichter bij het bedrijfsprobleem.

Voor AI-gestuurde modernisering en productontwikkeling zoek ik nu naar teams die verschillende capaciteiten combineren: sterke fundamenten in softwareontwikkeling, cloud- en platformontwikkeling, data- en AI-vaardigheid, beveiligingsbewustzijn, productdenken en operationeel inzicht. Ik waardeer ook technici die in ambigue omgevingen werken, vanuit eerste principes redeneren en AI-uitvoer valideren in plaats van die blindelings te accepteren.

Het model van vooruitgeschoven technische teams is een goed voorbeeld. In plaats van architectuur, AI-engineering, DevOps en beveiliging in afzonderlijke, sequentiële banen te houden, brengen we die vaardigheden dichter bij de klant- of bedrijfsomgeving. Het team werkt met echte code, data, beperkingen en succesmaatstaven.

Ook de werving is veranderd. Ik hecht nog steeds veel waarde aan technische diepgang, maar ik zoek ook naar systeemdenkers: mensen die architectuur begrijpen, AI verantwoordelijk gebruiken, communiceren met zakelijke belanghebbenden en verantwoordelijkheid nemen voor productieresultaten. In het AI-tijdperk zijn de beste ontwikkelaars niet alleen codeproducenten. Het zijn ook mensen die problemen kaderen, validatie-experts en bouwers van herhaalbare systemen.

Hoe je de effectiviteit van AI meet

Een vraag die ik vaker gesteld zou willen zien, is: Hoe zouden CTO's moeten meten of AI duurzame bedrijfswaarde creëert?

CTO's zouden AI niet alleen moeten beoordelen op basis van het aantal ingezette pilots of AI-assistenten, of op modelnauwkeurigheid op zichzelf. Dit zijn nuttige signalen, maar ze bewijzen geen transformatie.

CTO's zouden AI langs vier dimensies moeten meten:

1. Technische productiviteit: Vermindert AI de doorlooptijd, verbetert het de codekwaliteit, vergroot het de testdekking, versnelt het modernisering en vermindert het de technische schuld?
2. Bedrijfsimpact: Verbetert AI de klantervaring, de productiviteit van medewerkers, de omzetconversie, de kostenefficiëntie of de snelheid waarmee producten op de markt komen?
3. Productievolwassenheid: Zijn AI-systemen veilig, observeerbaar, betrouwbaar, beheerst en kostengecontroleerd? Hebben ze duidelijke menselijke verantwoordelijkheid en duidelijke poorten voor productiegereedheid?
4. Herbruikbaarheid en schaalbaarheid: Bouwen teams herbruikbare AI-diensten, AI-agenten, instructies, patronen, dataproducten en platformmogelijkheden, of creëren ze geïsoleerde demo's?

Dit is belangrijk omdat AI veel zichtbare activiteit kan creëren zonder duurzame waarde te creëren. CTO's moeten AI-activiteiten omzetten in herhaalbare capaciteiten. Dit betekent dat strategie, architectuur, bedrijfsmodel, governance en economie met elkaar worden verbonden.

Waarom CTO's experimenteren moeten scheiden van industrialisatie

Dit is mijn advies.

Ten eerste: behandel AI niet als een nevenexperiment. Beschouw het als een nieuwe operationele laag voor het bedrijf. AI zal invloed hebben op de manier waarop software wordt gebouwd, medewerkers werken, klanten contact maken en beslissingen worden genomen. Het is de taak van de CTO om de organisatie van verspreide pilots naar een beheerst en schaalbaar AI-platform te leiden.

Ten tweede: scheid experimenteren van industrialisatie. Snel experimenteren is prima, maar productiegerichte AI heeft architectuur, beveiliging, datagovernance, evaluatie, observeerbaarheid, kostenbeheersing en duidelijke menselijke verantwoordelijkheid nodig. Veel bedrijven zitten vast omdat ze veel demo's hebben, maar geen herhaalbare route naar productie. CTO's moeten die route opbouwen.

Ten derde: richt je op bedrijfswaarde, niet op de nieuwigheid van modellen. De succesvolle organisaties zullen niet de organisaties zijn die simpelweg het nieuwste model gebruiken. Het zullen de organisaties zijn die AI in echte werkprocessen verankeren, hun technologische fundament moderniseren, de technische productiviteit verbeteren en resultaten meten zoals doorlooptijd, kostenefficiëntie, klantervaring, omzetimpact en risicoreductie.

En ten vierde: mijn praktische advies is om samen een AI-platform en een model voor gedecentraliseerde ontwikkeling in te richten. Het platform biedt hergebruik, governance en schaal. Het model voor gedecentraliseerde ontwikkeling brengt AI naar echte klant- en bedrijfswerklasten, met gebruik van echte gegevens, echte code en echte beperkingen. Zo kunnen CTO's de stap maken van AI-ambitie naar gerealiseerde ROI.

Volg mee

Volg het werk van Saurabh Shrivastava op LinkedIn en zijn auteurspagina op Amazon.

Er volgen meer interviews met experts op The CTO Club!