Mitä jatkuvat palvelut tarkoittavat järjestelmän elinkaaren aikana?

Tuotantoon siirtyminen ei ole järjestelmän elinkaaren päätepiste

Yksi jatkuviin palveluihin liittyvistä keskeisistä väärinkäsityksistä on ajatus siitä, että järjestelmä olisi valmis, kun toteutusprojekti saadaan päätökseen ja ratkaisu julkaistaan tuotantoon.

Todellisuudessa tuotantoon siirtynyt järjestelmä on vasta elinkaarensa alussa. Kun käyttäjät alkavat käyttää sitä, esiin voi tulla uusia tarpeita. Integraatiot voivat muuttua, ympäröivät järjestelmät kehittyvät ja tekninen ympäristö elää. Samalla järjestelmään ja sen käyttämiin teknologioihin liittyy tietoturvan, päivitysten ja elinkaaren hallinnan tarpeita.

Jos tätä kokonaisuutta ei hallita julkaisun jälkeen, järjestelmä ei pysy itsestään ajan tasalla. Jatkuvien palveluiden tarkoituksena on varmistaa, että ratkaisu säilyy toimivana, turvallisena ja kykenee kehittymään liiketoiminnan mukana.

Jatkuvat palvelut eivät siten ole vain reagointia tilanteisiin, joissa jokin menee rikki. Niissä on kyse järjestelmän systemaattisesta hoitamisesta koko sen elinkaaren ajan.

Jatkuvat palvelut pitää huomioida jo projektin aikana

Jatkuviin palveluihin siirtymistä ei kannata alkaa suunnitella vasta siinä vaiheessa, kun järjestelmä on jo julkaistu.

Jos jo projektin aikana tiedetään, että järjestelmä siirtyy jatkuvien palveluiden piiriin, asia kannattaa huomioida alusta lähtien. Yksi keskeisistä syistä on dokumentaatio. Jatkuvien palveluiden näkökulmasta järjestelmästä pitää olla käytettävissä riittävän tasoinen ja ajan tasalla oleva dokumentaatio, joten sen tuottamista ja ylläpitämistä ei kannata jättää projektin loppuun.

Tuotantoon siirtymisen lähestyessä yhteistyö toteutusprojektin ja jatkuvien palveluiden välillä tiivistyy, mutta keskustelu voi alkaa jo paljon aikaisemmin – jopa ostovaiheessa. Siinä vaiheessa voidaan muodostaa ensimmäistä käsitystä esimerkiksi siitä, kuinka kriittinen järjestelmä tulee olemaan asiakkaalle ja millaisia palveluita sen ympärille tarvitaan.

Palvelun kriittisyys voi myös muuttua projektin aikana. Aluksi melko pieneltä vaikuttava ratkaisu saattaa muodostua organisaatiolle huomattavasti tärkeämmäksi kuin alun perin arvioitiin. Toisaalta myös päinvastainen kehitys on mahdollinen.

Viimeistään ennen tuotantoon siirtymistä pitää siksi ratkaista, millainen palvelutaso järjestelmälle tarvitaan ja tarvitaanko esimerkiksi ympärivuorokautista 24/7-valvontaa ja reagointia. Vaikka 24/7-palvelulle ei olisi tarvetta, järjestelmä voi silti kuulua jatkuvien palveluiden ja elinkaaren hallinnan piiriin.

Jatkuvien palveluiden kustannukset ovat osa järjestelmän kokonaiskustannusta

Jatkuvien palveluiden tarve kannattaa huomioida myös järjestelmän kustannuksia arvioitaessa.

Projektin toteutushinta on vain yksi osa järjestelmän kokonaiskustannusta. Sen jälkeen syntyy jatkuvia kustannuksia järjestelmän ylläpidosta ja palveluista. Siksi järjestelmää suunniteltaessa tarkasteluun kuuluu myös sen käytön aikainen kustannus eli kokonaiskustannus pidemmällä aikavälillä.

Kaikkea ei IT-projektissa pystytä arvioimaan täydellisesti etukäteen, ja palvelun tarpeet voivat tarkentua projektin edetessä. Jatkuvien palveluiden kustannuksia pyritään kuitenkin hahmottamaan jo varhaisessa vaiheessa, jotta myös järjestelmän käytön aikaisia kustannuksia voidaan budjetoida.

