Säilytä liikkumavara pilvessä – 8 asiaa, jotka kannattaa varmistaa

Tässä artikkelissa:

1. Datan sijainti ja palveluketju
2. Datan ja työkuormien kriittisyys
3. Toimittajariippuvuuksien tunnistaminen
4. Teknologiavalintojen dokumentointi
5. Arkkitehtuurin modulaarisuus
6. Korvaavat ratkaisut kriittisille palveluille
7. Kokonaisuuden omistajuus
8. Teknologiavalintojen jatkuva arviointi

1. Tiedätkö, missä datasi sijaitsee – ja kuka palveluketjua hallitsee?

Datan sijainti on tärkeä osa pilviratkaisun arviointia, mutta se ei yksin kerro koko kuvaa. Datasuvereniteettiin vaikuttavat myös palveluntarjoajan omistus, toimittajaketju ja se, minkä tahojen kautta palvelun jatkuvuus käytännössä rakentuu.

EU:ssa sijaitseva datakeskus ei siis automaattisesti tarkoita, että koko ratkaisu olisi eurooppalaisessa omistuksessa tai hallinnassa. Jos datan sijainti tai palveluketjun omistajuus on liiketoiminnan, asiakkaiden, sääntelyn tai riskienhallinnan kannalta tärkeä kysymys, se kannattaa selvittää koko ketjusta eikä ainoastaan palvelimen fyysisestä sijainnista.

Tarkista ainakin: missä data sijaitsee, kuka palveluntarjoajan omistaa, mitä alihankkijoita tai muita toimijoita palveluketjuun kuuluu ja miten palvelun jatkuvuus on järjestetty.

2. Oletko luokitellut datan ja työkuormat niiden kriittisyyden mukaan?

Kaikkea dataa ja kaikkia järjestelmiä ei tarvitse käsitellä samalla tavalla. Julkinen verkkosivusto, sisäinen liiketoimintadata, henkilötiedot, liikesalaisuudet ja esimerkiksi terveystiedot muodostavat hyvin erilaisia riskiprofiileja, joten myös pilviympäristön vaatimusten pitäisi vaihdella niiden mukaan.

Luokittelu auttaa välttämään kahta ääripäätä. Toisaalta kriittistä tietoa ei sijoiteta ympäristöön, jonka riskit eivät vastaa vaatimuksia, mutta toisaalta kaikkea ei myöskään tarvitse rakentaa korkeimman mahdollisen suojaustason mukaan. Kun työkuormien kriittisyys tunnetaan, myös pilvipalveluiden ja toimittajien vertailu muuttuu konkreettisemmaksi.

Tarkista ainakin: mitkä järjestelmät ovat liiketoimintakriittisiä, mitä dataa ne käsittelevät ja mitä erityisiä vaatimuksia niiden sijainnille, saatavuudelle tai hallinnalle on.

3. Tiedätkö, missä toimittajariippuvuus oikeasti syntyy?

Toimittajariippuvuus eli vendor lock-in ei yleensä synny yhdestä sopimuksesta tai yhdestä suuresta päätöksestä. Se kertyy usein vähitellen hallituista palveluista, rajapinnoista, toimittajakohtaisista teknologioista ja sovelluksiin tehdyistä ratkaisuista, joiden vaihtaminen alkaa myöhemmin vaatia muutoksia myös muualle järjestelmään.

Valmiiden palveluiden käyttäminen ei ole virhe. Ne voivat vähentää ylläpitotyötä, nopeuttaa kehittämistä ja tarjota selvää liiketoimintahyötyä. Olennaista on tunnistaa ne komponentit, joiden kohdalla palveluntarjoajan vaihtaminen tarkoittaisi muutakin kuin vastaavan kapasiteetin ostamista toisesta pilvestä.

Tarkista ainakin: mitkä palvelut ovat standarditeknologiaa, mitkä ovat toimittajakohtaisia ja mihin sovelluksiin tai prosesseihin nämä riippuvuudet ulottuvat.

4. Onko dokumentoitu myös se, miksi teknologiavalinnat on tehty?

Arkkitehtuurikuva kertoo, mitä ympäristössä on, mutta vuosien päästä se ei välttämättä kerro, miksi ratkaisut on alun perin tehty. Juuri perustelujen puuttuminen voi tehdä myöhemmästä muutoksesta hankalan, koska uuden tiimin on vaikea erottaa välttämättömiä riippuvuuksia sellaisista ratkaisuista, jotka syntyivät aikanaan vain silloisen tilanteen perusteella.

Dokumentaation merkitys kasvaa henkilöstön ja kumppaneiden vaihtuessa. Jos kriittinen tieto ympäristön riippuvuuksista on yhden asiantuntijan päässä, samalla katoaa helposti myös ymmärrys siitä, miten järjestelmää voidaan muuttaa turvallisesti.

Tarkista ainakin: onko keskeisistä arkkitehtuuri- ja teknologiavalinnoista kirjattu mitä tehtiin, miksi se tehtiin, mitä riippuvuuksia valinta synnytti ja kuka tiedon omistaa.

5. Onko arkkitehtuuri riittävän modulaarinen?

Modulaarisuus ei tarkoita sitä, että jokainen teknologia pitäisi voida vaihtaa hetkessä. Tavoite on käytännöllisempi: yhden komponentin korvaamisen ei pitäisi pakottaa rakentamaan koko järjestelmää uudelleen, jos siihen ei ole teknistä tai liiketoiminnallista syytä.

