COBOL på IBM-stormaskiner: en kritisk arv i AI-alderen

Forholdet mellom COBOL, IBMs stormaskiner og den nye bølgen av generativ AI opplever en av sine mest intense perioder på flere tiår. Et språk som ble laget på slutten av 1950-tallet, og som kjører på maskiner som mange anser som «fra en annen tid», har plutselig havnet i sentrum av teknologisk og aksjemarkedsdebatt takket være ett helt spesifikt ord: modernisering.

I de siste ukene har Anthropics kunngjøring av Claude Code og selskapets evner til å oversette og analysere COBOL-systemer forårsaket en skikkelig omveltning i markedet, med IBMs aksjekurs som stupte med millioner og fornyet interesse for å forstå hvilken rolle disse eldre systemene fortsatt spiller. For alle som jobber innen teknologi – fra gründere av oppstartsbedrifter til IT-ledere i bank eller offentlig sektor – er det som skjer med COBOL på IBMs stormaskiner en casestudie av hvordan historien til databehandling, kritisk infrastruktur og omveltningen av AI møtes.

Fra CODASYL til COBOL 2023: hvordan et «midlertidig» språk ble uunnværlig

Da Conference on Data Systems Languages ​​(CODASYL) ble dannet i 1959 , var det få som forestilte seg at språket de utviklet fortsatt ville være i produksjon mer enn seksti år senere. Denne gruppen, bestående av offentlige etater og store selskaper, forfulgte et veldig spesifikt mål: å lage et felles programmeringsspråk, fokusert på forretningsdatahåndtering og bærbart på tvers av forskjellige systemer.

COBOL arvet ideer fra FLOW-MATIC, språket utviklet av pioneren Grace Hopper , og var en del av et initiativ fra det amerikanske forsvarsdepartementet. Målet var klart: å ha et språk som kunne kjøre på forskjellige operativsystemer og maskinvareplattformer, noe som kan høres trivielt ut i dag, men som den gang nesten var science fiction. Portabilitet mellom miljøer som Linux, Windows, Unix og senere z/OS ble en av hjørnesteinene i den utbredte bruken.

Den første offisielle COBOL-spesifikasjonen ble publisert i 1960 , og i teorien ble den tenkt som en midlertidig løsning mens mer avanserte alternativer dukket opp. Forsvarsdepartementet innså imidlertid raskt dens praktiske nytteverdi for forretningsapplikasjoner og tok et avgjørende skritt: å kreve at datamaskinprodusenter tilbyr COBOL-støtte på maskinene sine. Dette politiske og tekniske trekket var nøkkelen til at IBM og andre leverandører integrerte den i sine stormaskinplattformer.

Gjennom årene ble språket mer etablert, og i 1968 ble en viktig milepæl nådd: den offisielle standardiseringen av COBOL . Fra det øyeblikket av ble det utgitt flere revisjoner og varianter – COBOL-61, COBOL-68, COBOL-74 og COBOL-85 – som forbedret syntaksen, datahåndteringen og tilpasset språket til nye forretningsbehov, men uten å bryte kompatibiliteten med de enorme kodebasene som allerede var distribuert på stormaskiner.

I det 21. århundre forsøkte COBOL 2002-standarden å gjøre et betydelig sprang fremover ved å introdusere objektorienterte funksjoner og andre moderne paradigmer , med ideen om at applikasjoner kunne integreres bedre i nåværende utviklingspraksis. Denne versjonen møtte imidlertid på et svært menneskelig problem: mangel på reell støtte og lav etterspørsel fra brukere , som ikke tydelig så fordelen med å ta i bruk de nye funksjonene sammenlignet med kostnadene ved å oppdatere stabile systemer.

De siste revisjonene av standarden har fortsatt å presse språket mot moderne interoperabilitet. COBOL 14 erstattet de gamle bærbare aritmetiske resultatene med IEEE 754-baserte datatyper , i samsvar med allment aksepterte industristandarder. Og den nyeste standarden, COBOL 2023 , fokuserer på å forbedre hvordan COBOL kan samhandle med andre nåværende systemer, språk og plattformer, og forsterker dens rolle i miljøer der tradisjonelle og skybaserte arkitekturer sameksisterer.