Mitä jatkuvat palvelut käytännössä sisältävät?

Jatkuvat palvelut muodostuvat useasta eri osa-alueesta. Kokonaisuus voi sisältää muun muassa:

• sovellus- ja käyttäjätukea sekä ongelmatilanteiden ratkaisemista
• järjestelmän elinkaaren hallintaa
• tarvittaessa lisenssien hallintaa
• palveluiden ja teknisen ympäristön valvontaa
• hälytyksiin reagointia
• alustan ylläpitoa
• varmistuksia ja palautusmahdollisuuksien ylläpitämistä
• kapasiteetin hallintaa esimerkiksi pilviympäristöissä
• sovitun palvelutason mukaista, tarvittaessa 24/7 tapahtuvaa valvontaa ja reagointia.

Käytännössä merkittävä osa työstä tapahtuu asiakkaalle näkymättömissä. Parhaassa tapauksessa jatkuva palvelu ei näy päivittäisessä käytössä juuri lainkaan: palvelu toimii, tietoturva on kunnossa ja taustalla tapahtuvat tarvittavat toimenpiteet hallitusti.

Jos esimerkiksi päivitys vaatii käyttökatkoa, siitä kommunikoidaan erikseen. Muuten jatkuvien palveluiden onnistuminen voi näkyä nimenomaan siinä, ettei käyttäjän tarvitse kiinnittää järjestelmän tekniseen ylläpitoon huomiota.

Valvonnassa tärkeintä ei ole vain havaita ongelma vaan pystyä reagoimaan siihen

Valvonnan tehtävänä on havaita erilaisia poikkeamia ja tilanteita, jotka vaativat toimenpiteitä.

Kyse voi olla esimerkiksi järjestelmän resursseihin liittyvästä hälytyksestä tai tietoturvapoikkeamasta. Valvontaan tarvitaan myös toimintamalli ja ihmiset, jotka pystyvät reagoimaan havaittuun tilanteeseen.

Webinaarissa nostettiin esimerkiksi tilanne, jossa yhteen palveluun kohdistunut pienimuotoinen hyökkäys havaittiin ja sen perusteella pystyttiin tekemään estäviä toimenpiteitä. Samalla todettiin, että nykyiset ympäristöt ovat aikaisempaa monimuotoisempia: valvonta ei tarkoita pelkästään perinteisten palvelinten resurssien seuraamista.

Tietoturva­haavoittuvuuksien hallinta vaatii jatkuvaa seurantaa

Tietoturva on yksi selkeimmistä esimerkeistä siitä, miksi järjestelmää ei voida vain julkaista ja jättää sen jälkeen ennalleen.

Webinaarissa kuvattiin tietoturvahaavoittuvuuksien määrän kasvaneen ja todettiin, että uusia haavoittuvuuksia pitää seurata aktiivisesti. Kun haavoittuvuuksia julkaistaan, niiden perusteella voidaan joutua päivittämään asiakkaiden ympäristöjä, sovelluksia ja niiden käyttämiä palveluita tai kirjastoja.

Keskeinen osa prosessia on selkeä vastuu. Jonkun pitää seurata haavoittuvuuksia ja arvioida niiden merkitystä.

Kaikki julkaistavat tietoturvatiedotteet eivät koske kaikkia järjestelmiä. Kun haavoittuvuus havaitaan, pitää ensin selvittää, mihin hallinnassa oleviin järjestelmiin, asiakkaisiin ja ympäristöihin se mahdollisesti vaikuttaa. Tätä varten tarvitaan sekä ajantasaista tietoa ympäristöistä että järjestelmiä, joiden avulla vaikutukset pystytään tunnistamaan.

Kun vaikutukset on tunnistettu, tarvittavat toimenpiteet kirjataan ja niiden etenemistä seurataan. Asiakkaalle pitää usein myös viestiä asiasta, sillä esimerkiksi päivitykset voivat vaatia testaamista tai palvelun uudelleenkäynnistämistä.

Useimmat tilanteet voidaan käsitellä normaalilla prosessilla: ongelma tunnistetaan, tarvittavat toimenpiteet määritetään ja niiden toteutuminen varmistetaan. Erittäin kriittisissä tilanteissa voidaan kuitenkin joutua käynnistämään erillinen toimintamalli, jossa muita töitä pysäytetään ja tarvittavat asiantuntijat keskitetään ongelman ratkaisemiseen.