Siirrettävyys ja modulaarisuus voivat olla myös hankintavaatimuksia. Kun palvelua tai teknologiaa valitaan, voidaan jo etukäteen arvioida, kuinka suuri osa kokonaisuudesta jouduttaisiin muuttamaan, jos komponentti pitäisi korvata toisella. Tämä tekee riippuvuudesta näkyvän jo päätöksentekovaiheessa.

Tarkista ainakin: onko kriittiset komponentit rajattu selkeästi, voidaanko niitä korvata ilman koko arkkitehtuurin uudistamista ja onko siirrettävyydelle asetettu vaatimuksia hankinnoissa.

6. Mikä korvaisi kriittisen palvelun, jos se poistuisi?

Palveluntarjoaja voi säilyä, vaikka yksittäinen palvelu sen valikoimasta katoaisi. Teknologian hinnoittelu, lisensointi tai kehitysmalli voi myös muuttua tavalla, joka tekee nykyisestä ratkaisusta yritykselle aiempaa huonomman vaihtoehdon. Tämä koskee sekä kaupallisia palveluita että avoimen lähdekoodin teknologioita.

Jokaisesta komponentista ei tarvitse rakentaa rinnakkaista varajärjestelmää. Kriittisten riippuvuuksien kohdalla pitäisi kuitenkin olla ainakin käsitys siitä, millä ratkaisulla toiminnallisuus voitaisiin korvata ja kuinka suuri muutos se vaatisi. Silloin vaihtoehtoa ei tarvitse alkaa etsiä vasta siinä vaiheessa, kun nykyinen ratkaisu on jo poistumassa.

Tarkista ainakin: mille kriittisille palveluille ei ole tunnistettu vaihtoehtoa, kuinka nopeasti korvaava ratkaisu voitaisiin ottaa käyttöön ja vaatisiko vaihto muutoksia sovelluskoodiin tai integraatioihin.

7. Säilyykö kokonaisuuden omistajuus omassa organisaatiossa?

Kaikkea infrastruktuuria tai ylläpito-osaamista ei ole järkevää pitää omassa organisaatiossa. Hallitut palvelut ja kumppanit voivat olla kustannusten, osaamisen ja tehokkuuden näkökulmasta selvästi parempi ratkaisu kuin kaiken tekeminen itse.

Ulkoistaa voi tekemistä, mutta kokonaisuuden ymmärrystä ei pitäisi ulkoistaa kokonaan. Asiakkaan pitäisi tietää, mistä ympäristö koostuu, mitkä järjestelmät ovat kriittisiä, miten eri kumppanit liittyvät kokonaisuuteen ja kuka pystyy tekemään päätöksiä silloin, kun arkkitehtuuria pitää muuttaa. Muuten toimittajan vaihtaminen voi alkaa tilanteesta, jossa kukaan asiakkaan puolella ei tiedä tarkasti, mitä ollaan siirtämässä.

Tarkista ainakin: kuka omistaa kokonaisarkkitehtuurin, missä keskeinen tekninen tieto sijaitsee ja pystyykö organisaatio arvioimaan kumppanien ehdottamia ratkaisuja myös itse.

8. Arvioidaanko teknologiavalintoja jatkuvasti vai vasta ongelman tullessa?

Pilviympäristö ei pysy muuttumattomana sopimuksen tai arkkitehtuuripäätöksen jälkeen. Palveluntarjoajat muuttavat palveluvalikoimiaan ja hinnoitteluaan, teknologiat kehittyvät, lisenssimallit vaihtuvat ja organisaation omat tarpeet muuttuvat. Myös uusi AI-palvelu tai muu nopeasti käyttöön otettu teknologia voi synnyttää uusia riippuvuuksia ennen kuin niitä ehditään kunnolla tunnistaa.

Siksi exit-valmiutta ei kannata tarkastaa vain silloin, kun kilpailutus tai migraatio on jo käynnissä. Riippuvuuksien, kustannusten, palveluiden elinkaaren ja vaihtoehtoisten ratkaisujen seuraamisen pitäisi olla osa normaalia arkkitehtuurin hallintaa. Pienet korjausliikkeet ovat yleensä helpompia kuin vuosien aikana kertyneen kokonaisuuden purkaminen kerralla.

Tarkista ainakin: milloin riippuvuudet on viimeksi arvioitu, kuka seuraa palveluiden ja teknologioiden muutoksia ja miten havainnot viedään osaksi roadmapia ja päätöksentekoa.

Kuinka monta kohtaa pystyt vastaamaan varmasti?

Jos jokaiseen kahdeksaan kohtaan löytyy selkeä vastaus, organisaatiolla on jo varsin hyvä lähtökohta muutosten hallintaan. Jos useamman kohdalla vastaus on epäselvä, kyse ei välttämättä tarkoita akuuttia ongelmaa, mutta se kertoo, missä ympäristön ymmärrystä kannattaa seuraavaksi parantaa.

Tavoite ei ole rakentaa pilviympäristöä, josta voi poistua ilman minkäänlaista kustannusta tai työtä. Tavoite on tietää, mihin on sitouduttu ja säilyttää riittävä kyky muuttaa suuntaa silloin, kun liiketoiminta sitä edellyttää.

Haluatko arvioida pilviarkkitehtuurisi riippuvuuksia ja vaihtoehtoja?