AWS’ globale chef for løsningsarkitektur deler sin model for AI-ledet modernisering

Saurabh Shrivastava er global chef for løsningsarkitektur og fremadrettet implementeringsteknik hos Amazon Web Services, hvor han fokuserer på agentisk AI og modernisering af virksomheder.

Vi satte os ned med Saurabh for at høre om de nye ingeniørmodeller, som han bruger i sit arbejde hos AWS. Her er, hvad han fortalte.

Ansvarlig industrialisering af AI

Jeg er leder inden for teknologi- og AI-transformation med over 20 års erfaring i at hjælpe virksomheder med at omsætte komplekse teknologiske skift til skalerbare forretningsresultater. Min karriere har ført mig gennem ingeniørarbejde, virksomhedsarkitektur, produktorienteret feltteknik, cloud-transformation og nu agentisk AI samt softwarefabriksmodeller hos AWS.

Tidligere i min karriere opbyggede og ledede jeg store virksomhedsplatforme inden for telekommunikation, detailhandel, forsyningskæder, fintech og forsknings- og udviklingsmiljøer. Det gav mig en stærk forståelse for systemtænkning, pålidelighed, integrationskompleksitet og realiteten ved at drive teknologi i virksomhedsskala.

Hos AWS blev min rolle udvidet fra at hjælpe kunder med at modernisere infrastruktur og applikationer til at lede global løsningsarkitektur og fremadrettede implementeringstekniske initiativer med fokus på AI, modernisering og agentiske platforme. Jeg har arbejdet sammen med virksomhedsledere, partnere, produktteams og ingeniørteams for at bevæge os fra strategi og eksperimentering til styrede, produktionsklare platforme.

AI er ikke længere blot endnu en teknologibølge. Den ændrer den måde, organisationer udvikler software på, hvordan medarbejdere arbejder, hvordan kunder interagerer, og hvordan teknologiorganisationer skal fungere. Den egentlige ledelsesudfordring handler ikke kun om at vælge modeller eller værktøjer. Det handler om at skabe den driftsmodel, arkitektur, styring, de kompetencer og den produktdisciplin, der skal til for at industrialisere AI ansvarligt.

Ledelse af AWS' løsningsarkitektur

Som global chef for løsningsarkitektur og FDE leder jeg AWS' globale organisation for løsningsarkitektur og fremadrettet implementeringsteknik med fokus på agentiske AI-platforme, modernisering af virksomheder og cloud-transformation i produktionsskala.

Organisationen arbejder i virksomhedsskala sammen med store globale kunder, strategiske partnere, produktteams, specialiserede ingeniørteams og regionale feltorganisationer. Arkitekturens område er bredt: AI/ML-platforme, agentiske arbejdsgange, data- og analysefundamenter, modernisering af applikationer, cloud-native-infrastruktur, sikkerhed, styring og partnerintegrerede løsninger.

Jeg leder, muliggør og påvirker mere end 200 specialister, partneringeniører og teknologiledere i felten globalt. Arbejdet er meget komplekst, fordi vi ikke bygger isolerede demoer. Vi hjælper virksomheder med at bevæge sig fra tidlige AI-idéer og moderniseringsforretningscases til gentagelige, sikre, produktionsklare platforme, der kan skaleres på tværs af forretningsenheder, markeder og kundemiljøer.

Vores implementeringsmodel kombinerer fremadrettet implementeringsteknik, globale platformsmekanismer, partnerdrevet levering og feedbacksløjfer mellem produkt og felt. Mit team udvikler genanvendelige skabeloner, referencearkitekturer, ledelsesdemoer, tekniske drejebøger, styringsmønstre og sammensættelige løsningsmodeller, der fremskynder ibrugtagningen og samtidig opretholder kvalitet, sikkerhed og driftsdisciplin.

Hvorfor en fremadrettet implementeringsteknisk model er afgørende med AI

