Julkisen sektorin palkanlaskenta- ja henkilöstöhallintoratkaisuja tuottavan Visma Aquilan ydinjärjestelmä oli 1990-luvun alusta asti rakentunut COBOL:in varaan. COBOL oli aikanaan luotettava ja laajasti käytetty teknologia, mutta vuosikymmenten aikana sen kehittäminen on muuttunut työlääksi. 

Visma Aquila käynnisti kolme vuotta sitten mittavan konversioprojektin, jossa COBOL-järjestelmä haluttiin kääntää tänä päivänä yleisemmälle Java-kielelle. Data- ja AI-ratkaisuja sekä ohjelmistokehitystä tarjoava teknologiayhtiö twoday kutsuttiin mukaan tähän mielenkiintoiseen caseen. twoday ja Reflector ovat tehneet pitkään yhteistyötä ja tätäkin asiakkaan tarvetta lähdettiin ratkomaan yhdessä. Reflectorilta mukana olivat Seme Hokynar ja Vesa Saarinen.

Miksi COBOL-järjestelmien modernisoinnilla on yrityksissä kiire?

COBOL-järjestelmä on ollut monessa firmassa vuosikymmeniä tärkeä tai jopa kriittinen osa liiketoimintaa. Teknologian kehittyessä ja monipuolistuessa sen kehittäminen on kuitenkin käynyt hitaaksi. COBOL ei enää taivu helposti nykyvaatimuksiin ja COBOL:ia hanskaavat asiantuntijatkin ovat siirtymässä yksi toisensa jälkeen eläkkeelle.

Tilannetta vaikeuttaa yrityksissä käytettävien eri järjestelmien laajuus ja kerroksellisuus: vuosien aikana yrityksissä väistämättä kertyy valtavasti koodia ja järjestelmiä, jotka on toteutettu eri aikoina, eri kielillä ja eri lähestymistavoilla sekä eri kumppaneiden kanssa.

Näin aloitat COBOL-konversion hallitusti

twoday ja Reflector astuivat Visma Aquilan projektiin ilman tarkkaa näkyvyyttä järjestelmän lukuisiin yksityiskohtiin. Haasteena oli yli miljoonan koodirivin sisältämä liiketoimintalogiikka. Eikä ollut myöskään varmuutta siitä, mitä liiketoimintasäännöille käy, jos ohjelmointikieli muutetaan Javaksi.

Projektin alkuvaiheessa COBOL-koodia konvertoitiin manuaalisesti. Kävi kuitenkin ilmi, että näin massiivista kokonaisuutta ei ollut mahdollista käsitellä ilman automaatiota: yhdellä kehittäjällä konversio olisi kestänyt vuosikymmeniä. 

Projektissa edettiin rakentamalla Proof of Concept -ratkaisu (POC), jolla selvitettiin, oliko konversio ylipäänsä mahdollinen. POC pureutui erityisesti asiakkaan omaan domain-spesifiseen ohjelmointikieleen (DSL), joka pohjautui COBOL-teknologiaan. POC osoitti, että työ oli tehtävissä, joskin vaiheittain.

Automaatio toi ryhtiä COBOL-konversioon

Seuraavaksi projektia edistettiin kehittämällä työkalun, joka tuotti COBOL-koodista Java-koodia. Ensimmäiset versiot eivät olleet täydellisiä, mutta ne antoivat kuitenkin selkeän rungon, jota pystyi jatkokehittämään. Automaation avulla koodin tyyli yhtenäistettiin, mikä oli keskeistä suuren kokonaisuuden hallinnassa. 

Konversiotyössä tunnistettiin monia rakenteellisia eroja COBOL:in ja Javan välillä. Esimerkiksi COBOL:in 88-tason muuttujat voivat tarkoittaa Boolean-arvoja, Enum-tyyppisiä rakenteita tai jopa Pattern Matching -logiikkaa. Näillä ei ole suoraa vastinetta Javassa.

Nykyisin tämä asiakkaalle räätälöity konvertointityökalu tuottaa lähes täydellistä koodia, jota asiakkaan omat kehittäjät voivat hyödyntää eteenpäin. COBOL-koodia ajetaan nyt työkalun läpi ja kehitystä jatketaan Java-alustalla, mikä oli myös alkuperäinen työn tavoite.

Miten luoda ylläpidettävä Java-ratkaisu COBOL:in pohjalta?

Migroitu Java-koodi on jatkokehityksen pohja. Sen tulee olla helposti ymmärrettävää ja ylläpidettävää. Visma Aquilan konversiotyökalun suunnittelussa keskeistä oli tuottaa sellaista koodia, jota kokenut kehittäjä voisi itse kirjoittaa: ei ainoastaan teknisesti toimivaa, vaan myös loogista ja laadukasta koodia.