COBOL på IBM-stormaskiner: et udødelig språk i hjertet av økonomien

Til tross for alderen er COBOL fortsatt den «skjulte motoren» i mye av verdens finansielle og administrative infrastruktur . Ulike estimater indikerer at den håndterer rundt 95 % av minibanktransaksjoner i USA, og det er hundrevis av milliarder linjer med COBOL-kode i produksjon, mange av dem kjører på IBM-stormaskiner.

Suksessen med denne kombinasjonen er ingen tilfeldighet. COBOL ble spesielt utviklet for forretningsdatabehandling , med prioritering av instruksjonslesbarhet og håndtering av store transaksjonsvolumer. Dette er nettopp den typen arbeidsmengde som passer perfekt til IBM Z-stormaskiner , designet for å behandle millioner av operasjoner per sekund med ekstrem pålitelighet.

Innen sektorer som bank, forsikring, flyselskaper og offentlig sektor har denne COBOL + IBM-stormaskinkombinasjonen bevist sin robusthet i flere tiår. Det anslås at IBM-stormaskiner behandler omtrent 87 % av kredittkorttransaksjoner globalt og håndterer rundt 8 billioner dollar i daglige betalinger . Vi snakker ikke om marginale systemer, men snarere den sanne ryggraden i den digitale økonomien.

Problemet er imidlertid ikke at COBOL er teknisk sett mangelfullt . Tvert imot: det fungerer, og det fungerer veldig bra. Hovedproblemet er generasjonsmessig. De fleste som utviklet og vedlikeholdt disse systemene i flere tiår har pensjonert seg eller er i ferd med å bli det , og universiteter har ikke tilbudt systematisk opplæring i dette språket på lenge. Som Anthropic selv erkjente, er det hvert år færre fagfolk som er i stand til å lese og forstå disse programmene flytende.

Dette gapet mellom teknologisk avhengighet og tilgjengeligheten av talent har drevet opp vedlikeholdskostnadene. Mangelen på erfarne COBOL-utviklere gjør ethvert oppgraderings- eller endringsprosjekt til et langvarig og dyrt foretak, noe som gir næring til en «teknisk gjeld» som ikke lenger bare er et ingeniørproblem, men en strategisk risiko for stabiliteten i finansielle og offentlige forvaltningssystemer.

IBM er godt klar over denne situasjonen, og langt fra å forbli stillestående, har de utvidet sitt økosystem av COBOL-kompilatorer og -verktøy . I dag er IBMs COBOL-kompilatorer kompatible ikke bare med z/OS, men også med AIX og Linux , slik at applikasjoner kan kjøres og utvikles i et bredere spekter av miljøer uten å forlate eldre systemer. Videre har selskapet lansert opplæringsprogrammer og læringsløyper som kan overstige 250 timer og inkluderer COBOL, Java, Python, CICS, IMS, DevOps, analyse og webutvikling, blant andre emner, nettopp for å lette generasjonsovergangen.

Fra oversettelse til transformasjon: hvorfor COBOL-modernisering er mye mer enn å bytte til Java

Anthropics kunngjøring om Claude Code og dens evne til å «modernisere» COBOL har avslørt en tilbakevendende misforståelse: ideen om at det å bare oversette kode fra ett språk til et annet er nok til å modernisere et kritisk system. Denne overforenklingen, gjentatt i overskrifter og forum, har vært en av faktorene som har bidratt til markedets skarpe tilbakeslag mot IBM.

Det verktøy som Claude Code lover er veldig konkret: lesing av massive COBOL-kodebaser, kartlegging av inngangspunkter, utførelsesbaner, dataflyter og avhengigheter , og derfra generering av dokumentasjon og forslag til oversettelser til moderne språk som Java eller Python. Det er til stor hjelp for å bryte ned den «svarte boksen» som mange organisasjoner har i sine eldre systemer, men det er langt fra en komplett løsning.

