Når kompleksitet blir en belastning: enterprise-produkter i en tid med AI-agenter

Enterprise-systemer blir ikke irrelevante fordi AI-agenter blir mer kapable. Mange av dem finnes av gode grunner: sikkerhet, sporbarhet, regulatoriske krav, transaksjonskontroll, integrasjon, stabilitet og operasjonell robusthet.

Enterprise-systemer blir ikke irrelevante fordi AI-agenter blir mer kapable. Mange av dem finnes av gode grunner: sikkerhet, sporbarhet, regulatoriske krav, transaksjonskontroll, integrasjon, stabilitet og operasjonell robusthet.

Men ikke all kompleksitet er verdifull.

Noe kompleksitet beskytter virksomheten. Noe kompleksitet gjør virksomheten tregere, dyrere og mer avhengig av enkeltpersoner, leverandører eller historiske beslutninger ingen lenger kan forklare.

Det er denne forskjellen AI-agenter gjør mer synlig.

Kompleksitet må kunne forklares

I mange år ble kompleksitet i enterprise-programvare nesten akseptert som en naturlig del av å drive store og kritiske systemlandskap. Lange implementeringsløp, spesialistkompetanse, leverandørspesifikk konfigurasjon, opplæring, integrasjonsarbeid og tunge driftsmodeller ble ofte sett på som prisen for skala, kontroll og pålitelighet.

Den logikken holder fortsatt delvis.

Virksomheter trenger systemer som kan håndtere ansvar, kontroll og risiko. ERP-systemer, dataplattformer, identitetsløsninger, finanssystemer, helsesystemer, energisystemer og offentlig infrastruktur kan ikke bare erstattes av enkle verktøy eller autonome agenter uten betydelig risiko.

Men AI endrer terskelen for hva som kan forsvares.

Når arbeidsflyter kan automatiseres, dokumentasjon kan søkes i intelligent, kode kan genereres raskere, tester kan støttes av AI og kunnskap kan gjøres mer tilgjengelig, blir skjult kompleksitet vanskeligere å forklare.

Spørsmålet blir derfor ikke om enterprise-systemer er komplekse.

Spørsmålet blir:

Er kompleksiteten nødvendig for virksomheten — eller er den et resultat av historiske valg, skjult logikk og svak arkitektur?

Verdifull og tilfeldig kompleksitet

Verdifull kompleksitet støtter virksomhetens behov for:

• etterlevelse;
• sikkerhet;
• sporbarhet;
• revisjon;
• datakvalitet;
• operasjonell robusthet;
• tilgangskontroll;
• tydelig ansvar.

Dette er kompleksitet som har en forretningsmessig begrunnelse.

Tilfeldig kompleksitet ser annerledes ut. Den viser seg ofte som skjulte forretningsregler, udokumenterte skript, skjøre integrasjoner, manuelle overleveringer, lokale workarounds, overlappende verktøy, uklart eierskap og systemer som bare én eller to personer virkelig forstår.

I en stabil leveransemodell kan dette være dyrt, men håndterbart.

I en AI-akselerert leveransemodell blir det en strategisk risiko.

Et system som er modulært, dokumentert, API-tilgjengelig og semantisk tydelig, blir enklere å automatisere, teste, forklare og videreutvikle.

Et system som bygger på taus kunnskap, skjulte avhengigheter og utydelige datamodeller, blir vanskeligere både for mennesker og AI-agenter å arbeide med.

Fra systemer brukere navigerer i, til systemer som utfører arbeid

Tradisjonelle enterprise-applikasjoner er ofte bygget rundt brukergrensesnitt: mennesker logger inn, søker, tolker, navigerer, registrerer og følger opp.

AI-agenter flytter oppmerksomheten fra grensesnitt til resultat.

Verdien ligger ikke lenger bare i å gi brukeren et verktøy. Den ligger i å hjelpe virksomheten med å fullføre en oppgave trygt, raskere og med mindre friksjon.

Det betyr ikke at systemer of record forsvinner. Tvert imot blir de fortsatt kritiske. Men flere arbeidsflyter rundt dem kan bli mer automatiserte, mer orkestrerte og mer agent-støttede.

Da må arkitekturen tåle det.

AI-agenter trenger ikke bare data. De trenger kontekst, tilgangsstyring, logging, kontroller, godkjenningspunkter, testbarhet, eierskap, metadata, lineage og tydelige grensesnitt.

Med andre ord: AI reduserer ikke behovet for arkitektur. Det øker behovet for god arkitektur.

Det nye arkitekturspørsmålet

Virksomheter bør derfor ikke bare spørre:

Hvilken plattform skal vi kjøpe?

De bør også spørre:

Hvilke deler av systemlandskapet må forbli stabile systemer of record, og hvilke deler bør utvikles til AI-støttede systemer of action?

Dette er et arkitekturspørsmål, ikke et hype-spørsmål.

Mange AI-initiativer stopper ikke fordi teknologien er for svak, men fordi virksomheten mangler grunnlaget for å skalere: felles dataforståelse, tydelig eierskap, standarder, styring, integrasjon, prosessforståelse og gjenbrukbare tekniske byggeklosser.

AI-agenter kan bare fungere trygt i et landskap der virksomheten forstår sine egne prosesser, data og avhengigheter.

Hva virksomheter bør vurdere nå

Før man kjøper enda en plattform, starter enda et AI-initiativ eller erstatter enda et system, bør ledere og arkitekter stille noen grunnleggende spørsmål:

• Hvilken kompleksitet i dagens landskap skaper faktisk forretningsverdi?
• Hvilken kompleksitet skaper bare avhengighet, friksjon og kostnad?
• Hvor er vi avhengige av taus kunnskap hos enkeltpersoner eller leverandører?
• Kan en ny medarbeider, et nytt team eller en AI-agent forstå systemet gjennom dokumentasjon, metadata, API-er og tester?
• Hvilke systemer er kritiske systemer of record?
• Hvilke løsninger fungerer mest som arbeidsflyt- eller grensesnittlag?
• Hvor har vi overlappende verktøy, utydelige datamodeller eller uklart eierskap?
• Har vi data, prosesser og kontroller som er klare for agent-støttet arbeid?
• Kan vi forklare hvorfor arkitekturen er kompleks — i forretningsspråk?

Det siste spørsmålet er ofte det viktigste.

Hvis kompleksiteten ikke kan forklares, styres eller måles mot verdi, vil den bli vanskeligere å forsvare.

Hva arkitekter bør gjøre

Den praktiske responsen er ikke nødvendigvis et stort utskiftingsprogram.

Det første steget bør være en arkitektonisk vurdering av kompleksitet.

1. Gjennomfør en kompleksitetsanalyse

Vurder systemer langs noen sentrale dimensjoner:

• forretningskritikalitet;
• total kostnad;
• kunnskapsoverføring;
• grad av tilpasning;
• integrasjons- og API-modenhet;
• AI- og automatiseringsklarhet.

Målet er ikke å kritisere komplekse systemer. Målet er å skille verdifull kompleksitet fra tilfeldig kompleksitet.

2. Bygg et agent-klart arkitekturlag

Før virksomheten tar i bruk mange AI-agenter, bør grunnlaget være på plass:

• tydelige API-er;
• styrte dataprodukter;
• metadata og lineage;
• identitets- og tilgangsstyring;
• logging og revisjonsspor;
• testautomatisering;
• arbeidsflytorkestrering;
• human-in-the-loop-kontroller.

Dette er klassisk enterprise- og dataarkitektur, men med ny aktualitet.

3. Behandle legacy-systemer som kunnskapsaktiva

Legacy-systemer er ikke bare teknisk gjeld. De kan også inneholde tiår med forretningsregler, prosesslogikk, unntak og operasjonell erfaring.

Før man erstatter dem, bør man hente ut og dokumentere:

• forretningsregler;
• datamodeller;
• prosesslogikk;
• integrasjoner;
• unntak;
• operasjonelle avhengigheter;
• eierskap og ansvar.

Deretter kan man vurdere om systemet bør moderniseres, forenkles, pakkes inn, erstattes eller eksponeres gjennom API-er.

Konklusjon: kompleksitet må bli bevisst

Fremtidens enterprise-programvare vil ikke bli definert av et enkelt valg mellom store plattformer og lette verktøy.

Den vil bli definert av evnen til å gjøre kompleksitet bevisst.

Enterprise-produkter vil fortsatt være nødvendige der de gir tillit, robusthet, etterlevelse, styring og skala. Men de vil bli utfordret der de først og fremst skaper avhengighet, skjult logikk, treg endring, manuell koordinering og dyr kunnskapsoverføring.

De sterkeste plattformene vil ikke nødvendigvis være de enkleste.

De vil være de der kompleksiteten er eksplisitt, styrt, modulær, observerbar og forståelig — for mennesker, team og AI-agenter.

Enterprise-programvare er ikke i fare fordi den er kompleks.

Den er i fare når kompleksiteten ikke lenger kan forklares, styres eller forsvares.

English version: When Complexity Becomes a Liability: Enterprise Products in the Age of AI Agents