Jeg introducerede sidste år en fremadrettet implementeringsteknisk model til AI-drevet modernisering.

I cloud-æraen havde vi genanvendelige referencearkitekturer, løsningsskabeloner, implementeringsmønstre og kontrolpunkter for styring. De var nødvendige, men utilstrækkelige med AI. Kunder havde stadig svært ved at bevæge sig fra POC til produktion, fordi det vanskeligste arbejde foregik i deres faktiske miljø: data, applikationsportefølje, kodekompleksitet, sikkerhedsbegrænsninger og driftsmodel.

Derfor introducerede jeg en FDE-mekanisme, som placerer ingeniører meget tættere på kundens faktiske arbejdsbelastninger. I stedet for at rådgive udefra arbejder FDE-teamet med kundens data, kode, arkitektur og leveringsteams for at identificere kandidater til modernisering, opbygge anvendelige aktiver og flytte den første arbejdsbelastning i produktion.

Jeg introducerede også en enkel 3-3-3-model: 3 dage til afdækning, 3 uger til vurdering og 3 måneder til at flytte den første arbejdsbelastning i produktion. Det gav ledere en tydelig vej fra AI-ambition til målbar værdi.

Effekten var betydelig. Kunderne kunne fremskynde deres moderniseringsrejse med 2x til 4x, reducere omkostningerne med op til det halve og komme videre end demoer til realiseret ROI. Endnu vigtigere ændrede det samtalen på ledelsesniveau. AI var ikke længere et sideeksperiment; det blev en praktisk mekanisme til at modernisere reelle arbejdsbelastninger, forbedre ingeniørproduktiviteten og skabe målbar forretningsværdi.

Sådan moderniserer du hurtigere uden at miste tilliden

Jeg bruger AI i stor udstrækning til at fremskynde teknisk forståelse, mønstergenkendelse og udviklingskapacitet, men jeg overlader ikke ansvaret til AI.

I komplekse virksomheder er forretningen ofte bygget på årtiers kode, teknisk gæld, udokumenterede afhængigheder og indlejrede forretningsregler. I det miljø har vi brug for både deterministiske og probabilistiske tilgange. Man kan ikke udelukkende stole på probabilistisk AI-baseret afdækning, når man forsøger at forstå missionskritiske systemer.

Til kodeafdækning, udtrækning af forretningsregler, afhængighedsanalyse, funktionskortlægning og vurdering af den nuværende tilstand foretrækker jeg en mere deterministisk tilgang. Vi har brug for sporbarhed, gentagelighed, dokumentation og tillid til, hvad systemet gør. AI kan hjælpe ved at opsummere, gruppere og fremskynde analysen, men fundamentet skal bestå af verificerbare fakta fra kode, logfiler, dataflows, runtime-adfærd og arkitektonisk dokumentation.

AI bliver mere effektivt i arbejdet med den fremtidige tilstand: generering af moderniseringsmuligheder, forslag til nye arkitekturer, definition af servicegrænser, udvikling af migrationsmønstre, skrivning af kode, generering af tests og acceleration af implementeringen. Denne del kan være mere probabilistisk, fordi AI kan udforske muligheder og øge udviklingshastigheden.

Men selv her forbliver den endelige beslutning menneskelig. Ansvarlige udviklere og ledere skal validere arkitekturvalg, sikkerhedsniveau, produktionsparathed, compliancerisiko, kundeimpact og afvejninger vedrørende investeringer.

Min model er derfor: deterministisk afdækning, AI-accelereret design og implementering samt menneskestyret validering. Denne kombination gør det muligt for os at modernisere hurtigere uden at miste tillid, kontrol eller virksomhedens ansvarlighed.

Ulemperne ved AI i udviklingsarbejdsgange

Saurabh deler

Omkostninger er ikke den eneste ulempe ved AI. AI kan også skabe falsk tryghed, hvis teams bruger det uden styring.

