Codenton yhteisöblogi: Digitalisaation kuusi sudenkuoppaa – ja miten ne välttää

Codenton yhteisöblogi: Digitalisaation kuusi sudenkuoppaa – ja miten ne välttää

By Codenton konsultit

 

Johdanto

Me codentolaiset olemme ahkeroineet viimeiset kuukaudet erilaisissa digitalisaatiohankkeissa konsultteina ja kohdanneet kymmeniä erilaisia asiakastilanteita. Samalla olemme pysähtyneet huomaamaan, kuinka paljon näillä työmailla kohdataan samoja sudenkuoppia, jotka olisivat voitu välttää etukäteen.

Codenton kaltaisen konsulttiyrityksen elämäntehtävä lienee kaksijakoinen näkemyksen tuottaminen asiakkaidemme suuntaan: yleisesti havaittujen onnistumisten toistaminen ja vastaavasti sudenkuoppien välttäminen.

Vältettävissä oleviin toistuviin sudenkuoppiin ajautuminen aiheuttaa aina todella paljon pettymyksiä ja turhautumista ja pysähdyimmekin näin kesää vasten koko Codenton konsulttiporukan kanssa yhdessä pohtimaan ja kokoamaan omia ajatuksiamme erityisesti näiden sudenkuoppien välttämiseksi.

Syntyi elävä ja monitahoinen yhteisöllinen ajatustenvaihto,  joka meidän oman kokemuksen ja näkemyksen pohjalta tiivistyi kuuteen juurisyyhyn ja kokonaisuuteen:

  1. Lähdetään ratkaisemaan alunperin väärää ongelmaa
  2. Jäädään olemassaolevien sovellusten ja infrastruktuurin vangiksi
  3. Jäädään nykyisten toimintamallien vangiksi
  4. Ei hyödynnetä optimaalisesti uusien pilviteknologioiden mahdollisuuksia
  5. Dataa ei hyödynnetä liiketoiminnassa riittävästi
  6. Koneoppimisen ja tekoälyn hyödyntämisellä ei kehitetä kilpailuetua

Käydään seuraavaksi yhdessä Codenton konsulttien kanssa tätä mielenkiintoista vuoropuhelua läpi.

 

Suodenkuoppa 1: Lähdetään ratkaisemaan alunperin väärää ongelmaa

Kuinkakohan monta Design Sprinttiä ja MVP:ta on maailmassa toteutettu uusien ratkaisuiden luomisessa niin, että alkuperäinen ongelmanasettelu ja asiakastarve on perustunut vääriin oletuksiin tai muuten ollut puutteellinen?

Tai että moni liiketoiminnalille arvokkaampi ongelma on jäänyt ratkaisematta, kun ne ovat jääneet jonossa varasijille? Teknologiavalinta esimerkiksi valmistustuotteen tai räätälöidyn ohjelmiston välillä on puolestaan usein se helpoin vaihe.

Vikaa ei sinänsä ole Design Sprint- tai Minimum Viable Product -metologiassa: nehän soveltuvat erittäin hyvin epävarmuuteen ja kokeilevaan lähestymiseen ja turhan tuotantokelpoisen työn välttämiseen, mutta parannettavaa on varmasti siinä mihin ongelmiin niitä sovelletaan.

Veera muistelee erästäkin tilannetta: “Aletaan ratkoa ongelmaa MVP-henkisesti miettimättä kovin pitkälle, miten sovelluksen pitäisi toimia erilaisissa käyttötapauksissa. Sovelluksesta voi tulla kokoelma erilaisia erikoistapauksia ja yhdistävä tekijä niiden välillä jää puuttumaan. Myöhemmin voidaan joutua tekemään isoja remontteja, kun alkuperäinen arkkitehtuuri tai tietomalli ei kanna riittävän pitkälle.”

Markku luettelee sujuvasti tyypillisä ongelmia, jotka liittyvät konseptointi- ja MVP-vaiheeseen: “Tietty jäykkyys nopeassa ja jatkuvassa kokeilussa, taipumus täydellisyyteen, loppuasiakkaan väärin ymmärtäminen, väärä teknologia tai toimintamalli.”

“Oma ratkaisutapani on aina pienentää ongelman määritys niin pieneksi osaongelmaksi, että sen ratkaiseminen on nopeampaa ja oppiminen tehokkaampaa. Samalla positiivinen tunnelma kasvaa, kun saadaan aina aikaan jotain näkyvää.”, Anthony täydentää.

Toni näkee kolme olennaista vaihetta ratkaisuksi: “Tarvitaan paljon erilaisia ongelmakandidaatteja. Valitaan niistä yhteisillä kriteereillä yksi kirkastettavaksi. Työstetään ongelmanmääritystä sekä laaja-alaisesti että syvälle. Vasta tämän jälkeen kannattaa lähteä Design Sprintttiin.”

 

Suodenkuoppa 2: Jäädään olemassaolevien sovellusten ja infrastruktuurin vangiksi

Helppoahan se on “greenfield”-hankkeissa, joissa “pöytä on puhdas”, mutta mitä tehdä silloin, kun kunnianhimoisen digivision esteenä on vuosikausien pölyttynyt sovellus- ja IT-ympäristö?

Olli-Pekka aloittaa: “Softahan ei ole valmis ennen kuin se poistetaan tuotannosta. Siihen asti siihen uppoaa enemmän tai vähemmän rahaa, joka olisi kiva saada takaisin joko säästettynä työaikana, tai sitten ihan suoraan tuloina. Jos tuotannossa olevia järjestelmiä ei pidetä kehityksen kyydissä, niin niihin uppoavat kulut ohittavat taatusti niistä saatavat hyödyt ennemmin tai myöhemmin. Tästä pitää huolen inflaatio ja teknologian eksponentiaalinen kehitys.”