Reagoinnin merkitystä kasvattaa se, että tietoturvatilanteissa käytettävissä oleva aika voi olla lyhyt. Erityisen haastavia ovat tilanteet, joissa haavoittuvuutta ryhdytään hyödyntämään nopeasti sen julkitulon jälkeen. Silloin korjaaviin toimenpiteisiin ei välttämättä ole käytettävissä pitkää aikaa.

Elinkaaren hallinta perustuu tietoon siitä, mitä järjestelmä todella sisältää

Haavoittuvuuksia tai päivitystarpeita ei voida hallita luotettavasti, jos järjestelmän teknisestä kokonaisuudesta ei ole tarkkaa tietoa.

Elinkaaren hallintaan kuuluu esimerkiksi tieto siitä, mitä teknologioita ja versioita asiakkaan ympäristössä käytetään. Versioita ei voida vain arvailla, vaan niiden pitää olla tiedossa.

Valmiissa tuotteissa ja alustoissa voidaan seurata teknologiatoimittajien ja ohjelmistojulkaisijoiden tiedotteita ja päivityksiä. Täysin räätälöidyssä järjestelmässä tilanne on erilainen: silloin järjestelmä pitää tuntea alusta lähtien, eikä voida luottaa siihen, että ulkopuolinen toimittaja ilmoittaa kaikista järjestelmää koskevista asioista.

Tässä dokumentaation ja muiden teknisten työkalujen merkitys korostuu. Niiden avulla ylläpidetään tilannekuvaa siitä, mitä ympäristössä on ja mitä siellä tapahtuu.

Elinkaaren hallinnassa pyritään reagoimisen lisäksi ennakoimaan

Hyvä elinkaaren hallinta ei tarkoita sitä, että odotetaan teknologian vanhentumista ja toimitaan vasta sitten.

Jos tiedetään esimerkiksi, että jokin järjestelmän käyttämä komponentti tai palvelu lähestyy elinkaarensa loppua tiettynä ajankohtana, asia voidaan ottaa käsittelyyn etukäteen. Asiakkaalle voidaan kertoa tulevasta muutoksesta ajoissa ja tarvittavat toimenpiteet voidaan suunnitella, aikatauluttaa ja resursoida.

Ennakointi helpottaa sekä asiakkaan että palveluntuottajan toimintaa. Kun tulevat elinkaarimuutokset tunnetaan, päivityksiä voidaan mahdollisuuksien mukaan yhdistää muihin muutoksiin. Tämä voi tehdä tekemisestä myös kustannustehokkaampaa kuin tilanteessa, jossa päivitystarve havaitaan vasta viime hetkellä.

Dokumentaatio suojaa järjestelmää myös henkilövaihdosten ja organisaatiomuutosten jälkeen

Pitkään käytössä olleiden järjestelmien ongelmat eivät synny välttämättä yhdestä yksittäisestä virheestä.

Vuosien aikana dokumentaatio voi jäädä puutteelliseksi, henkilöt vaihtua ja järjestelmien omistus siirtyä esimerkiksi organisaatiomuutosten tai yrityskauppojen yhteydessä. Samalla ympäröivä teknologia ja liiketoiminnan tarpeet muuttuvat.

Jos tietoa on pääasiassa yksittäisten ihmisten varassa, henkilövaihdos voi tehdä järjestelmän ylläpidosta huomattavasti vaikeampaa. Vanha järjestelmä voi lopulta päätyä tilanteeseen, jossa siihen ei uskalleta tehdä muutoksia, koska kokonaisuutta ei tunneta riittävän hyvin.

Dokumentointi, jatkuva viestintä ja järjestelmän määrittelyn ylläpitäminen vähentävät tätä riskiä. Pitkäaikaisessa yhteistyössä hyötyä on myös jatkuvuudesta: mitä paremmin järjestelmää ja asiakkaan toimintaa tunteva osaaminen säilyy mukana eri vaiheiden yli, sitä vähemmän tietoa katoaa siirtymissä.

Selkeä omistajuus on jatkuvien palveluiden edellytys

Tekninen ylläpito ei yksin ratkaise järjestelmän elinkaaren hallintaa. Järjestelmällä pitää olla myös asiakkaan organisaatiossa selkeä omistaja.