Det største positive resultat var, at AI forkortede vejen fra afdækning til produktion markant, når det blev integreret i en disciplineret udviklingsarbejdsgang.

AI satte også fart på kodeforståelse, udtrækning af forretningsregler, afhængighedsanalyse, testgenerering, dokumentation og moderniseringsplanlægning. Det reducerede tiden til manuel analyse og hjalp udviklingsteams med i højere grad at fokusere på arkitekturbeslutninger, validering og produktionsparathed.

Men AI kan blive meget dyrt meget hurtigt, hvis teams ikke designer med fokus på inferensøkonomi. I store virksomheder med millioner af brugere kan tokenomkostninger for avancerede modeller løbe op i millioner af dollars, hvis enhver interaktion afhænger af eksterne tredjepartsgrundmodeller uden optimering.

En læring er, at AI-arkitektur skal omfatte en omkostningsarkitektur. For visse arbejdsbelastninger bør virksomheder evaluere selvhostet eller cloudhostet inferens ved hjælp af GPU'er eller acceleratorer, herunder muligheder som vLLM på cloudinfrastruktur. Det giver større kontrol over omkostninger, svartid, datagrænser og strategien for modelservering. Teknikker som KV-caching, kontinuerlig batching, kvantisering og kerneoptimering kan forbedre GPU-udnyttelsen mærkbart og reducere inferensomkostningerne.

Omkostninger er ikke den eneste ulempe. AI kan også skabe falsk tryghed, hvis teams bruger det uden styring. Risiciene omfatter ufuldstændig kodeforståelse, opdigtede afhængigheder, utilstrækkelig testdækning, sikkerhedshuller og teams, der bevæger sig for hurtigt fra prototype til produktion.

Hvorfor AI har vanskeligt ved komplet modernisering af ældre systemer

AI har haft størst vanskeligt ved opgaver, hvor teams beder det træffe tekniske vurderinger uden tilstrækkelig systemkontekst.

Et almindeligt eksempel er modernisering af ældre systemer. AI kan opsummere kode, generere idéer til migrering og endda hurtigt producere ny kode. Men i store virksomheder rækker den reelle kompleksitet ud over selve koden. Den omfatter årtiers forretningsregler, udokumenterede integrationer, batchjob, dataafhængigheder, operationelle undtagelser, sikkerhedsbegrænsninger og organisatorisk ejerskab. Hvis du beder AI om at modernisere dette miljø ud fra et ufuldstændigt billede, kan den levere overbevisende, men ufuldstændige svar.

Produktionsberedskab er et andet område, hvor den har vanskeligheder. AI kan skabe prototyper meget hurtigt, men mange prototyper bliver ikke automatisk til sikre, overvågbare, robuste og omkostningseffektive produktionssystemer. Teams undervurderer nogle gange det arbejde, der kræves til test, styring, hændelseshåndtering, overvågning, modelevaluering, datakvalitet og livscyklusstyring.

Hvordan ingeniører kan forbedre produkter og samtidig kontrollere inferensomkostninger og pålidelighed

Her er et eksempel fra en stor platform til medie- og marketingindholdsproduktion, hvor AI hjælper brugere med at gå fra intention til færdige digitale aktiver i virksomhedsskala.

Arbejdsgangen begynder, når en bruger beskriver, hvad vedkommende vil skabe: en kampagne til en produktlancering, kreativt indhold til sociale medier, en salgspresentation, et videoklip eller et lokaliseret marketingaktiv. AI fortolker brugerens intention, herunder målgruppe, format, tone, brandretningslinjer, nødvendige aktiver, kanalbegrænsninger og krav om overholdelse.

Herfra anvender platformen en agentbaseret arbejdsgang. Én agent henter brandgodkendte skabeloner, logoer, skrifttyper, farver og kampagneaktiver. En anden genererer tekst og kreative variationer. En tredje foreslår layout. En fjerde kontrollerer overholdelse af brandretningslinjer, tilgængelighed, politikker og indholdssikkerhed. Et afsluttende orkestreringslag samler outputtet i redigerbare aktiver og sender det gennem arbejdsgange til godkendelse eller publicering.