Stormaskiner som kjører COBOL er ikke bare millioner av linjer med gammel kode . De er et resultat av flere tiår med justeringer, oppdateringer, integrasjoner med andre systemer, optimaliseringer tett knyttet til maskinvaren og forretningsprosesser som har utviklet seg i samme tempo som regelverket. Å bare oversette instruksjoner fra ett språk til et annet løser ikke i seg selv denne arkitektoniske kompleksiteten.

En primær utfordring er den monolittiske arkitekturen som disse applikasjonene vanligvis er bygget på . De fleste COBOL-programmer ble designet for en verden av batchprosesser og sentraliserte transaksjoner, langt unna konsepter som mikrotjenester, skybaserte arkitekturer eller kontinuerlige distribusjoner. Å forvente at linje-for-linje automatisk oversettelse vil generere et "moderne" system er å ignorere det faktum at arkitekturen og datamodellen forblir den samme.

En annen alvorlig hindring er skjulte og udokumenterte avhengigheter . I løpet av flere tiår har mange systemer raskt tilpasset seg, og integrert filer, køer, jobber og tjenester fra andre områder uten omfattende dokumentasjon. Et oversettelsesverktøy kan konvertere COBOL-instruksjoner til Java , men det vil ikke nødvendigvis avsløre hvilke andre applikasjoner som er avhengige av den modulen eller hvilke tjenestenivåavtaler hver prosess krever.

I tillegg er mye av forretningslogikken innebygd i koden på svært spesifikke måter . Skatteregler, detaljer om bankprodukter, regulatoriske unntak – alt dette ligger i COBOL-setninger som noen ganger bare forstås av de som opprinnelig skrev dem. Modernisering uten å miste noe av denne logikken innebærer å tolke og validere hva hver modul gjør , noe som foreløpig fortsatt krever ekspert menneskelig tilsyn.

Til slutt er det spørsmålet om ytelse og optimalisering som er iboende i stormaskiner . Disse maskinene er designet for å håndtere enorme transaksjonsvolumer med minimal latens og ekstremt høy pålitelighet. Å replikere denne oppførselen i x86-serverbasert infrastruktur eller i skyen er ikke så enkelt som å "flytte" koden; det krever vanligvis å redesigne hele systemet, justere databaser, meldingskøer, mekanismer for katastrofegjenoppretting og mye mer.

Den sanne kostnaden ved modernisering: avkastning, risikoer og aksjemarkedspanikken rundt IBM

Markedsreaksjonen på nyheten om Claude Codo har vært like slående som den har vært sigende. IBM-aksjene falt med rundt 13 % på én dag , den verste børsøkningen siden 2000, og selskapets markedsverdi krympet med omtrent 30–40 milliarder dollar i løpet av få timer . For februar måned hadde aksjen falt med nesten 27 %, noe som peker mot den verste måneden på flere tiår.

Dette fallet kan ikke forstås utelukkende som en teknisk svingning. Investorer reviderer modellene sine for hvordan kunstig intelligens kan forstyrre etablerte virksomheter , spesielt de som er basert på arbeidsintensive tjenester, som rådgivning om modernisering av eldre systemer. Enkelt sagt, hvis AI kan oversette COBOL «raskt og billig», kan en betydelig del av IBMs inntekter knyttet til stormaskiner og tjenester være i fare.

Når tallene og forretningsstrukturen analyseres, er imidlertid bildet mer nyansert. I et nylig år rapporterte IBM en totalinntekt på rundt 67.500 milliarder dollar . Av dette tallet kommer omtrent 45 % fra programvare, og resten er fordelt mellom konsulentvirksomhet og infrastruktur . Innenfor sistnevnte ligger IBM Z-stormaskinvirksomheten, nært knyttet til COBOL-applikasjoner. Ulike analyser anslår at rundt 20 % av IBMs inntekter, sannsynligvis med en enda større innvirkning på fortjenesten, avhenger av stormaskiner og COBOL-relaterte miljøer.