“Yrityksen liiketoimintaa tukeva todella vanha järjestelmä, jonka korvaus on käytännössä mahdotonta.”, jatkaa Jari T. “Siitä tuleva pieni liikevaihto ja teknologian vanhuus tarkoittaa, että järjestelmää ei kannata korvata. Järjestelmä ajetaan alas kuin viimeiset liiketoiminnan osat on lakkautettu järjestelmästä.”

“Mieleen tulee monoliittinen järjestelmä, jota ei pysty uudistamaan osa kerrallaan. Koko järjestelmän uusiminen taas olisi liian iso kustannus.”, täydentää Veera.

Olli- Pekka hahmottaa kolme erilaista tilannetta: “Käyttäjäkunnasta riippuen paineet modernisoinnille ovat erilaisia, mutta tarve sille ei poistu missään vaiheessa. Otetaanpa muutama esimerkki.

Kuluttajatuotteet – tämän luulisi olevan itsestäänselvää. Antiikkituotteille ei tällä alalla ole markkinoita, ellei liiketoimintasi perustu NFT:iden myyntiin Doomin alkuperäisestä lähdekoodista, eikä silloinkaan. Vai milloin olet viimeksi ihastellut Win-XP:n romppuja kaupan hyllyssä?

Yritystuotteet – vähän monimutkaisempi tapaus. Tässä hommaa hoputtaa se, että jotta käytettävä järjestelmä olisi liiketoiminnan kannalta oleellinen, sen on syytä pelata kiltisti yhteen muiden organisaation käytössä olevien järjestelmien kanssa. Muussa tapauksessa sille kyllä arvotaan korvaaja, koska manuaaliset stepit prosessissa ovat sekä kalliita, että virhealttiita. Ongelmaa ei tosin ole, mikäli kukaan ei päivitä tuotteitaan. En tuudittautuisi tämän varaan.

Sisäinen käyttö – näitähän ei tarvitse modernisoida? Tässä riittää vain, että koulutat itse uudet osaajat poistuvien tilalle, koska kukaan muu ei sitä sinun stackillesi enää tee. Muista myös toivoa, että kaikki ne, jotka onnistut tähän teknologiseen umpikujaan houkuttelemaan, eivät keksi ryhtyä kurkkimaan aidan yli. Ja muista myös varata hieman ylimääräistä valuuttaa ylläpitosopimuksiin, koska ulkopuoliset toimittajat saattavat nostaa hintojaan kun käyttäjämäärät heidän auringonlaskun tuotteilleen tippuvat.”

Iirolle tuli heti mieleen muutamia käsitteitä: “Polkuriippuvuus ja Sunk cost fallacy. Näistähän voisi molemmista kirjoittaa oman blogin?”

“Mitä syitä tai hankaluuksia tulee vastaan eri tutkimuksista?” kysyvät Sami ja Marika.

“Itselleni on mieleen ainakin jäänyt budjettihaasteet, ympäristöjen monimutkaisuus, integraatiokyvykkyyden puute, tietoturva ja lainsäädäntö. Mikä sitten avuksi?”, vastaa ja kysyy Anthony samalla kertaa.

Olli-Pekan kolme ideaa syntyvät nopeasti: “Kartoita järjestelmäsi – tähän kannattaa käyttää myös ulkopuolisia silmäpareja, koska ne osaavat tunnistaa sellaisetkin yksityiskohdat, joihin oma silmä on jo tottunut. Ulkopuolinen asiantuntija osaa myös kysyä oikeita kysymyksiä, sekä onkia näihin vastaukset. Suunnittele reittisi ulos loukusta – harvemmin kannattaa rynnistää sokkona joka suuntaan samaan aikaan. Riittää, että puhkaiset aukon siihen, missä aita on heikoin. Tästä voit sitten lähteä laajentamaan ja rakentamaan uusille laitumille itsellesi sopivaan tahtiin. Investoi osaamiseen – reikä aitaan syntyy helpoiten oikeilla työkaluilla. Ja taitava tekijä puhkaisee aukon niin, että siitä on helppo kulkea jatkossakin repimättä vaatteitaan. Ei kannata tuudittautua siihen, että tämä tekijä löytyisi talosta sisältä, koska jos näin olisi, niin se aukko olisi jo siinä. Tai sitten prosessi mättää. Joka tapauksessa apua tarvitaan.”

 

Suodenkuppa 3: Jäädään nykyisten toimintamallien vangiksi

“Kumpikohan on lopulta isommin esteenä: infrastuktuuri ja sovellukset vai omat toimintamallit ja muutoskyvykkyyden puute?”, pohtii Tommi. 

“Itse kallistuisin toimintamallien suuntaan.”, näkee Samuel. “Siiloutuminen erityisesti liiketoiminnan ja IT:n välillä, riskien ylempalttinen välttäminen, muutoskyvykkyyden puute, ohjaavan digivision epämääräisyys, ja näkemyksen puute tulevat vahvasti itselleni mieleen.” 

Veera täydentää: “Lähdetään mallintamaan vanhoja prosesseja sellaisenaan uuteen sovellukseen, sen sijaan että mietittäisiin, miten prosesseja voisi samalla muuttaa ja saada hyötyä myös paremmista prosesseista.”

Elmo luettelee heti muutamia käytännön esimerkkejä: “Word+Sharepoint-dokumentaatio rajoittaa, koska “näin on toimittu aina”. Muutosvastarinta aiheuttaa sen, että ei voida hyödyntää moderneja toimintatapoja ja uusimpia välineitä ja suljetaan tätä kautta osa kontribuutiosta pois tekemisestä. Tämä rajaa käyttäjäkuntaa, koska ei voida käyttää organisaation rajat ylittävää osaamista.”