I denne skala stod ingeniørarbejdet over for udfordringer, der ikke kun handlede om modelkvalitet, men også om inferensøkonomi, latenstid, pålidelighed og styring. Teamet optimerede et inferensmiljø i meget stor skala, der understøttede cirka 10.000 computernoder og omkring 80.000 GPU'er. Arkitekturen kombinerede GPU-kapacitet fra flere cloududbydere og godkendte tredjeparter og forbandt disse miljøer gennem et hybridt netværkslag. Det gav platformen fleksibilitet til at placere arbejdsbelastninger baseret på omkostninger, latenstid, tilgængelighed og datalokation.

Teamet implementerede også en mere disciplineret strategi for modelservering. I stedet for at sende hver forespørgsel til den dyreste frontlinjemodel dirigerede platformen forespørgsler på tværs af formålsegnede modeller, herunder åbne modeller som Kimi og Qwen, der blev kørt gennem optimerede kørselsmiljøer som vLLM og mønstre i stil med Ollama. Teamet anvendte også teknikker til optimering af inferens, herunder KV-caching, kontinuerlig batching, kvantisering, hukommelsesoptimering og justering på kernel-niveau, for at forbedre GPU-udnyttelsen og reducere omkostningerne.

Mennesker forblev i kontrol på de afgørende vurderingspunkter. AI genererede muligheder, anbefalede layout, skrev tekst og fremskyndede produktionen, men brugeren eller brandejeren godkendte det endelige aktiv. Ingeniørteams ejede sikkerhedsforanstaltningerne: sikkerhed, dataadgang, modelvalg, observerbarhed, latenstid, omkostningskontrol, sikkerhedstjek og feedbacksløjfer.

Resultatet blev en AI-arbejdsgang, der blev en del af produktopplevelsen og ikke blot et internt produktivitetsværktøj. Den reducerede tiden fra idé til aktiv, forbedrede personaliseringen, øgede genbruget af godkendte brandkomponenter og skabte en feedbacksløjfe, hvor brugerredigeringer og engagementdata forbedrede fremtidige anbefalinger. Samtidig gav arkitekturen virksomheden langt stærkere kontrol over inferensomkostninger, pålidelighed og styring.

Hvorfor udrulning af AI kræver en produktorienteret tankegang

Udrulning af AI-værktøjer handler mindre om at tage værktøjerne i brug og mere om at ændre den operationelle model for ingeniørarbejdet.

Oprindeligt tror mange organisationer, at udfordringen består i at give ingeniører adgang til copiloter, kodningsassistenter, model-API'er eller interne AI-platforme. Det hjælper, men det er ikke nok. Uden klare mønstre anvender teams AI inkonsekvent. Nogle bruger det kun til kodegenerering. Nogle bruger det til dokumentation. Nogle har for stor tillid til det. Andre undgår det, fordi de er usikre på risici vedrørende sikkerhed, immaterielle rettigheder eller kvalitet.

Hvis jeg skulle begynde forfra, ville jeg definere AI-arbejdsgangen for ingeniørarbejdet endnu tidligere: hvor AI bør og ikke bør anvendes, hvilken dokumentation der kræves, hvad mennesker skal gennemgå, og hvordan output testes, sikres og promoveres til produktion.

Dette ville have afværget nogle problemer. For det første kunne vi have reduceret inkonsistent anvendelse på tværs af teams. For det andet kunne vi have undgået uberettiget tillid til AI-genereret kode eller analyse, der så korrekt ud, men manglede tilstrækkelig kontekst. For det tredje kunne vi tidligere have kontrolleret omkostningerne ved fra begyndelsen at implementere modelrouting, tokenbudgettering, caching og inferensstyring. For det fjerde kunne vi have skabt bedre genanvendelige mønstre i stedet for at lade hvert team opfinde sin egen tilgang.

