Skrevet av: Harald Aarvig

Den tekniske gjelden synes på bunnlinjen: høyere driftskostnader, lavere produktivitet og tap av nye inntektsmuligheter fordi systemene ikke henger med. De fleste vet at noe bør gjøres. Det har imidlertid vært mangel på fornuftige veier inn. I Avo har vi bygget en metode der AI leser den gamle koden og lager en komplett beskrivelse av hva systemet faktisk gjør. Ut fra den bygger vi en spesifikasjon av det nye systemet.

‍Derfor har omskriving vært så vanskelig

Å skrive om et kjernesystem er en stor beslutning. Kostnadene er høye, risikoen er reell og det er vanskelig å forsvare investeringen internt. Du ber om budsjett for å gjøre noe du allerede har. Selv om et omskrevet og modernisert system er bedre, må dette bevises i nytte-kostnadsanalyser. Alle som eier driftskostnadene vet imidlertid godt at alternativet, å la være å skrive om, er dyrt og holder bedriften tilbake.

Den første utfordringen har vært kartlegging. Forretningsreglene er gjemt i kode skrevet for ti eller tjue år siden, og bygget for andre arbeidsflyter en de som brukes i dag. Ingen har full oversikt over hva systemet faktisk gjør. Tradisjonell dokumentering gjennom intervjuer og manuell kodegjennomgang tar måneder og koster deretter.

Avos metode: fra gammel kode til ny spesifikasjon

Det siste året har AI blitt god nok til å lese og forstå store, gamle kodebaser. Det endrer økonomien i moderniseringsprosjekter, fordi kartleggingen har vært tidkrevende og kostbar. Det som tidligere tok måneder med kartlegging, tar nå uker.

Vi i Avo starter med å la AI lese seg gjennom hele kodebasen. Den identifiserer forretningsregler, avhengigheter og dataflyt, og produserer et utkast til ny funksjonell spesifikasjon. Utviklere og brukere beriker spesifikasjonen med sin innsikt. Det er denne spesifikasjonen som danner grunnlaget for det nye systemet. Spesifikasjonen oppdateres fortløpende gjennom prosjektet i dialog med utviklere og brukere.

Slik ser et prosjekt ut i praksis

Startpunktet er kildekoden. Vi kjører AI-analyse kombinert med workshops og brukerinnsikt, og kartlegger det tekniske landskapet rundt: integrasjoner, avhengigheter og rammer som ny arkitektur må passe inn i. Resultatet er en tredelt forståelse: hva systemet gjør i dag, hva det burde gjøre, og hva som mangler. Av dette bygges spesifikasjonen for det nye systemet.

Derfra bygger vi det nye systemet del for del, med spesifikasjonen som styringsdokument. Gammelt og nytt kjører ofte parallelt underveis, slik at overgangen skjer kontrollert og brukerne kan gi tilbakemeldinger løpende.

Erfaringen fra prosjektene våre viser det samme mønsteret:

• Typisk er 20-40% av koden død — den skal ikke videreføres, bare fjernes

• Nye krav og ønsker som har hopet seg opp, kan endelig tas inn i det nye systemet

• Vi bygger brukergrensesnittet på nytt for bedre brukervennlighet, mens forretningslogikken videreføres

• Vi rydder og oppdaterer datagrunnlaget som del av prosjektet

• Gammelt og nytt system kan kjøre parallelt, slik at overgangen skjer kontrollert

Underveis dukker det alltid opp ting: felter ingen bruker, duplikater i logikken, funksjonalitet som hører hjemme i andre systemer. Alt identifiseres og tas stilling til. Spesifikasjonen bygges opp på nytt.

I de fleste prosjekter lever gammelt og nytt system side om side en periode. Vi planlegger for det fra start, med gradvis overgang og mulighet for fallback. Erfaringen viser at overgangen til nytt system er like mye et endringsprosjekt som et teknisk prosjekt, og vi tar høyde for begge deler.

Effekten på bunnlinjen

Et modernisert system merkes på bunnlinjen. Her er de viktigste effektene:

• Lavere driftskostnader — ryddig kode og god dokumentasjon gjør at endringer koster mindre og går raskere

• Høyere produktivitet — ansatte sparer tid hver dag på bedre arbeidsflyter, og det merkes når du ganger opp på tvers av teamene

• Nye inntektsmuligheter — dere kan lansere nye produkter, koble på integrasjoner og justere prosesser uten kostbare omveier

• Bedre styring — oversikt over nøkkeltall, status og avvik i sanntid, på tvers av systemer

Med ryddig arkitektur og oppdatert dokumentasjon blir kontinuerlig videreutvikling en reell mulighet videre.

Realistiske forventninger

AI er ikke en magisk knapp. Den er et kraftig verktøy, men den trenger styring. Akkurat som en dyktig konsulent trenger en tydelig oppdragsbeskrivelse.

AI kan ikke skrive om et helt system automatisk. Det er for mange tolkninger og avveininger til å slippe teknologien løs uten kontroll.

Det som fungerer er å jobbe systematisk, del for del. Våre utviklere styrer prosessen, AI gjør grovarbeidet og spesifikasjonen oppdateres underveis. Effekten er at utviklingstiden typisk halveres, og at teamet bruker mer tid på å forstå behov og lage riktig løsning. Gode løsninger lages fortsatt av mennesker. AI er verktøyet som gjør det mulig å levere raskere og billigere.

Start med et forprosjekt — få beslutningsgrunnlaget på uker, ikke måneder

Den tekniske gjelden vokser. For hvert år du venter, øker kostnaden. Forskjellen nå er at terskelen for å gjøre noe med den er vesentlig lavere. Med vår metode får du en spesifikasjon av det nye systemet, med konkret estimat på tid og kostnad, etter et kort og intensivt forprosjekt.

Det nye systemet bygges på moderne arkitektur, klar for AI-integrasjon fra dag én. Du eier kildekoden og spesifikasjonen selv. Ingen leverandørlåsing.

De fleste vet at den tekniske gjelden må håndteres. Spørsmålet er når. Et forprosjekt gir deg beslutningsgrunnlaget, en konkret beskrivelse med tidsestimat og kostnad. Ta kontakt for en uforpliktende prat om mulige veier videre.