Anne jatkaa: “Excel+word-dokumentaatiomallit johtavat siihen, että tieto on levällään ja ylläpito vaikeaa. Sähköpostitse tiedon kulku. Suurin este kulttuuri ja tekemisen tapa, ei tekniikka itsessään.”

“Mitä pitäisi tehdä ja mistä saada motivaatio?”, pohtii puolestaan Perttu ja jatkaa ratkaisuehdotuksella: “Pieniä voittoja nopeasti – matalalla roikkuvat hedelmät olisi poimittava. Mitä pidempään jatkaa tehotonta toimintaa, sitä kalliimpaa sieltä pois pääseminen. Sunk Cost Fallacy tulee ajatusvinoumana myös mieleen.”

“Parannettavia toimintamalleja on rajattomasti.”, Markku avaa vaihtoehtojen kirjoa: ”Liiketoimintayhteistyö, tuotehallinta, sovelluskehitys, DevOps, testaus, integraatio, tuotantoonsiirto, jatkokehitys, johtaminen, resursointi, alihankinta, työkalut, prosessit, dokumentaatio, mittarit. Kaikessa ei tarvitse olla maailmanluokkaa, mutta on hyvä parantaa osa-aluetta tai osa-alueita, joilla saadaan isoin vaikuttavuus optimaalisella panostuksella.”

 

Sudenkuoppa 4: Ei hyödynnetä uusien pilviteknologioiden mahdollisuuksia

Google Cloud, Azure, AWS vai monipilvi? Onko tämä keskeisin kysymys?

Markku vastaa: “Mielestäni ei. Talousohjauksen mittarit siirtävät pilvikulut pois poistojen puolelta suoraan ylemmäksi tuloslaskelman rivejä ja tähän ei monen yrityksen tavoiteasetanta taivu, vaikka todellisuudessa kassavirtaan saatisi pidemmällä aikavälillä paljon positiivista vaikutusta.”

Sannalle tulee mieleen muutamia vastaantulleita tilanteita: “Valitaan teknologia, jonka uskotaan sopivan parhaiten omaan tarpeeseen. Tämä siksi, ettei ole tarpeeksi kattavaa tietoa ja kokemusta olemassa olevista teknologioista ja niiden mahdollisuuksista. Siksi saatetaan päätyä tilanteeseen, jossa valitun teknologian päälle on jo rakennettu paljon logiikkaa ja ominaisuuksia kun huomataan, että jokin toinen malli olisi sopinut käyttötapaukseen paremmin.  Kokemus tosielämästä: “näillä funktioillahan tämän saa toteutettua näppärästi”,  kaksi vuotta myöhemmin: “miksi ihmeessä ei valittu IoT-hubia”.” 

Perttu korostaa: ”Lähempänä jokapäiväistä bisnestä muuallakin kuin pilviteknologian kylmässä ja teknisessä ytimessä löytyy esimerkkinä digitaalisten alustojen käyttö työskentelyssä (esim. drive, meet, teams jne). Varsinkin, kun viimeaikoina julkinen keskustelu on pyörinyt muutaman ison firman ohjeistusten, joissa käskytetään työntekijät takaisin lähityöhön, ympärillä.”

Perttu jatkaa: “Tähän verraten digitaalisten alustojen tarjoamat palvelut tekevät toiminnasta ketterämpää ja mahdollistavat suuremman kirjon elämäntyylejä sekä kaiken lisäksi tehostavat liiketoimintaa. Muistettava tietysti, että fyysiset kohtaamiset ovat myös tärkeitä ihmisille, mutta voitaneen olettaa, että minkä tahansa alan asiantuntijat ovat parhaita määrittelemään itse tehokkaat työskentelyn tavat. Win-win, eikö?”

Mikä sitten ratkaisuksi?

“Minusta tärkeintä on, että pilvikyvykkyyksien käyttöönotettavat ominaisuudet sovitetaan valittuihin lyhyen ja pitkän aikavälin käyttötapauksiin”, summaa Markku.

 

Sudenkuoppa 5: Dataa ei hyödynnetä liiketoiminnassa riittävästi

Ei taida olla juuri yrityksiä, jotka voivat välttää, että heillä on pääosa datastaan hyvin hallussa ja eheää? Mutta millaisia erilaisia haasteita tähän liittyy?

Aleksi pohjustaa: “Datan laajemman hyödyntämisen käytännön esteenä on  organisaatiossa melko usein huono näkyvyys saatavilla oleviin datoihin. Saattaa löytyä monia piilossa lymyäviä datajoukkoja, joiden olemassaoloa ei tunne kuin pari ihmistä. Nämä saattavat olla löydettävissä ainoastaan sattumalta keskustelemalla oikeiden ihmisten kanssa.

Toinen samankaltainen ongelma on, että joidenkin datajoukkojen osalta datan sisältöä, rakennetta, alkuperää tai syntymistapaa ei enää nykytilanteessa oikeasti tunne kukaan – ja  mitään dokumentaatiota asiasta ei juurikaan ole.”

Aleksi jatkaa, “Liian ehdoton ja varhaisessa vaiheessa sovellettava business case -lähestyminen estää datan hyödyntämisen kokeilun ja kehittämisen tapauksissa, joissa mukana on ”tutkimuksellinen aspekti”. Näin on esimerkiksi monissa uusissa koneoppimisen tapauksissa: etukäteen ei ole selvillä mitä on odotettavissa, tai edes saadaanko aikaiseksi mitään hyödynnettäväksi kelpaavaa. Näin ollen tällaista varhaista tekemistä on vaikea perustella tavanomaisen business casen avulla.

