Jos järjestelmäarkkitehtuuri on 90-luvulta, voiko kehitystyö olla ketterää?

Lähes joka toisen yrityksen nettisivuilla ja myyntipuheissa tuodaan ilmi, kuinka toiminta on leania tai agilea. Prosessien tehostaminen ja ketterä tuote- tai palvelukehitys jää kuitenkin usein vain kauniiksi korulauseeksi, mikäli järjestelmäarkkitehtuuri on jämähtänyt 90-luvulle. Vaikka kehitystyön hitaus ja kömpelyys alkaakin jossakin vaiheessa valjeta yrityksessä, saatetaan pinnistellä viimeiseen asti purkkaratkaisuiden varassa. Tämä on luonnollista, sillä laaja-alaiset muutokset etenkin suurten ja vakiintuneiden organisaatioiden järjestelmäarkkitehtuurissa vaativat aikaa sekä resursseja, joihin ei helposti tunnu kiireessä olevan aikaa.

Monoliittinen velka

Uusilla yrityksillä on sinänsä ihanteellinen tilanne, että ne voivat alkaa rakentaa alusta asti modernia järjestelmäarkkitehtuuria ilman monoliittisten järjestelmien tuomaa rasitetta. Mutta entä kun suuressa organisaatiossa saavutetaan se piste, että kilpailukyky kärsii kehitystyön hitaudesta ja ylläpitoon menee enemmän rahaa kuin uudistuksiin? Miten siirtyä järkevästi mikropalveluihin?

Mikropalvelut hyödyt

Ei kertakäyttöisiä järjestelmiä, vaan skaalautuvaa hyötyä

Mikropalvelut tehostavat ohjelmistojen ylläpidon ja kehityksen. Lisäksi ne avaavat täysin uusia mahdollisuuksia liiketoiminnan kehitykselle. Kerran kehitettyä peruskomponenttia voidaan hyödyntää uusissa liiketoiminnoissa, minkä vuoksi yritysten on helppo laajentaa palvelutarjontaansa.

1. Resurssointi ja projektin suunnittelu

Näin mittaviin projekteihin harvoin riittää talon sisältä resursseja. Kun valitset kumppania, valitse sellainen, joka kykenee sekä strategiseen liiketoiminnan suunnitteluun että tekniseen toteutukseen. Koska uudistukset järjestelmäarkkitehtuurissa eivät tapahdu yhdessä yössä, on ensisijaisen tärkeää luoda vaiheittainen roadmap, joka ottaa huomioon resurssit sekä liiketoiminnan kannalta kriittisimmät tarpeet. Ihanteellisinta on se, että kumppanilla on kokemusta konteksista. Integraatioiden suunnittelu ja toteutus varastonhallintaan tai logistiikkaan vaatii erilaista tietämystä suhteessa esimerkiksi ERP-, PIM- tai CRM-järjestelmiin.

2. Nykytilanteen kartoitus

Kun on selvää kenen kanssa hankkeeseen lähdetään, itse järjestelmäarkkitehtuurin kehitystyö alkaa nykytilan perusteellisesta kartoituksesta. Mitä suurempi ja vakiintuneempi organisaatio on, sitä enemmän tähän vaiheeseen tulee luonnollisesti käyttää aikaa. Jotta arkipäivän käytäntöjä voidaan ymmärtää riittävällä tarkkuudella, kannattaa haastatella mahdollisimman useaa käyttäjää ja toimittajaa. Arkkitehtuurin hahmottamiseen voi käyttää ruutuvihkoa, Exceliä tai siihen tarkoitettuja visuaalisia ohjelmistoja. Pääasia on se, että kaikki järjestelmien väliset suhteet havainnoidaan, niiden roolit ja käyttäjät listataan sekä ymmärretään, miten valinnat palvelevat liiketoiminnan tavoitteita.

3. Tee työtä, jolla on tarkoitus?

Seuraavaksi lähdetään suunnittelemaan arkkitehtuuria ja minimoimaan päällekkäisiä toimintoja. Palapelin palaset järjestellään uudelleen ja turhat heitetään roskiin. Luomalla järjestelmille järkevät roolit ja vastuut voidaan optimoida työntekijöiden ajankäyttö. Kun samaa tietoa ei tarvitse lisätä moneen paikkaan, tulee työnteosta myös mielekkäämpää ja manuaalisen työn inhimillisyydestä johtuvat virheet vähenevät. Integraatioilla ei helpoteta pelkästään työntekijöiden arkea, vaan tehdään myös asiakkaista tyytyväisempiä. Esimerkiksi omnichannel-kaupassa saatavuustiedot verkon ja kivijalkamyymälän välillä tulee saada ajan tasalle. Jos tiedonsiirto on hidasta ja päivitykset ajetaan vain kerran yössä, eivät asiakkaat tai myyjät voi luottaa saldomääriin.

Mikropalvelut

4. Monoliittijärjestelmästä mikropalveluihin

Kun monoliittijärjestelmää aletaan purkaa ja korvata pienemmillä, ketterillä osakokonaisuuksilla, täytyy toteutuksen olla hallittu ja johdonmukainen. Huonosti johdetussa uudistustyössä kriittistä tietoa häviää tai kehityksessä tehdään turhia virheitä, jotka moninkertaistavat prosessin keston.

Mikropalveluiden yksi eduista on se, että jokaista palvelukokonaisuutta voi kehittää oma porukkansa. Tällöin vastuu jakautuu selkeämmin ja tiimeille voidaan asettaa esimerkiksi mikropalvelukohtaisia KPI:tä. Kun tiimi on vastuussa yhdestä kokonaisuudesta eikä epämääräisestä osasta suurta järjestelmää, vastuunotto tapahtuu luonnostaan. Sen sijaan, että asioita palloteltaisiin eri asiantuntijoiden välillä, ovat tiimit itsenäisesti vastuussa komponentin toimivuudesta.

Henkilöstö tulee kouluttaa uuteen ajattelutapaan sekä työskentelylogiikkaan. Mikropalveluiden käyttö ei mullista ainoastaan ohjelmistokehittäjien arkea, vaan luo uudenlaisia mahdollisuuksia myös esimerkiksi liiketoiminnan kehittäjille tai myynnin vastuuhenkilöille. Mikropalveluiden myötä voidaan siirtyä aidosti ketterään kehitykseen ja kokeilla innovatiivisesti uusia ideoita: yksittäinen mikropalvelu on nopea toteuttaa ja jos se ei toimi, voidaan ketterästi kokeilla uutta suuntaa.