Når det kommer til stykket, er moderniseringsbeslutninger ikke utelukkende basert på tekniske muligheter, men også på avkastning på investeringen (ROI) . Migrering av et kritisk system skrevet i COBOL innebærer betydelige direkte utgifter: kodeoversettelse eller omskriving, omfattende testing, opplæring av team i nye teknologier, utrulling av ny infrastruktur og potensielle tilleggslisenser. Og det er uten å ta hensyn til alternativkostnader og risikoer : tapt tid på utvikling av nye funksjoner, tjenesteavbrudd, feil introdusert i systemer som for øyeblikket fungerer uten større hendelser, og tap av institusjonell kunnskap under overgangen.

I sterkt regulerte sektorer som bank, forsikring og offentlig forvaltning konkluderer mange organisasjoner med at det å fortsette å drifte og optimalisere sine eksisterende COBOL-systemer, støttet av IBM-stormaskiner, gir en mer forutsigbar avkastning enn en fullstendig migrering. AI-verktøy kan endre kostnadsligningen, men de eliminerer ikke behovet for å nøye vurdere virkningen på den daglige driften.

I mellomtiden opplever markedet det noen har kalt «SaaSpocalypse» : en bølge av aksjemarkedskorrigeringer i programvare-som-en-tjeneste-selskaper (Salesforce, SAP, Microsoft, Adobe, Intuit, Atlassian, blant andre), drevet av frykt for at AI kan kannibalisere forretningsmodeller som en gang virket urørlige . IBM- og COBOL-fiaskoen er bare et nytt kapittel i den samme historien: frykten for at AI vil automatisere oppgaver som tidligere rettferdiggjorde kontrakter med høy margin.

Claude Code, IBM og det nye AI-assisterte moderniseringsøkosystemet

Innenfor denne nervøse konteksten er det avgjørende å forstå nøyaktig hva Claude Code gjør og hvordan det passer inn i landskapet av moderniseringsverktøy . Anthropic har presentert løsningen sin som et system som er i stand til å lese komplette COBOL-prosjekter, identifisere inngangspunkter, spore utførelsesbaner og oppdage implisitte koblinger i datastrukturer og filoperasjoner som mange tradisjonelle statiske analyseverktøy overser.

Når denne kartleggingen er fullført, kan Claude Code generere detaljert dokumentasjon av arbeidsflyter som tidligere bare eksisterte «kodet» i selve programmet , samt gi en risikovurdering som skiller mellom moduler som er relativt enkle å migrere og mer komplekse. Forretningsløftet er overbevisende: å redusere prosjekter som pleide å vare i årevis til et spørsmål om kvartaler , i hvert fall når det gjelder analyse, dokumentasjon og noe av refaktoreringen.

Det er viktig å merke seg at Anthropic selv erkjenner behovet for ekspert menneskelig tilsyn . AI kan automatisere mye av det kjedelige arbeidet, men i kritiske systemer – spesielt økonomiske systemer – kan man ikke klare seg uten personer som er ansvarlige for å validere hver endring . Claudes rolle ville i så måte være en svært dyktig assistent, ikke en fullstendig erstatning for moderniseringsteamet.

Anthropic er ikke alene om å gå inn i denne arenaen. Markedet for migrerings- og moderniseringsverktøy har utviklet seg i årevis. AWS Mainframe Modernization tilbyr både refaktorering og replatforming; Microsoft Azure Mainframe Migration inkluderer verktøy for analyse og automatisert migrering; og selskaper som Micro Focus lar deg kjøre COBOL i moderne miljøer uten full kodeoversettelse, noe som forlenger levetiden til eldre applikasjoner.

Hovedforskjellen er at språkmodeller (LLM-er) som Claude muliggjør en dypere, mer kontekstuell forståelse av kode , generering av dokumentasjon, automatiserte tester og designforslag i en hastighet som tidligere var utenkelig. Utover oversettelse blir verktøy for automatisert dokumentasjon, avhengighetsanalyse, AI-drevet regresjonstesting og arkitekturassistenter stadig mer vanlige , og hjelper med å bestemme hva som skal migreres, når og hvordan.