Parempi voisi olla arvioida mahdollisia hyötyjä, joita lähestymisellä voisi onnistuessaan olla. Jos nämä hyödyt ovat riittävän suuret, voi lähteä kokeilemaan, tarkastella tilannetta jatkuvasti kriittisesti ja torpata huonoksi osoittautuvat ideat nopeasti. Business casen aika voi olla myöhemmin.”

 

Sudenkuoppa 6: Koneoppimisen ja tekoälyn hyödyntämisellä ei kehitetä kilpailuetua

Taitaa olla nykyaikana muotia, että liikkeenjohtaja osallistuu erilaisille koneoppimisen kursseille ja organisaatioissa on käynnissä vaihteleva määrä kokeiluja. Vielä ei kuitenkaan olla kovin pitkällä, vai ollaanko?

Aleksi avaa kokemuksiaan: “Nykyinen ”perinteisellä tavalla” toteutettu toimintamalli on ajan saatossa viilattu jo melko hyväksi, ja parannuspotentiaalia on jäljellä hyvin rajallisesti. Ensimmäiset koneoppimisen kokeilut eivät tuota nykyistä parempaa lopputulosta, joten niiden tarkastelu ja kehittäminen päätetään lopettaa. Monesti tilanne näissä saattaa olla kuitenkin se, että nykyisen toimintamallin mahdollistama potentiaali on ajan saatossa ulosmitattu lähes täysin, kun taas koneoppimisen puolella parannuspotentiaali yltäisi huomattavasti korkeammalle tasolle. Jäädään ikään kuin lukkoon nykyiseen tapaan vain, koska ensimmäiset yritykset eivät heti tuoneet parannusta.”

Anthony tiivistää haasteet kolmeen kokonaisuuteen: “Liiketoiminta-arvo on epäselvä, data ei ole saatavilla eikä osaamista koneoppimisen hyödyntämiseen ole riittävästi.”

Jari R. haluaa mainostaa omaa aiempaa puheenvuoroaan kevään liiketoimintalähtöisen koneoppimisen online- tapahtumassa. “Jos nyt muistan oikein niin kokosin juuri tähän aiheeseen sovelutuvaa listan peräti kymmenestä sudenkuopasta. Tässä tapahtumamateriaalissa ne ovatkin sujuvasti luettavissa:

  1. Konkreettista liiketoimintaan liittyvää ongelmaa ei määritellä kunnolla. 
  2. Mallin luotettavuudelle ei määritellä tavoitetta tai tavoite on epärealistinen.
  3. Datalähteiden valinta jätetään data scientistien ja engineerien tehtäväksi eikä liiketoiminta-alueen asiantuntijoiden osaamista hyödynnetä.
  4. ML-projekti toteutetaan yksinomaan IT-osaston omin voimin. Liiketoiminta-alueen asiantuntijoita ei osallisteta projektissa.
  5. Mallin rakentamiseen ja hyödyntämiseen tarvittavat datat pidetään sirpaleisena eri järjestelmissä eikä pilvialustojen dataratkaisuja hyödynnetä.
  6. Mallin uudelleenkoulutettavuutta pilvialustalla ei oteta huomioon jo kehitysvaiheessa.
  7. Malliin valitaan mahdollisimman muodikkaat algoritmit. Algoritmien tarkoituksenmukaisuutta ei pohdita.
  8. Mallin tekemien virheiden juurisyitä ei analysoida vaan luotetaan sokeasti tilastollisiin tarkkuusparametreihin.
  9. Mallin rakennetaan toimimaan data scientistin omalla koneella eikä sen siirrettävyyttä pilvialustalle mietitä kehitysvaiheessa.
  10. Mallin kykyä analysoida oikeaa liiketoimintadataa ei seurata systemaattisesti eikä mallia uudelleenkouluteta.”

Tämä toimineeksin hyvänä esimerkkinä data scientistin perinpohjaisuudesta. Tuohon listaan on helppo yhtyä ja uskoa, että meiltä codentolaisilta löytyy näkemystä sudenkuoppien välttämiseen tälläkin alueella.

 

Yhteenveto – Vältä sudenkuopat ajoissa

Sudenkuoppiin putoamisen ennaltaehkäisyksi Codenton konsultit ovat luvanneet tarjota kahden tunnin veloituksettomat työpajat halukkaille organisaatioille aina yhteen näistä sudenkuopista kerrallaan keskittyen:

  • Digiarvotyöpaja: Täsmennetty ja ymmärrettävä liiketoimintaongelma ratkaistavaksi konseptointivaiheeseen
  • Sovellusuudistustyöpaja: Priorisoitu etenemiskartta sovellusten modernisoinnissa
  • Toimintamallityöpaja: Potentiaalisten toimintamallihaasteiden tunnistaminen arviointivaihetta varten
  • Pilviarkkitehtuurityöpaja: Auttaa tunnistamaan konkreettiset askeleet kohti laadukasta pilviarkkitehtuuria ja sen jatkokehittämistä
  • Data-arkkitehtuurityöpaja: Alustava data-arkkitehtuurin nykytilanne ja potentiaaliset kehityskohteet jatkosuunnittelua varten
  • Tekoälyarvotyöpaja: Priorisoidut käyttötapauskuvaukset liiketoiminnan toteutettavuuden näkökulmasta tarkempaan suunnitteluun

 

Kysy meiltä lisää ja varataan aika jo elokuulle, niin syksy lähtee mukavasti käyntiin sudenkuoppia vältellen.

#NEXTGENCLOUD: Yhden vai usean pilven taktiikalla – liiketoimintalähtöinen asiantuntijablogi