Sudenkuoppa syntyy, jos julkaisun jälkeen ei ole sovittu, kuka järjestelmästä vastaa. Liiketoiminta saattaa odottaa IT:n ottavan vastuun, samalla kun IT odottaa liiketoiminnalta päätöksiä ja priorisointia.

Seurauksena kehitys voi hidastua. Jos kukaan ei priorisoi tarpeita ja tee päätöksiä, järjestelmä voi vähitellen lakata tukemasta niitä tavoitteita, joita varten se alun perin toteutettiin.

Ratkaisuna on sekä selkeästi määritelty omistajuus että sovittu jatkuvan palvelun toimintamalli. Palvelukumppani voi nostaa esille ylläpitoa ja kehittämistä vaativia asioita, mutta asiakkaan puolelta tarvitaan henkilö tai taho, joka pystyy tekemään tarvittavia päätöksiä.

Organisaation koko vaikuttaa haasteiden luonteeseen. Pienemmässä organisaatiossa ongelmaksi voi muodostua itse omistajuuden epäselvyys. Suuremmassa organisaatiossa tavoite ja vastuut saattavat olla tiedossa, mutta päätöksenteko voi olla hitaampaa esimerkiksi siksi, että päätöksiä tarvitaan useista eri organisaation osista tai maista.

Tekninen velka syntyy monesta lähteestä – ja lykkäykset kasaavat sitä

Tekninen velka on käytännössä väistämätön osa monien järjestelmien elinkaarta. Sen syntymiselle ei ole yhtä yksittäistä syytä.

Taustalla voi olla esimerkiksi aikanaan tehty teknologiavalinta, joka osoittautuu myöhemmin hankalaksi. Järjestelmään liittyvän osaamisen saatavuus voi heikentyä. Integraatiot ja muut järjestelmät voivat synnyttää uusia riippuvuuksia ja rajoitteita.

Teknistä velkaa syntyy myös silloin, kun tarpeellisia asioita siirretään jatkuvasti myöhemmäksi. Yksittäinen lykkäys ei vielä välttämättä aiheuta suurta ongelmaa, mutta jos päätöksiä siirretään riittävän monta kertaa, tehtävät ja ongelmat alkavat kasaantua. Tilannetta voi vaikeuttaa entisestään se, jos samalla järjestelmän keskeisiä osaajia poistuu organisaatiosta.

Webinaarissa tätä verrattiin siivoamiseen: jos perustasoa ylläpitää jatkuvasti pienillä toimenpiteillä, työ pysyy hallittavana. Jos mitään ei tehdä pitkään aikaan, korjausurakka kasvaa huomattavasti suuremmaksi.

Sama ajatus pätee järjestelmän tekniseen kuntoon. Jatkuvien palveluiden tehtävänä ei ole poistaa kaikkea teknistä velkaa, vaan auttaa tunnistamaan ja hallitsemaan sitä ennen kuin ongelmat kasvavat liian suuriksi.

Kaikkea ei voida ratkaista palveluntuottajan toimesta

Jatkuvat palvelut vähentävät riskiä siitä, että järjestelmä yksinkertaisesti unohtuu, mutta ulkopuolinen palveluntuottaja ei voi yksin ratkaista kaikkia järjestelmän ongelmia.

Järjestelmän ylläpidon pitää kulkea käsi kädessä asiakkaan ja loppukäyttäjien tarpeiden kanssa. Se tarkoittaa, että tarvittavat kehitys- ja muutospäätökset riippuvat myös asiakkaan tekemistä valinnoista.

Lisäksi järjestelmä voi olla riippuvainen kolmansista osapuolista. Tekninen velka tai muu ongelma saattaa johtua toisesta järjestelmästä, johon ei voida juuri sillä hetkellä tehdä tarvittavaa muutosta. Yhden järjestelmän elinkaaren päättyminen voi siten aiheuttaa haasteita myös muille siihen kytkeytyville ratkaisuille.

Järjestelmän julkaisun jälkeen on käytännössä kolme mahdollista kehityspolkua

Järjestelmän tilannetta muutaman vuoden kuluttua tuotantoon siirtymisestä voidaan hahmottaa kolmen erilaisen mallin kautta.