Useat markkinoilla olevat automaattikonversiotyökalut tuottavat koodia, jota on käytännössä erittäin hankala ylläpitää. Täysin automaattinen konversio voi tuottaa koodia, joka on teknisesti oikein, mutta käytännössä se on sekavaa. Siksi työkalun täytyy sisältää älykkyyttä ja konversiota on aina tarkasteltava kehittäjän silmin. Varsinainen kehitystyö alkaakin vasta konversion jälkeen.

Lisäksi virheselvityksen vuoksi koodin rakenteen kannattaa aluksi muistuttaa alkuperäistä COBOL-koodia – näin virhetilanteet voidaan jatkossa paikantaa tehokkaammin.

Järjestelmämodernisoinnin riskit hallintaan vertikaalisiivuilla

Yksi keskeisistä projektin opeista on ollut konversiotyön pilkkominen ns. vertikaaleihin siivuihin: kokonaisia toiminnallisuuksia konvertoidaan ja viedään tuotantoon yksi kerrallaan. Näin ongelmat saadaan näkyviin ja ratkaistua ajoissa sen sijaan, että koko järjestelmä konvertoidaan ensin ja yritetään ottaa käyttöön vasta lopuksi.

Tämä lähestymistapa ei ainoastaan vähennä riskejä, vaan myös tuo näkyviä tuloksia liiketoiminnalle nopeammin.

Ajoympäristön vaikutus COBOL–Java -konversioon

Konversioprojekti ei koske vain koodia. COBOL:in ja Javan ajomallit eroavat merkittävästi toisistaan. COBOL-ympäristöt ajavat usein erillisiä prosesseja kutakin tehtävää varten, kun taas Java-sovellukset toimivat jatkuvasti käynnissä olevan JVM:n (Java Virtual Machine) päällä ja hyödyntävät sisäisiä säikeitä rinnakkaiseen suoritukseen.

Myös asiakkaan tekninen organisaatio pääsee oppimaan uutta. Mikäli Java on jo käytössä muualla organisaatiossa, tämä oppimiskäyrä on loivempi. Täysin uusi ympäristö vaatii kuitenkin kunnollista perehtymistä ja investointeja osaamisen kasvattamiseen.

Kokonaisuus on joskus lähes arkeologinen projekti

Konversioprojektissa nousee usein esiin paljon muutakin kuin COBOL-koodia: shell-skriptejä, konfiguraatiotiedostoja, tietokantatriggereitä ja muuta logiikkaa. Näitä ei voi jättää huomiotta, sillä ne vaikuttavat järjestelmän toimintaan ja koodin yhteen toimivuuteen.

Niinpä konversio on aina myös ympäristömuutoksen hallintaa ja usein myös arkeologinen projekti, jossa esiin kaivetaan vuosien saatossa unohtuneita rakenteita.

Legacy-järjestelmän riskejä, jos modernisointi viivästyy

Jos yritysten vanhoja järjestelmiä ei päivitetä, niiden ylläpito käy mahdottomaksi. Uusia vaatimuksia ei voida toteuttaa ja liiketoiminnan ketteryys katoaa. Vanhojen järjestelmien lisenssimaksut voivat nousta pilviin. Kehittäjät turhautuvat vanhoihin ympäristöihin ja loppukäyttäjien käyttökokemus heikkenee.

Modernit kehitysmallit mahdollistavat nopeamman reagoinnin, paremman tuen liiketoiminnalle ja pienemmät riskit. Kyse ei ole siis vain teknologiasta.

Mitä COBOL-konversioprojektista opittiin käytännössä?

twoday ja Reflectorilta Vesa Saarinen ovat olleet Visma Aquilan ja twodayn projektissa alusta asti. Kolmessa vuodessa on tullut vastaan lukematon määrä haasteita, joista suurin osa ei ole teknisiä, vaan ne liittyvät dokumentaatioon, testaukseen ja hiljaisen tiedon puutteeseen. 

Yksi tärkeimmistä opeista on ollut ymmärtää, että ilman määrittelyjä ja testitapauksia työ muuttuu hitaaksi virheselvitykseksi. Testitapaukset ovat välttämättömiä: jos niitä ei ole, niitä täytyy rakentaa. Ilman testitapauksia konversio ei voi onnistua hallitusti.

Toinen keskeinen riski on tietotaidon katoaminen. Jos viimeisetkin osaajat lähtevät talosta ennen kuin tiedot on dokumentoitu ja testitapaukset rakennettu, kehittäminen muuttuu käytännössä mahdottomaksi.