Paradoksalt nok er IBM ikke fremmed for denne bevegelsen . For flere år siden introduserte selskapet sin egen tilnærming til å omskrive COBOL til Java ved hjelp av AI, med produkter som Watsonx Code Assistant for Z. Faktisk fremhevet IBMs administrerende direktør i nylige resultater at deler av stormaskindivisjonens sterke ytelse nettopp skyldtes kodekonverteringsverktøy og etterspørselen etter kontrollert modernisering fra store kunder.

Videre annonserte IBM og Anthropic tidligere en strategisk allianse for å integrere Claude-modeller i IBMs bedriftsøkosystem , inkludert AI-assisterte utviklingsmiljøer som rapporterte produktivitetsøkninger på opptil 45 % for de første brukerne. Det som opprinnelig ble presentert som synergi, blir nå omtolket, i hvert fall fra et aksjemarkedsperspektiv, som potensiell direkte konkurranse i visse segmenter av tjenestevirksomheten.

Uansett er nøkkelen å forstå at ingen enkeltstående AI-løsning kan løse alle aspekter ved en COBOL-migrering : prosjekter som adresserer den massive flyttingen av historiske data, utskifting av mellomvare, rekonstruksjon av integrasjoner, gjenoppbygging av katastrofegjenopprettingsprosesser og tilpasning av driftsprosedyrer er fortsatt nødvendige. Det er her IBM fortsatt har enorm innflytelse takket være sin erfaring, sine tilbud om bedriftsstøtte og sin posisjon i regulerte sektorer.

Hvorfor IBM fortsatt er en strategisk aktør til tross for aksjemarkedets straff

Den kraftige nedgangen i IBMs aksjekurs har fått mange til å lure på om æraen med IBMs stormaskiner nærmer seg slutten . Men hvis vi ser forbi den kortsiktige støyen, er det flere faktorer som forklarer hvorfor teknologigiganten opprettholder en posisjon som er vanskelig å gjenskape, selv i en verden dominert av AI.

For det første er det relevansen av stormaskininfrastrukturen for den virkelige økonomien . Det faktum at en betydelig andel av daglige kredittkorttransaksjoner og storskala betalinger går gjennom IBM Z-plattformer er ingen liten sak. Organisasjoner som håndterer denne typen operasjoner verdsetter pålitelighet, sikkerhet, prosessorkraft og støtte med svært strenge servicenivåavtaler over nesten alt annet . Et løfte om kodeoversettelse er ikke nok: driftskontinuitet, revisjon og samsvar med regelverk må garanteres.

For det andre tilbyr IBM supportkontrakter og bedriftsgarantier som er kritiske for banker, forsikringsselskaper og offentlige etater. Hvis noe går galt i et system som håndterer milliarder av euro om dagen, må noen ta ansvar og handle raskt. IBMs kombinasjon av maskinvare, programvare og spesialiserte tjenester er en pakke som er vanskelig for nye leverandører å matche, uansett hvor avanserte AI-verktøyene deres måtte være.

Vi må også vurdere økosystemet av verktøy som er bygget rundt stormaskinen over flere tiår : overvåkingsløsninger, sikkerhet, ytelsesoptimalisering, endringshåndtering, integrasjon med andre miljøer ... Alt dette danner en «vollgrav» som ikke demonteres bare ved at et godt kodeanalyseverktøy dukker opp.

Selv om mangelen på COBOL-talenter er et reelt problem, har IBM investert i opplæringsprogrammer og verktøy som gjør stormaskinmiljøet mer tilgjengelig for nye generasjoner . Læringsløyper som kombinerer COBOL med Java, Python, smidige metoder, DevOps og dataanalyse har som mål å forhindre at eldre systemer blir isolert fra resten av teknologistakken.

Til slutt peker mange analytikere på et nesten ironisk aspekt: ​​hvis COBOL ender opp med å bli erstattet i massevis, kan IBM tjene enda mer penger ved å bidra til å gjennomføre og orkestrere denne overgangen , enten det er på egne stormaskiner, i hybridskyer eller i kombinasjoner av begge deler. Med andre ord kan virksomheten gå fra rent vedlikehold av eldre systemer til moderniserings- og migreringstjenester med høy verdiøkning , et område der selskapet allerede har en svært sterk tilstedeværelse.