Den vigtigste læring er, at AI-udrulning kræver en produkt- og platformstankegang. Man har brug for kompetenceopbygning, sikkerhedsrammer, observerbarhed, omkostningskontrol, sikkerhedsgennemgang, genanvendelige prompts og agenter, evalueringsmønstre samt et tydeligt menneskeligt ansvar. Ellers øger AI aktiviteten uden altid at øge kvaliteten af udviklingsarbejdet eller forretningsværdien.

Hvorfor SDLC skal blive til AI-DLC

Saurabh deler

CTO’er bør aktivt gentænke selve livscyklussen for softwarelevering.

CTO'er bør aktivt gentænke selve livscyklussen for softwarelevering. Jeg ser dette som en bevægelse fra traditionel SDLC til AI-DLC, en AI-forstærket leveringslivscyklus til den agentiske AI-æra.

I traditionel SDLC følger vi ofte lineære faser: krav, design, udvikling, implementering og support. Det fungerede rimeligt godt, da det primære mål var at bygge deterministisk software gennem strukturerede overdragelser. Men med AI, især agentisk AI, bliver livscyklussen mere iterativ og komprimeret.

Jeg opdeler AI-DLC i tre overordnede faser: igangsættelse, konstruktion og drift.

• I igangsættelsesfasen hjælper AI med afdækning, kodeforståelse, udledning af forretningsregler, afhængighedsanalyse, præcisering af krav, identifikation af risici og planlægning af måltilstanden.
• I konstruktionsfasen hjælper AI med arkitekturmæssige muligheder, opdeling af tjenester, generering af kode og tests, dokumentation, sikkerhedsgennemgange, infrastrukturtmønstre og moderniseringseksekvering.
• I driftsfasen understøtter AI observerbarhed, hændelsessortering, feedbacksløjfer, modelevaluering, omkostningsoptimering, styring og løbende forbedringer.

Det vigtige er, at AI-DLC ikke bare er SDLC med en kodeassistent tilføjet. Det er en gentænkt operationel model for udvikling. Den integrerer AI-agenter, deterministisk afdækning, menneskelig validering, sikkerhedsgates, produktionsparathed og omkostningsstyring i én samlet arbejdsgang.

Hvordan udviklingsteams ændrer sig på grund af AI

AI har flyttet udviklingsteams fra rollebaseret, sekventiel udførelse til mere integrerede, resultatorienterede teams.

Tidligere organiserede vi os omkring adskilte roller: arkitekter, applikationsudviklere, dataingeniører, DevOps, sikkerhed, QA og drift. Disse roller er stadig vigtige, men AI komprimerer livscyklussen og mindsker værdien af lange overdragelser. De bedst præsterende teams er mere tværfunktionelle og tættere på forretningsproblemet.

Til AI-ledet modernisering og produktudvikling søger jeg nu teams, der kombinerer flere kompetencer: stærke grundlæggende softwareudviklingsfærdigheder, cloud- og platformsteknik, data- og AI-kompetence, sikkerhedsbevidsthed, produktorienteret tænkning og operationel dømmekraft. Jeg sætter også pris på udviklere, der arbejder i tvetydige miljøer, ræsonnerer ud fra første principper og validerer AI-output i stedet for blindt at acceptere det.

Modellen med kundetætte udviklingsteams er et godt eksempel. I stedet for at holde arkitektur, AI-udvikling, DevOps og sikkerhed i separate, sekventielle spor bringer vi disse kompetencer tættere på kundens eller virksomhedens miljø. Teamet arbejder med reel kode, reelle data, reelle begrænsninger og reelle succesmål.

