Monoliitistä polyliittiin – miksi IT-järjestelmät rakennetaan paloista?

Kun yhdestä kivestä hakattua IT-järjestelmää halutaan muokata tai kehittää, se on yleensä ongelmallista ja kallista.

Monoliitti-termi on peräisin geologiasta ja sillä viitataan vuoreen, joka koostuu kokonaisuudessaan yhdestä kivestä. IT-maailmaan termi on lainattu kuvanveistosta ja arkkitehtuurista. Kun ihminen tekee yhdestä kivestä kokonaisen teoksen, olipa se sitten taidetta, arkkitehtuuria tai informaatioteknologiaa, se on monoliitti.

Maalaisjärjellä ajateltuna, mitä isompi monoliitti on, sitä vaikeampi sitä on siirtää, sitä painavampi se on ja sitä helpommin siitä murtuu osa. Eikä yhdestä kivestä hakattua kokonaisuutta jälkikäteen enää juuri muokata. Puolen välin jälkeen ei enää muuteta mieltä siitä, millainen lopputuloksesta halutaan.

Mitä tekoa tällä on IT-järjestelmien kanssa?

Iso osa vanhoista IT-järjestelmistä on monoliitteja. IT-monoliitti on yksi iso järjestelmä, jossa kaikki ominaisuudet ovat samasta kivestä, eikä niitä saa irti toisistaan. Se on tehty yleensä yhdellä teknologialla ja sitä suoritetaan yhdestä paikasta, yhtenä prosessina. Kun se alkaa ajan saatossa hapertua, sitä on vaikea paikata. Jos sitä halutaan muokata tai kehittää, se on yleensä ongelmallista ja kallista.

Esimerkiksi verkkokauppamonoliitti on vanha järjestelmä, joka pitää sisällään niin verkkokaupan, varastonhallinnan, toimitusten käsittelyn kuin toiminnanohjausjärjestelmänkin ja ne ovat kaikki samaa kokonaisuutta, samaa sovellusta. Samanlaisia isoja järjestelmiä on kaikkialla yksityiseltä sektorilta valtionhallintoon.

Monoliitissä ei sinänsä ole mitään vikaa. Saattaa olla järkevääkin tehdä yksi kokonaisuus yhdestä kivestä, kunhan kokonaisuus on riittävän pieni, muutostarpeita on tiedossa vähän, sovelluksen oletettu elinkaari on lyhyt tai tarvitaan ”kertakäyttöjärjestelmä”. Silloin kokonaisuus on yksinkertainen ja toimii, tiedonsiirto järjestelmän osien välillä on vaivatonta ja yksinkertaista. Ongelmiin päädytään vasta sitten, jos yhdestä kivestä yritetään rakentaa kokonainen kerrostalo huonekaluineen.

Tutustu verkkokauppa osaamiseemme

Miksi monoliitista halutaan eroon?

Yksi syy hankkiutua eroon monoliiteista on se, että järjestelmät vanhenevat ja niitä pitäisi päivittää. Valtavan järjestelmän uusiminen yhdellä kertaa on valtava investointi ja myös valtavan pitkä projekti. Ei ole enää oikein realistista teettää miljoonia maksava kilpailutus ja uusia kokonainen monoliitti toiseen monoliittiin. Se on yksinkertaisesti liian riskialtista.

Toinen syy muuttaa monoliittia nousee tarpeesta tuoda uusia palvelukanavia tai rakentaa kokonaan uusia palveluita asiakkaalle. Esimerkiksi halutaan tuoda tietoa vanhasta järjestelmästä vaikkapa auton kojelautaan tai älytelkkariin. On tarve tehdä vanhalle, selaimesta käytettävälle palvelulle mobiilikäyttöliittymä. Tai halutaan palvella asiakasta monikanavaisesti kaikissa mahdollisissa kanavissa.

Vanha järjestelmä ei kuitenkaan pysty näitä tarpeita palvelemaan, koska niitä ei ollut silloin, kun kiveä alettiin aikanaan hakata.

Siksi tehdään polyliittejä

Polyliitti ei ole mikään virallinen termi, mutta kuvaa nykyaikaista tapaa tehdä uusia tai päivittää vanhoja IT-järjestelmiä. Monoliitti puretaan pienempiin osiin ja siihen lisätään uusia pieniä osia, jotka keskustelevat kyllä keskenään, mutta eivät ole kiinni samassa järjestelmässä. Järjestelmiä rakennetaan ja uudistetaan paloista.

Tämä saattaa kuulostaa siltä, että kokonaisuus sirpaloituu. Tosiasiassa kun monoliittia puretaan, asioista pyritään tekemään yksinkertaisempia ja paremmin hallittavia, ongelma pyritään ”pureksimaan” pienemmissä paloissa. Toki monikanavaisessa, palasista koostuvassa järjestelmässä vaaditaan erilaista kokonaisuuden hallintaa kuin monoliittia tehtäessä. Siksi ymmärrän, että saattaa tuntua turvallisemmalta marssia toimittajan luo ja tilata yksi kokonainen monoliitti, yhdellä kertaa.

Polyliittiä puoltaa kuitenkin muutama erittäin tärkeä asia:

• Kun järjestelmä ei ole yksi valtava kokonaisuus, investoinnin riski pienenee merkittävästi. Uudistusta voidaan testata ensin osalla, ennen kuin tehdään suuria päätöksiä.
• Isoa kokonaisuutta on vaikea hinnoitella oikein ja projekteihin saattaa tulla piilo- ja yllätyskuluja. Pieniä kokonaisuuksia on helpompi arvioida ja hallita.
• Polyliittiin suunnitelmaan voidaan tehdä matkalla muutoksia, kun kokonaisuus koostuu joka tapauksessa paloista. Paloja voi vaihtaa, lisätä tai poistaa.
• Toimittajaa voidaan helpommin vaihtaa, jos jälki ei ole sopimuksen mukaista. Kokonaisuuden toteuttamiseen voi osallistua useampi tekninen toteuttaja.
• Järjestelmän voi tehdä monilla eri teknologioilla, jotka palvelevat tiettyjä osia paremmin kuin se yksi ja sama, jolla monoliitti on tehty.
• Uudistuksia saadaan nopeammin ulos, kun niitä tehdään osissa. Vanha järjestelmä pysyy silti toimintakuntoisena, jotta käyttäjä ei kokisi suuria katkoja palvelussa.

Ainakin suosittelen vakavasti harkitsemaan ennen monoliitin ostoa, että olisiko sitten kuitenkin järkevämpi rakentaa paloista kuin hakata yhdestä kivestä.

Lisätietoja

Juha Wiberg

• Senior Software Architect
• juha.wiberg@ambientia.fi
• +358 50 372 0297

Kirjoittaja on omien sanojensa mukaan "humanisti insinöörin valepuvussa, polkujuokseva onsite-koodari ja arkkitehtuurisäätäjä".

Julkaistu 30.5.2018.