#NEXTGENCLOUD: Yhden vai usean pilven taktiikalla – liiketoimintalähtöinen asiantuntijablogi

Author: Markku Tuomala, CTO, Codento

 

Tausta pilvitaktiikan valitsemiselle

Perinteisesti organisaatioissa on arkkitehtuuria valittaessa päädytty keskittämään kaikki voimat yhden julkisen pilven ratkaisuihin. Taustalla on ollut usein ajatus kapasiteettipalveluiden tehokkuuden optimoimisesta. Käytännössä tämä tarkoittaa olemassa olevien sovellusten siirtämistä maksimaalisesti pilveen –  ilman sovellusarkkitehtuurin muutoksia.

Tavoitteena on keskittää volyymi yhdelle pilvipalveluiden toimittajalle ja sitä kautta saavuttaa mahdollisimman suuri hyöty infrapalveluiden operoinnista ja palvelukustannuksista.

 

Merkittävimmät käyttötapaukset

Marraskuun 2021  #NEXTGENCLOUD -online tapahtumassamme keskityimme seuraavan sukupolven pilven kyvykkyyksiin ja millaisia liiketoimintahyötyjä voi saavuttaa jo lyhyessäkin ajassa. #NEXTGENCLOUD-ajattelussa katse käännetään asiakkaan tarpeen ratkaisemiseen sopivimmilla työkaluilla.

Tästä näkökulmasta jakaisin merkittävimmät käyttötapaukset seuraavasti katergoriaa:

  1. Uusien palveluiden kehittäminen
  2. Sovellusmodernisoinnit

Tarkastelen näitä seuraavaksi tarkemmin.

 

Uusien palveluiden kehittäminen

Uusien palveluiden kehittämisessä lähdetään liikkeelle kokeilemalla, palvelun tulevia käyttäjiä aktivoimalla ja iteratiivisella oppimisella. Jo nämä teemat sinällään aiheuttavat arkkitehtuurin suunnitttelulle mielenkiintoisen haasteen, jossa suunta ja päämäärä saattavat muuttua hyvinkin nopeasti oppimisen myötä.

On tärkeää, että arkkitehtuuri tukee laajamittaisesti valmiiden kyvykkyyksien käyttöönottamista, kasvattaa palvelun autonomiaa ja varmistaa käyttäjille entistä paremman käyttökokemuksen. Usein näissä ratkaisuissa päädytään käyttämään useamman julkipilven valmiita kyvykkyyksiä, jotta tuloksiin päästäisiin nopeammin. 

 

Sovellusmodernisoinnit

Pilvet on rakennettu toisistaan poikkeavilla tavoilla. Erot eivät rajaudu vain teknisiin yksityiskohtiin, vaan käsittävät myös hinnoittelumallit sekä muita käytäntöjä. IT-ympäristössä toimivien sovellusten erilaiset tarpeet tekevät lähes mahdottomaksi ennustaa mikä pilvi sopii liiketoimintatarpeille sekä sovelluksille optimaalisesti. Tästä seuraa se että oikea tarve määräytyy yksittäisen liiketoimintatarpeen tai sovelluksen perusteella, joka yhden pilven toimintaympäristössä tarkoittaa tarpeettomia kompromisseja sekä teknisesti epäoptimaalisia valintoja. Nämä konkretisoituvat kustannustehottomuutena sekä kehityksen hitautena. 

IT-ympäristöjen sovellusmodernisoinnissa kannattaa jo suunnitteluvaiheesta alkaen maksimoida eri pilvipalveluiden hyödyt kompromissien välttämiseksi, sujuvan käyttökokemuksen varmistamiseksi, autonomian kasvattamiseksi, tuotannollisen riskin hajauttamiseksi sekä tulevaisuuden liiketoiminnan tarpeiden tukemiseksi. 

 

Pullonkaulana osaaminen?

Löytyykö kaikkeen tähän osaamista, onko useamman pilven teknologian osaaminen suurin este?

Sovellusarkkitehdeille ja ohjelmistokehittäjille on normaalia opetella useampia ohjelmointikieliä siinä missä lääkäreiden tai sairaanhoitajien uusia hoitomenetelmiä. monipilviteknologioiden osaamisen kehittymisessä pätevät samat lainalaisuudet. Tänä päivänä jo yhä useampi meistä on työskennellyt useamman pilviteknologian kanssa ja hyödyntänyt valmiita palveluita. Samalla teknologia useampien pilvien hallintaan on kehittynyt merkittävästi, joka helpottaa niin kehitystoimintaa kuin pilvien operointiakin.

 

Artikkelin kirjoittaja, Markku Tuomala, CTO, Codento. Markulla on 25 vuoden kokemus ohjelmistokehityksestä ja pilvestä, työskenneltyään Suomen johtavalla teleoperaattorilta Elisalla. Markku vastasi Telco- ja IT-palveluiden pilvistrategiasta ja kuului Elisan tuotannon johtoryhmään. Keskeisiä tehtäviä olivat Elisan ohjelmistostrategia ja liiketoimintakriittisten IT-ulkoistusten operatiivisten palveluiden johtaminen. Markku ajoi asiakaslähtöistä kehitystä ja oli avainasemassa liiketoiminnan kasvussa, palveluiden kuten Elisa Viihde, Kirja, Lompakko, itsepalvelu ja verkkoautomaatio parissa. Markku johti myös Elisan konesalitoimintojen muutosta DevOpsiin. Markku toimii Codenton Value Discovery -palveluiden senior-tason konsulttina.

 

Kysy meiltä lisää:

#NEXTGENCLOUD, Osa 2. Tulevaisuuden pilvi – oikeilla valinnoilla pitkäjänteistä kilpailukykyä