Ensimmäisessä järjestelmällä on hallittu jatkuvan palvelun malli. Sen teknistä kuntoa ylläpidetään ja samalla järjestelmää voidaan aktiivisesti kehittää edelleen. Jatkokehitysprojekteja voi siis olla käynnissä samaan aikaan jatkuvien palveluiden kanssa.

Toisessa mallissa järjestelmä on ikään kuin pysähtyneessä tilassa. Se on edelleen tuotannossa ja jatkuvien palveluiden piirissä, mutta varsinaista jatkokehitystä ei juuri tehdä. Tarvittaessa ratkaistaan häiriöitä ja toteutetaan pieniä muutoksia.

Kolmas ja riskialttein vaihtoehto on tilanne, jossa jatkuvia palveluita ei ole lainkaan. Silloin järjestelmältä puuttuu systemaattinen hallinta. Tietoturvariskit kasvavat ja tekninen velka voi kasaantua.

Jatkuvat palvelut ja jatkokehitys eivät tarkoita samaa asiaa

Jatkuvat palvelut ja järjestelmän jatkokehitys kulkevat usein rinnakkain, mutta kyse on eri asioista.

Sovellus- ja ohjelmistokehityksen jatkokehitys on projektityyppistä tekemistä. Siihen liittyy kehitystiimi ja projektin johtaminen, ja tavoitteena on kehittää järjestelmään uusia tai laajempia ominaisuuksia.

Jatkuvien palveluiden tehtävänä on puolestaan huolehtia olemassa olevasta järjestelmästä. Niissä käsitellään häiriöitä ja ongelmia sekä voidaan toteuttaa pienempiä muutospyyntöjä, mutta varsinainen laajempi jatkokehitys on erillistä tekemistä.

Asiakkaan yhteydenpitoa varten voidaan käyttää Service Deskiä ja asiakasportaalia, jonka kautta tukipyynnöt tulevat käsiteltäväksi ja jossa asiakas pystyy seuraamaan omia tukitapauksiaan.

Tämä jako mahdollistaa myös tilanteen, jossa järjestelmän perustekninen hallinta jatkuu, vaikka uusia ominaisuuksia ei juuri sillä hetkellä rakennettaisi.

Myös toisen toimittajan toteuttama järjestelmä voidaan ottaa jatkuvien palveluiden piiriin

Jatkuvien palveluiden ei tarvitse alkaa saman toimittajan toteutusprojektista. Myös jonkun muun rakentama järjestelmä voidaan ottaa haltuun.

Haltuunotolle on kuitenkin tiettyjä edellytyksiä.

Dokumentaation pitää olla riittävällä tasolla ja sen taso pitää pystyä arvioimaan ennen siirtymistä. Vastuiden ja omistajuuden pitää olla selvillä sekä palveluntuottajan että asiakkaan puolella. Erityisesti ulkopuolelta haltuun otettavassa järjestelmässä myös ympäristön vakauden ja hallittavuuden pitää olla riittävällä tasolla, jotta jatkuvaa palvelua voidaan lähteä rakentamaan hallitusti.

Kun kokonaisuuteen liittyy useita eri tahoja, vastuunjako pitää käydä läpi jo alkuvaiheessa. Tähän voidaan käyttää esimerkiksi RACI-mallia, jolla kuvataan, mitkä tehtävät kuuluvat kenellekin.

Integraatiot ja data ovat osa valvottavaa kokonaisuutta

Nykyaikainen järjestelmä ei välttämättä ole yksi itsenäinen sovellus, vaan se voi olla kytköksissä lukuisiin muihin palveluihin ja datalähteisiin.

Siksi myös integraatioita voidaan joutua valvomaan. Data-alustoille pitäisi saada tietoa oikeassa muodossa ja oikeaan aikaan, ja näiden prosessien toiminta on osa järjestelmän kokonaisuutta.

Räätälöidyissä sovelluksissa valvontaa voidaan helpottaa jo suunnitteluvaiheessa. Järjestelmään voidaan rakentaa rajapintoja ja muita keinoja, joiden kautta sen toiminnasta ja esimerkiksi suorituskyvystä saadaan tarvittavaa tietoa.

Tämä on jälleen yksi syy siihen, miksi jatkuvien palveluiden tarpeita kannattaa miettiä jo toteutusprojektin aikana eikä vasta järjestelmän valmistuttua.

