Lær at leve med Cobol-koden: It-kludetæpper kan være praktiske

Der er ganske givet mange it-chefer, der har en privat liste over gamle applikationer, som de helst ville sende på pension, så de kunne samle alt på én platform. Men det er ikke realistisk, og derfor bør man i stedet fokusere på at gøre det så let som muligt for sin organisation at leve med applikationer, der er spredt ud over mere eller mindre forældede platforme.

Det mener i hvert fald IBM distinguished engineer Hayden Lindsey fra IBM's Rational-division.

»I dag kører de applikationer, der driver din virksomhed, med komponenter, som kører på forskellige platforme. De består af forskellige stumper lavet med forskellige teknologier, men er en del af den samme applikation,« siger Hayden Lindsey til Version2.

Det kan eksempelvis være et system, som henter data fra en Cobol-applikation, som via en applikationsserver og webservices bliver tilgået som en webapplikation i en browser. Det giver udfordringer, når systemerne skal vedligeholdes.

»Du kan meget vel have mindst tre personer involveret fra tre interessegrupper. Hvis du skal lave opdateringer på tværs af platforme, så er du nødt til at gøre det manuelt, og det øger risikoen for, at folk begår fejl,« siger Hayden Lindsey.

Han arbejder blandt andet med Application Lifecycle Management hos IBM, som netop er det område, der handler om at kunne håndtere en applikation, der måske viser sig at blive brugt i produktionen i over 30 år.

Selvom det er muligt at konvertere 95 procent af koden i de fjerdegenerationssprog, der er brugt til at lave applikationer til mainframes, som er blevet oversat til Cobol i 1970'erne og 1980'erne, så er der stadig en manuel opgave med at få de sidste fem procent på plads.

»Migrering er en løsning, hvis du eksempelvis ikke længere kan finde medarbejdere med de nødvendige kompetencer, men det er et ret drastisk skridt. Der kører stadigvæk omkring 250 milliarder linjer Cobol-kode, så det er ikke realistisk at migrere det hele. Og Cobol-applikationerne gør det, de skal og yder som regel udmærket. Så du kunne omskrive det hele til Java, men hvad ville formålet være?« spørger Hayden Lindsey.

I stedet kan man ændre rammerne omkring applikationerne, hvor det blandt andet er vigtigt at få de forskellige hold, som er involveret i de forskellige platforme, til at arbejde sammen. Og så bør man ifølge Hayden Lindsey fokusere mere på at konsolidere værktøjerne, som udviklerne arbejder med, i stedet for sprogene.

»Det giver mere mening at ændre brugeroplevelsen med at vedligeholde applikationen, så den er den samme på tværs af forskellige platforme. Softwareudviklere ved udmærket godt, hvordan de lærer et nyt programmeringssprog, men prøv ikke at sætte en nyuddannet til at bruge en editor på en 'green screen', som var state-of-the-art for 30 år siden,« siger Hayden Lindsey med henvisning til det miljø, der stadig er standard i mange it-afdelinger, som arbejder med mainframe-applikationer.

Problemet er, at hver generation fra mainframen over klient-server til serviceorienteret arkitektur har udviklet sine egne værktøjer, og det er ikke alle platformene, der er lige parate til de nye udfordringer, der opstår, når applikationerne eksempelvis pludselig skal tilgås via web.

»Man skal sørge for at lavede samlede test på hele applikationen og ikke kun teste Java-delen for sig og Cobol-delen for sig. Og så skal man sørge for at finde sikkerhedshullerne i Cobol-koden. Kunderne begynder at blotte nogle interne applikationer via webservices, og så er der pludselig risiko for, at sårbarhederne bliver synlige,« siger Hayden Lindsey.

Hans overordnede råd til it-afdelinger, der har systemer bestående af komponenter spredt over mange platforme, er at få menneskene bag systemerne til at samarbejde uafhængigt af deres forskellige platforme.

»Det gælder om at få holdene samlet. Vi har fået splittet udviklermiljøerne, fordi hver generation ville opfinde nye værktøjer, fordi vi troede, vi havde opfundet noget nyt, så hver platform har sine egne værktøjer,« siger Hayden Lindsey.