#NEXTGENCLOUD, Osa 2. Tulevaisuuden pilvi – oikeilla valinnoilla pitkäjänteistä kilpailukykyä

Author: Jari Timonen, Codento Oy

# NEXTGENCLOUD – tulevaisuuden pilvi – on viitekehys, jonka varaan me Codentolla uskomme asiakkaidemme pitkäjänteisen menestyksen rakentuvan.

Valtavirtatoimittajien pilvikyvykkyyksien kehittyessä kiihtyvällä vauhdilla on äärimmäisen tärkeää ottaa näiden uusien ominaisuuksien tuomat mahdollisuudet huomioon oikeita valintoja tehtäessä ja suunnitelmia kirkastettaessa.

Me Codentolla koemme tämän osa-alueen näkemyksen kehittämisen olevan keskeinen roolimme. Yhteistyössä teknologiatoimittajien ja asiakkaiden kanssa tuemme asiakkaiden liiketoimintaa sekä mahdollistamme sovellusinnovaatiot ja -modernisoinnin.

Kaksiosaisessa blogisarjassamme ja tulevassa #NEXTGENCLOUD-tapahtumassa avaamme keskeisiä näkemyksiämme.

  • Osa 1: Tulevaisuuden pilvi: liiketoimintanäkökulmia (julkaistu 17.11.)
  • Osa 2: Tulevaisuuden pilvi: Oikeilla valinnoilla pitkäjänteiseen kilpailukykyyn

Tässä blogissa pohdimme miten tulevaisuuden pilven arkkitehtuuri mahdollistaa pitkäjänteisen kilpailukyvyn.

Tavoitearkkitehtuuri on kaiken uuden tukirakenne

Taloissa on kantavat seinät ja erikseen kevyemmät rakenteet perustelluista syistä. Millaisia rakenteita tarvitaan pilviarkkitehtuureissa?

Toimivien rakenteiden valintoja ohjaavat seuraavat tekijät.

  • Toiminnallisen kerrosten tunnistaminen
  • Käyttötarkoitukseen soveltuvien palveluiden valinta
  • Löyhä integrointi kerrosten välillä
  • Kattava tietoturva

Kunkin julkisen pilven toimittajan kyvykkyyksien mukaan voidaan määritellä omanlaisensa tavoitearkkitehtuuri. Monipilviratkaisuissa vastaavasti usean eri pilven kyvykkyyksien mukainen monipilviarkkitehtuuri.

Google Cloud -teknologioita hyödyntävässä tulevaisuuden arkkitehtuurissa tulisi huomioida seuraavat neljä osaa:

  • Tiedon tuonti ja prosessointi (Ingestion and processing)
  • Tiedon tallennus (Data Storage)
  • Sovellukset (Applications)
  • Analytiikka ja raportointi (Analytics, Reporting and Discovery)

Jokaisessa osassa on käytettävissä useita eri vaihtoehtoisia ja toisiaan täydentäviä pilvipalveluita, jotka ratkaisevat erilaisia liiketoiminta- ja teknisiä haasteita. Huomionarvoista arkkitehtuurissa on, että mikään palvelu ei ole toisiin palveluihin nähden keskeisessä tai alisteisessa roolissa.

Tulevaisuuden pilven ratkaisut ja palvelut ovat osa kokonaisarkkitehtuuria. Mahdollisesti poistuvat tai korvattavat palvelut eivät aiheuta laajamittaista muutostaakkaa kokonaisarkkitehtuuriin.

Uuden sukupolven pilvi mahdollistaa laskennan pilven reunalla (edge computing)

Suunniteltaessa tavoitearkkitehtuuria pitää ottaa huomioon pilven tarjoamat kyvykkyydet hajauttaa laskentaa ja tiedon tallennusta lähemmäksi tiedon kuluttajaa tai käyttäjää.

Internetin alkuaikoina sovelluskoodia ajettiin pelkästään palvelimilla. Tämä sai aikaan skaalautuvuushaasteita käyttäjämäärien kasvaessa. Myöhemmin sovellusarkkitehtuureja uudistettaessa sovelluksen osia jaettiin eri tietokoneille, eritoten käyttöliittymien osalta. Tämä helpotti palvelimien skaalautuvuutta sekä vähensi suunnittelemattomien käyttökatkosten riskiä. Suurin osa käyttäjälle näkyvästä sovelluskoodista suoritetaan puhelimilla, tableteilla tai tietokoneilla, kun taas liiketoimintalogiikka suoritetaan pilvessä.

Samankaltainen murros on tapahtumassa nyt pilven laskentakapasiteetissa.

Tulevaisuudessa kaikkia työkuormia ei ajeta pelkästään pilvipalveluiden suurissa palvelukeskuksissa, vaan niitä ajetaan myös lähempänä asiakasta. Esimerkkejä tällaisista ratkaisuista ovat mm. analytiikka-, koneoppimis- ja muuta laskentatehoa vaativat sovellukset, kuten esineiden Internet (Internet of Things).

Osa sovelluksista vaatii niin alhaista latenssia, että se edellyttää laskentatehoa lähellä asiakasta. Konesalin läheinen maantieteellinen sijainti ei välttämättä riitä vaan tarvitaan paikallista laskentakapasiteettia reunalaskentaan.

Pilven älykkäät ominaisuudet mahdollistavat uusia sovelluksia

Pilvi on kehittynyt alun kustannuksia ja kapasiteettia optimoivasta virtuaalikonekeskeisestä ajattelumallista kohti älykkäämpiä palveluita. Näiden älykkäiden palveluiden käyttäminen mahdollistaa keskittymisen olennaiseen, eli liiketoiminta-arvon tuottamiseen. Uuden sukupolven pilven kyvykkyyksien ja palvelujen kehitys tulee kiihtymään tulevaisuudessa.