Jatkuvien palveluiden hinta riippuu ennen kaikkea palvelutasosta ja järjestelmän kompleksisuudesta

Jatkuvien palveluiden kustannuksille ei ole yhtä vakiohintaa, koska järjestelmät ja niiden tarvitsemat palvelut voivat olla hyvin erilaisia.

Hintaan vaikuttaa ensinnäkin sovittu palvelutaso. Siihen kuuluvat esimerkiksi SLA:ssa määritellyt vasteajat sekä se, millä aikavälillä valvonnan ja reagoinnin pitää olla käytettävissä.

Toinen keskeinen tekijä on järjestelmän kompleksisuus. Mitä enemmän järjestelmässä on esimerkiksi erilaisia integraatioita ja teknisiä ympäristöjä, sitä enemmän hallittavaa kokonaisuudessa on.

Webinaarissa kustannusten haarukaksi kuvattiin hyvin yleisellä tasolla muutamasta sadasta eurosta tuhansiin euroihin kuukaudessa. Tarkkaa hintaa ei voida määritellä ilman tietoa järjestelmästä ja palvelutasosta.

Kevyt SaaS-ratkaisu, jonka tekninen valvonta hoidetaan muualla, voi vaatia palveluntuottajalta hyvin rajattua panosta. Toisessa ääripäässä voi olla teknisesti monimutkainen kokonaisuus, jossa hallitaan kapasiteettia ja valvontaa ja ympäristö koostuu lukuisista palvelimista, verkkolaitteista ja erilaisista yhteyksistä.

Jatkuvien palveluiden kustannukset ovat samalla yleensä luonteeltaan ennustettavia kuukausikustannuksia.

Jos järjestelmä on jo päässyt heitteille, ensimmäinen tehtävä on muodostaa tilannekuva

Jatkuvien palveluiden aloittaminen ei edellytä, että järjestelmä olisi valmiiksi täydellisessä kunnossa.

Jos järjestelmä on ollut pitkään ilman hallittua ylläpitoa, ensimmäinen vaihe on käydä asiakkaan kanssa läpi, millaisesta palvelusta on kyse ja missä kunnossa se tällä hetkellä on. Sen jälkeen voidaan kartoittaa järjestelmän nykytila sekä määritellä tarvittavat seuraavat toimenpiteet.

Täysin ilman mitään dokumentaatiota olevat järjestelmät eivät webinaarissa kuvatun kokemuksen mukaan ole tavallisin tilanne. Useimmiten jotakin tietoa löytyy, mutta sen oikeellisuus, kattavuus ja käyttökelpoisuus voivat vaihdella.

Parhaassa tilanteessa haltuunotossa pystytään keskustelemaan järjestelmän alkuperäisten kehittäjien kanssa. Aina tämä ei kuitenkaan ole mahdollista. Dokumentaatio voi olla myös siinä mielessä puutteellista, että varsinainen tieto on löydettävissä lähdekoodista mutta sitä ei ole koottu valmiiksi helposti hyödynnettävään muotoon.

Järjestelmän elinkaari vaatii jatkuvaa hallintaa

Jatkuvien palveluiden perusajatus voidaan lopulta palauttaa yksinkertaiseen asiaan: IT-järjestelmä muuttuu myös silloin, kun sitä ei aktiivisesti kehitetä.

Sen ympärillä olevat teknologiat vanhenevat, haavoittuvuuksia löytyy, integraatiot ja muut järjestelmät muuttuvat, käyttäjien tarpeet kehittyvät ja organisaation ihmiset vaihtuvat. Jos järjestelmää ei samalla ylläpidetä ja sen tilaa seurata, muutokset alkavat vähitellen kasaantua.

Jatkuvien palveluiden tehtävä on tuoda tähän systemaattinen toimintamalli: ylläpitää tilannekuvaa, seurata järjestelmän teknistä elinkaarta, reagoida häiriöihin ja tietoturvatarpeisiin, ennakoida tulevia muutoksia sekä pitää järjestelmä hallittavana myös vuosien kuluttua.

Tuotantoon siirtyminen ei siis päätä järjestelmän kehityskaarta. Se aloittaa sen vaiheen, jossa järjestelmän toimivuudesta, turvallisuudesta ja hallittavuudesta pitää huolehtia pitkäjänteisesti.