Smart modernisering for gründere og tekniske ledere: strategier og lærdommer

All denne støyen rundt COBOL, IBM og AI tilbyr flere nyttige lærdommer for oppstartsgründere og produkt- eller teknologiledere som står overfor moderniseringsdilemmaer – selv om de ikke har en stormaskin i livene sine.

For å begynne med er det viktig å skille tydelig mellom trinnvis forbedring og total transformasjon . AI-verktøy som Claude Code, Watsonx Code Assistant og andre kan gi enorm verdi i oppgaver som refaktorering, dokumentasjon, avhengighetsanalyse og testgenerering. Dette er ikke det samme som å fullstendig omskrive en plattform og endre den underliggende arkitekturen . Før man starter et stort prosjekt, er det avgjørende å definere om målet er å forbedre vedlikeholdbarheten, redusere infrastrukturkostnader eller muliggjøre helt nye funksjoner.

Et annet kritisk punkt er å beregne alternativkostnaden . Timer brukt på å migrere et system som fungerer akseptabelt, er timer som ikke brukes på å lansere nye produkter, forbedre brukeropplevelsen eller utforske nye markeder. Spørsmål som «Gir denne migreringen ytterligere inntekter?», «Rettferdiggjør besparelsene risikoen?» eller «Er det en reell fare for foreldelse som kan senke virksomheten?» bør stilles før man blir revet med i trenden.

Videre er det tilrådelig å utforske hybridstrategier i stedet for «alt-eller-ingenting»-tilnærminger . Mange vellykkede organisasjoner har valgt det såkalte strangler-mønsteret , der funksjonalitet gradvis erstattes mens det eldre systemet forblir i drift. Andre har foretrukket å pakke eldre systemer inn bak moderne API-er , slik at kjernen i COBOL forblir stabil mens front-end og tilhørende tjenester oppdateres. Selektiv modernisering er også vanlig , der innsatsen fokuseres på modulene som gir mest verdi eller bærer mest risiko.

Til slutt er det en faktor som ofte undervurderes: domenekunnskapen som er innebygd i eldre kode . I mange tilfeller inneholder COBOL-linjer forretningsregler, unntak og scenarier som ikke lenger finnes i noen formell dokumentasjon. Å bevare og forstå denne kunnskapen er like viktig som teknologien som implementerer den. AI kan bidra til å trekke ut og organisere den, men det er viktig å ha folk som kan validere og kontekstualisere resultatene.

Nyere utvikling viser at AI vil være en formidabel alliert i modernisering av kritiske systemer , akselerering av analyse av store kodebaser, forbedring av dokumentasjon, generering av testpakker og levering av konsekvensmodeller for arkitekturendringer. Imidlertid er det fortsatt langt fra å være i stand til å håndtere komplekse prosesser på egenhånd, som å migrere historiske data, redesigne integrasjoner, oppfylle strenge regulatoriske krav eller omdefinere hele forretningsdriften.

Det som skjedde med IBM, COBOL og Claude Code tjener som en påminnelse om at stabilitet i teknologi alltid er relativt . En godt utformet kunngjøring kan utslette titalls milliarder dollar i markedsverdi på én dag hvis markedet tolker den som en løsning på et problem som har vedvart i flere tiår. Samtidig er tekniske og operasjonelle realiteter ofte mer gjenstridige: kritisk infrastruktur utvikler seg sakte, og de som best forstår dens komplikasjoner er best posisjonert til å lede overgangen.

Hele denne situasjonen gjør én grunnleggende idé klar: eldre systemer eksisterer ikke på grunn av treghet eller latskap, men fordi de har vist seg å være en ekstremt pålitelig måte å løse svært komplekse problemer på . Debatten bør ikke fokusere på hvorvidt man skal oversette COBOL-kode eller ikke, men på når modernisering er verdt det, hvilke deler som er fornuftige å transformere, og hvordan man kan kombinere det som allerede fungerer med de nye mulighetene som AI bringer . I denne balansen vil IBMs stormaskiner, COBOL og nye verktøy for kunstig intelligens fortsette å sameksistere i mange år fremover.