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

Järjestelmäarkkitehtuuri

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 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.

Vaikka onkin hohdokkaampaa keskustella yrityksen kilpailukyvystä rekrytoinnin tai viestintäkäytäntöjen tasolla, niin järjestelmät ovat se pohja, jolle työkulttuuri aidosti rakentuu.

Uusilla startupeilla on sinänsä ihanteellinen tilanne, että ne voivat alusta asti alkaa käyttää pilvipalveluita eikä monoliittista möhkälejärjestelmää pääse kehittymään. Mutta entä kun suurella organisaatiolla 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?

Resurssointi 

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. Ihanteellista on, jos kumppanilla on kokemusta konteksista. Integraatioiden suunnittelu ja toteutus varastonhallintaan tai logistiikkaan vaatii erilaista tietämystä suhteessa esimerkiksi ERP-, PIM- tai CRM-järjestelmiin.

Nykytilanteen kartoitus

Kun on selvää kenen kanssa hankkeeseen lähdetään, itse järjestelmäarkkitehtuurin kehitystyö lähtee liikkeelle 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.

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.

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

Monoliittimöhkäleestä 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, niin voidaan ketterästi kokeilla jotakin muuta.