Rekrutteringen har også ændret sig. Jeg lægger stadig stor vægt på teknisk dybde, men jeg søger også systemtænkere: personer, der forstår arkitektur, bruger AI ansvarligt, kommunikerer med interessenter i virksomheden og tager ejerskab for resultater i produktion. I AI-æraen er de bedste udviklere ikke bare kodeproducenter. De er problemformulerere, validatorer og skabere af systemer, der kan gentages.

Sådan måler du AI's effektivitet

Et spørgsmål, jeg ville ønske, at flere stillede, er: Hvordan bør CTO'er måle, om AI skaber varig forretningsværdi?

CTO'er bør ikke kun måle AI på antallet af implementerede pilotprojekter eller copiloter eller på modellens nøjagtighed isoleret set. Det er nyttige signaler, men de beviser ikke transformation.

CTO'er bør måle AI på tværs af fire dimensioner:

1. Produktivitet inden for softwareudvikling: Reducerer AI gennemløbstiden, forbedrer kodekvaliteten, øger testdækningen, fremskynder moderniseringen og reducerer teknisk gæld?
2. Forretningsmæssig effekt: Forbedrer AI kundeoplevelsen, medarbejdernes produktivitet, omsætningskonverteringen, omkostningseffektiviteten eller hastigheden, hvormed produkter kommer på markedet?
3. Produktionsmodenhed: Er AI-systemerne sikre, observerbare, pålidelige, underlagt styring og omkostningskontrollerede? Har de et tydeligt menneskeligt ansvar og klare kriterier for produktionsparathed?
4. Genanvendelighed og skalerbarhed: Bygger teams genanvendelige AI-tjenester, agenter, prompts, mønstre, dataprodukter og platformskapacitet, eller skaber de isolerede demoer?

Det er vigtigt, fordi AI kan skabe stor synlig aktivitet uden at skabe varig værdi. CTO'er skal omsætte AI-aktivitet til gentagelig kapacitet. Det betyder, at strategi, arkitektur, driftsmodel, styring og økonomi skal forbindes.

Hvorfor CTO'er skal adskille eksperimentering fra industrialisering

Her er mit råd.

For det første skal AI ikke behandles som et sideeksperiment. Betragt det som et nyt driftslag for virksomheden. AI vil påvirke, hvordan software udvikles, hvordan medarbejderne arbejder, hvordan kunderne interagerer, og hvordan beslutninger træffes. CTO'ens opgave er at flytte organisationen fra spredte pilotprojekter til en styret, skalerbar AI-platformstrategi.

For det andet skal eksperimentering adskilles fra industrialisering. Det er fint at eksperimentere hurtigt, men produktionsklar AI kræver en arkitektur, sikkerhed, datastyring, evaluering, observerbarhed, omkostningskontroller og et tydeligt menneskeligt ansvar. Mange virksomheder sidder fast, fordi de har mange demoer, men ingen gentagelig vej til produktion. CTO'er skal skabe denne vej.

For det tredje skal fokus være på forretningsværdi, ikke på modellens nyhedsværdi. De vindende organisationer bliver ikke dem, der blot bruger den nyeste model. Det bliver dem, der integrerer AI i reelle arbejdsgange, moderniserer deres teknologiske fundament, forbedrer produktiviteten inden for softwareudvikling og måler resultater som gennemløbstid, omkostningseffektivitet, kundeoplevelse, omsætningseffekt og risikoreduktion.

Og for det fjerde er mit praktiske råd at skabe en AI-platform og en model for fremadrettet implementering i teams på samme tid. Platformen giver genbrug, styring og skala. Modellen for fremadrettet implementering bringer AI ind i reelle kunde- og virksomhedsarbejdsbelastninger ved hjælp af virkelige data, virkelig kode og reelle begrænsninger. Det er sådan, CTO'er kan bevæge sig fra AI-ambition til realiseret investeringsafkast.

Følg med

Følg Saurabh Shrivastavas arbejde på LinkedIn og hans forfatterside på Amazon.

Der kommer flere ekspertinterviews på The CTO Club!