Yhä laajemmin tulemme näkemään ja hyödyntämään pilvinatiiveja älykkäitä sovelluksia, jotka hyödyntävät tehokkaasti uuden sukupolven pilven kyvykkyyksiä verkon reunalta keskitettyihin palveluihin saakka.

Tämä mahdollistaa modernien tietoliikenneratkaisujen kanssa asiakkaille aivan uudenlaiset palvelut, joiden arkkitehtuuri kantaa pitkälle tulevaisuuteen. Esimerkkeinä laaja tuki Teollisuus 4.0:n reaaliaikaisuusvaatimuksille, itseohjautuvat autot, uudet terveydenhuollon palvelut tai todenmukainen virtuaalikokemus.

Kestävä ja uusiutuva pilviarkkitehtuuri, reunalaskennan hyödyntäminen ja älykkäiden palveluiden käyttö ovat kaikki osana #NEXTGENCLOUD-viitekehystämme.

Blogin kirjoittaja Jari Timonen on kokenut ohjelmistoalan ammattilainen, jolla on yli 20 vuoden kokemus tietotekniikka-alalta. Jarin intohimo on luoda siltoja liiketoiminnan ja teknisten tiimien välille, jossa hän on toiminut esimerkiksi Cargotecin edellisessä tehtävässään. Codentossa hän on elementissään luotsatessaan asiakkaita kohti tulevaisuuden kanssa yhteensopivia pilvi- ja hybridipilviympäristöjä.

#NEXTGENCLOUD Osa 1. Tulevaisuuden pilvi – ohituskaista liiketoimintahyötyihin?

Osa 1. Tulevaisuuden pilvi – ohituskaista liiketoimintahyötyihin?

Author: Jari Timonen, Codento

#NEXTGENCLOUD – tulevaisuuden pilvi – on viitekehys, jonka varaan me Codentolla uskomme asiakkaidemme pitkäjänteisen menestyksen rakentuvan.

Valtavirtatoimittajien pilvikyvykkyyksien kehittyessä kiihtyvällä vauhdilla on äärimmäisen tärkeää ottaa näiden uusien ominaisuuksien tuomat mahdollisuudet huomioon oikeita valintoja tehtäessä ja suunnitelmia kirkastettaessa.

Me Codentolla koemme tämän osa-alueen näkemyksen kehittämisen olevan keskeinen roolimme. Yhteistyössä teknologiatoimittajien ja asiakkaiden kanssa tuemme asiakkaiden liiketoimintaa sekä mahdollistamme sovellusinnovaatiot ja -modernisoinnin.

Kaksiosaisessa blogisarjassamme ja tulevassa #NEXTGENCLOUD-tapahtumassa avaamme keskeisiä näkemyksiämme

  • Osa 1: Tulevaisuuden pilvi: ohituskaistaa liiketoimintahyötyihin?
  • Osa 2: Tulevaisuuden pilvi: teknologian avulla pitkäjänteistä kilpailukykyä?

Tässä blogissa pohdimme miten tulevaisuuden pilvi mahdollistaa liiketoimintahyötyjen saavuttamisen nopeasti.

Liikkeellelähdössä avarakatseisuus on arvokasta

Pilvipalveluihin liittyvien liiketoimintanäkökulmien pohdinta vaatii monitasoista tarkastelua. Tässä pohdinnassa yhdistyvät tavoiteltavat liiketoimintahyödyt, sovellusten ominaispiirteet ja eri sidosryhmien toimintatavat ja tavoitteet.

Kuinka yhdistää nopea innovaatioiden hyödyntäminen kustannustehokkuuden parantamiseen? Oikeiden valintojen ja toteutusten kautta voidaan uutta liiketoimintaa tukea ja kehittää sekä nopeammin että tehokkaammin. Sovellusten näkökulmasta kyse on teknisen pilvialustan kyvykkyyksistä mahdollistaa tavoiteltavat hyödyt. Prosessien ja toimintatapojen näkökulmasta tavoitteena on läpinäkyvyys, joustavuus, automaatio ja skaalautuvuus.

Tukevaisuuden pilven hyödyt vaativat pilvikyvykkäitä sovelluksia

Liiketoiminnalle tärkeiden sovellusten modernisointi on keskeinen toimenpide liiketoimintahyötyjen saavuttamisessa.

Moni asiakas ei ole täysin saavuttanut tavoittelemiaan pilven hyötyjä ensimmäisen sukupolven pilviratkaisuissa. Osa pettymyksistä liittyy ns. lift-and-shift -typpiseen pilvisiirtymään, jossa sovellukset on siirretty lähes sellaisenaan pilveen. Tällöin lähes ainoa mahdollinen hyöty löytyy infrastruktuurikustannusten säästöistä.

Pilvikyvykkäät ns. pilvinatiivit sovellukset ovat lähtökohtaisesti ainoa oikea kestävä tie pilven laajojen liiketoimintahyötyjen saavuttamiseksi.

Tukevaisuuden pilven tuki sovelluksille

Tulevaisuuden pilvi tukee liiketoimintasovelluksia monella eri tasolla:

  • Pilvinatiivi, kustannustehokas ajoympäristö
  • Liiketoimintasovelluksia tai niiden osia korvaavat Platform-as-a-Service (PaaS) ja Software-as-a-Service (SaaS) -palvelut
  • Lisäarvotoiminnallisuudet, kuten kustannustehokas analytiikka- ja raportointi

Esimerkkeinä tällaisista liiketoimintasovelluksia tukevista pilviteknologioista ovat mm:

  • Google Cloud Anthos / Google Kubernetes Engine (Hybridi-, moni- ja yksipilviympäristöt)
  • Google Cloud BigQuery (Data Warehouse)
  • Google Data Studio (Raportointi)
  • Google Cloud Looker (Enterprise-tason analytiikka)

Pilvikyvykkyydet ja uusien mahdollisuuksien tunnistaminen

Useimmat organisaatiot ovat rakentaneet ensimmäisen sukupolven pilvikyvykkyytensä yhteen pääpilviteknologiaan perustuen.

Samanaikaisesti vaihtoehtoisten mahdollisuuksien kirjo on kasvanut ja käytännön oppien kautta on syntynyt hyvin nopeasti aiemman rinnalle suunnaksi ns. monipilvi (multi-cloud) -polku.

Molemmat etenemispolut edellyttävät jatkuvaa ja nopeaa uudistumis- ja innovointikykyä  koko organisaatiolta pilven liiketoimintahyötyjen saavuttamiseksi.

Tällä matkalla tarvitaan vankkaa liiketoiminnan tukea. Innovointi tapahtuu kehittäjien, arkkitehtien sekä heitä ohjaavan organisaation roolien yhteistyönä. Mukana olijat tarvitsevat realistiset taloudelliset mahdollisuudet onnistua. Aktiivinen vuorovaikutus eri osapuolien välillä on tärkeää onnistumisen kannalta. On tärkeää luoda kulttuuri, jossa voidaan kokeilla, epäonnistua, kokeilla uudestaan sekä onnistua.

Innovointia tukee ketteristä kehitysmenetelmistä tuttu iteratiivinen prosessi, jonka aikana tehdään hypoteeseja ja testataan niitä. Nämä lopputulokset näkyvät tulevaisuuden käytäntöön viedyissä toiminnallisuuksissa, toimintatavoissa ja tuotteistuksissa.

Tulevaisuuden pilvi ja innovoinnin kolme tasoa

Innovointi pilvessä nyt ja tulevaisuudessa voidaan jakaa karkeasti kolmeen eri osa-alueeseen:

  • Liiketoiminta pitää olla oikea-aikaista, kannattavaa sekä tulevaisuuteen katsovaa. Innovoinnilla luodaan uutta liiketoimintaa tai kiihdytetään nykyistä.
  • Konsepti varmistaa, että olemme tekemässä oikeita asioita. Tämän pitää olla asiakkailla varmistettua ja mahdollisimman oikeaksi todettua. Asiakas tarkoittaa kohderyhmää, joka voi koostua sisäisistä tai ulkoisista käyttäjistä.
  • Tekninen kyvykkyys luo pohjan kaikelle innovaatiolle sekä tulevaisuuden tuotteistamiselle. Kyvykkyys kasvaa ja kehittyy liiketoiminnan mukana joustavasti ja ketterästi.

Tulevaisuuden pilvi tukee edellä mainittuja kolmea polkua vielä tehokkaammin kuin aiemmin. Pilveen kasvaa uusia alusta- sekä API-talouden mahdollistavia palveluita, jotka vähentävät ylläpitoon tarvittavaa aikaa.

Nopein tapa liiketoimintahyötyihin kulkee MVP:n kautta

Pilveen kehittämisen tulee olla merkityksellistä sekä arvoa tuottavaa. Tämä kuulostaa itsestään selvältä, mutta se ei aina ole sitä.

Arvontuotto voi merkitä eri asioita eri ihmisille. Siksi Minimum Viable Product (MVP) -lähestyminen on hyvä tapa aloittaa toteutus. MVP on tapa, jolla kuvataan pienin arvoa tuottava yksikkö mikä voidaan toteuttaa ja viedä tuotantoon. Monesti tässä vanhat ajatusmallit tuottavat ansoja: “Kaikki ominaisuudet pitää olla valmiina, jotta saataisiin hyötyä.” Kuitenkin, jos tuotetta aletaan ”harjaamaan”, niin sieltä löytyy asioita, joita ei tarvita ensimmäisessä vaiheessa.

Näitä voi olla esimerkiksi oman profiilin muutokset, loppuun asti hiotut visuaaliset animaatiot tai laaja lista ominaisuuksia. MVP on hyvä tapa myös validoida omia suunnitelmia ja arvioida sovelluksen arvolupausta.

Pilvi tukee tätä tarjoamalla innovointiin ja kehitykseen työkaluja sekä melkein rajattoman kapasiteetin. Tämä kehitys tulee jatkumaan tulevaisuuden pilvessä antaen uusille sovelluksille paremman mahdollisuuden onnistua tavoitteissaan.

Ja lopuksi

Nopein ja todennäköisin onnistumisen kiihdytyskaista liiketoimintahyötyihin kulkee siis #NEXTGENCLOUD-ajattelun, pilvikyvykkäiden sovellusten ja MVP-toimintamallin kautta.  Blogikokonaisuuden toisessa osassa pohditaan myöhemmin enemmän teknologianäkökulmia ja pitkäjänteisten hyötyjen saavuttamista.

Artikkelin kirjoittaja, Codenton Lead Cloud Architect, Jari Timonen, on kokenut ohjelmistoalan ammattilainen, jolla on yli 20 vuoden kokemus tietotekniikka-alalta. Jarin intohimo on luoda siltoja liiketoiminnan ja teknisten tiimien välille, jossa hän on toiminut esimerkiksi Cargotecin edellisessä tehtävässään. Codentossa hän on elementissään luotsatessaan asiakkaita kohti tulevaisuuden kanssa yhteensopivia pilvi- ja hybridipilviympäristöjä.