Sovellusmodernisointi Archives

Codento Goes FooConf 2023 – kohokohtia ja oppimista

Kirjoittaja: Andy Valjakka, Full Stack -kehittäjä ja arkkitehtikokelas, Codento

Johdanto

Me Codentossa käytämme suurimman osan ajastamme asiakkaidemme konsultointiin. Silloin tällöin syntyy kuitenkin erinomainen tilaisuus saada inspiraatiota laadukkaista konferensseista. Tällä kertaa ryhmä koodaavia konsulttejamme päätti viettää jännittävän päivän fooConf 2023 -tapahtumassa muiden organisaatioiden kollegoiden kanssa.

FooConf 2023: Konferenssi kehittäjiltä kehittäjille

Ensimmäinen fooConf on päättynyt, ja se on tarjonnut osallistujilleen runsaasti tietoa työkaluista, teknologioista ja menetelmistä sekä inspiroivia puheenvuoroja. Saimme kokea erilaisia esityksiä, joissa lähestyttiin kuulijoita eri tavoin: oli ajatuksia herättäviä esityksiä, joissa osallistujille tarjottiin uusia näkökulmia sekä erittäin käytännönläheisiä casejä, jotka havainnollistivat, kuinka oppiminen tapahtuu tekemällä.

Mutta mikä tarkalleen on fooConf? Kuten heidän verkkosivustollaan todetaan, se on konferenssi, joka on ”by Developers by Developers” eli kehittäjien luoma ja kehittäjille tarkoitettu. Toisin sanoen kaikki esitykset on räätälöity ohjelmistoalalla työskenteleville: hyödyllistä sekä käytännöllistä tietoa, jota voidaan soveltaa juuri nyt.

Yleisesti ottaen esitykset jakautuivat kahteen luokkaan:

Eri työkalujen käyttötarkoituksien ja etujen havainnollistamista sekä
tapoja sekä lähestyä ongelmia käytännössä että ajatella niitä uudella tavalla.

Lisäksi pääpuheenvuorot muodostivat oman kolmannen kategoriansa henkilökohtaisesta kasvusta ja itsereflektiosta alan jatkuvasti muuttuvassa turbulenssissa.

Tutustutaan tarkemmin jokaiseen kategoriaan ja katsotaan, mitä niistä löytyy!

Työkalujen loputon valikoima

Ammatissamme ei todellakaan ole pulaa työkaluista, jotka vaihtelevat suhteellisen yksinkertaisista IDE-laajennuksista älykkäisiin avustajiin, kuten GitHub Copilot. Kokemukseni mukaan ammattilaisilla on tapana valita joitain ja tottua niihin, mikä voi vaikeuttaa näkemyksen laajentamista asian suhteen. Ehkä jotkut esitellyistä työkaluista ovat juuri niitä, joita tarvitset nykyiseen projektiisi.

Koska esimerkiksi kontit ja palvelimettomuus ovat tämän hetken trendejä, on meillä paljon opittavaa tällaisten ympäristöjen oikeanlaisesta käytöstä. Abdellfetah Sghiouarin esityksessä The Hitchhiker’s Guide to container security on Kubernetes oli paljon tarjottavaa siitä, miten voidaan varmistaa, etteivät klusterit vaarannu sellaisten uhkien takia kuin suojaamattomat kuvat ja käyttäjät, joilla on liian laajat oikeudet. Erityisesti gVisorin käyttäminen pienten, eristettyjen kernelien luomiseen kontteja varten oli idea, jolle näimme heti käyttöä tosielämässä.

Muita merkittäviä kohokohtia ovat seuraavat:

Erityisesti Java-kehittäjille on tarjolla OpenLiberty – pilvipohjainen mikropalvelukehys, joka on MicroProfilen ajoympäristö. (Cloud-Native Dev Tools: Bringing the cloud back to earth, Grace Jansen.)
GitHub Actions – tapa tehdä DevOpsia kerralla oikein käyttämällä jännittävää matriisistrategiaa, jonka avulla voit määrittää helposti samanlaisia töitä pienillä muunnelmilla. (A Call to (GitHub) Actions!, Justin Lee.)
Palvelimettoman arkkitehtuurin yhteistoiminta vanhan järjestelmän kanssa voidaan tehdä nokkelasti muuntamalla järjestelmän tietoja tapahtumiksi Debeziumin avulla. (A Legacy App enters a Serverless Bar, Sébastien Blanc.)

Ratkottavaa on runsaasti

Ohjelmistojen kanssa työskentely vaatii pohjimmiltaan ongelmanratkaisutaitoja, mikä puolestaan vaatii ideoita, uusia näkökulmia ja toisinaan myös ripauksen hulluutta. Muiden kokemuksista oppiminen on korvaamatonta, sillä se on paras tapa lähestyä aiheita ilman, että niihin tarvitsee sukeltaa syvälle. Lisäetuna on se, että saa kuulla, mitä kaltaisesi ihmiset oikeasti ajattelevat niistä. Onneksi fooConfilla oli enemmän kuin tarpeeksi tarjottavaa tämän tiimoilta.

Esimerkiksi Daniel Deogunin Security by design -esitys muistutti kaikkia siitä, että turvallisuusongelmat ovat aina läsnä. Ohjelmistoja tulee rakentaa ”Defense in Depth” -tyylillä käyttämällä turvallisia suunnittelumalleja jokaiselle osa-alueelle – varsinkin, jos rakentaa julkisia rajapintoja. Merkittävä nosto tästä esityksestä liittyy suhteellisen tuoreeseen Log4Shell-haavoittuvuuteen: lokien kirjoittaminen tulisi nähdä erillisenä järjestelmänä ja näin ollen käsitellä sellaisena. Esitys kehotti muun muassa pohtimaan, mitkä kaikki ohjelmistosi osat ovat todellisuudessa erillisiä ja mahdollisesti haavoittuvaisia järjestelmiä.

Muita kohokohtia:

JavaScriptin tulevaisuudessa palvelimen ja asiakaspuolen renderöinnin välinen kuilu pyritään kuromaan umpeen jättämällä mahdollisimman vähän JavaScriptiä loppukäyttäjän suoritettavaksi. (JavaScript frameworks of tomorrow, Juho Vepsäläinen.)
Jokaisella on velvollisuus testata, vaikka tiimillä olisikin nimetty testaaja. Testaajat voivat löytää ainutlaatuisia näkökulmia tutkimuksen avulla, mutta 77 % tuotannon häiriöistä voidaan havaita yksikkötesteillä. (Let’s do a Thing and Call it Foo, Maaret Pyhäjärvi.)
Muilla aloilla käytettävien ratkaisujen kokeileminen saattaa jopa onnistua, kuten Supermetrics oppi lainattuaan mallin autentikoinnin tekevästä keskuspalvelimesta MMORPG-videopeleistä. (Journeying towards hybridization across clouds and regions, Duleepa Wijayawardhana.)

Aivan kuten muiden kokemuksista oppiminen on sinulle tärkeää, myös muiden on yhtä arvokasta kuulla sinun kokemuksistasi. Älä pelkää jakaa tietämystäsi ja yritä saada aikaa tiimisi kalenterista, jotta voitte jakaa ajatuksianne mistä tahansa aiheesta. Riman asettaminen matalalle on tärkeää; ajatus, joka vaikuttaa sinusta satunnaiselta, voi olla vain jollekulle toiselle suuri oivallus.

Ajaton inspiraatio

Tom Coolsin avauspuhe Learning Through Tinkering oli matka, jossa oppimisen prosessin käytiin läpi tekemällä, ja se kehotti kaikkia olemaan tietoisia siitä, mitä he oppivat ja miten. Monissa tilanteissa on arvokasta olla tietoinen ”proksimaalisen kehityksen vyöhykkeestä”: tietoalueesta, jolle oppija pääsee ohjattuna. Tämä on arvokas ajatus muistaa paitsi itsellesi myös tiimillesi, varsinkin jos satut olemaan johtaja: tiimisi rajojen ymmärtäminen voi auttaa sinua auttamaan toisiasi eteenpäin. Lisäksi on liian helppoa kompastua kaikkiin mahdollisuuksiin, jotka kohtaavat polkusi. Siksi on tärkeää valita yksi saavutettavissa oleva tavoite kerrallaan ja olla tietoinen oppimisen tavoitteista.

Epäilemättä jokainen meistä ammatinharjoittajista on kokenut, että opittavien asioiden määrälle ei näy loppua. Jopa itse konferenssi tarjosi liikaa yhdelle ihmiselle täysin käsitettäväksi. Nate Schuttan päätöspuhe Thinking Architecturally toimi lempeänä muistutuksena siitä, että aina ei ole tarve ratsastaa teknologian aallonharjalla. Teknologiat tulevat ja menevät aaltoina, jotka tuppaavat noudattamaan kaavoja pitkällä aikavälillä, joten mikään tieto ei ole koskaan täysin vanhentunutta. Sen sijaan tulee olla strateginen sen suhteen, mihin huomion kohdentaa, sillä kukaan meistä ei voi olla edes yhden aiheen täydellisiä tietäjiä. Tärkeintä on olla ennakkoluuloton ja haalia laaja-alaisesti tietoa monista asioista sekä syvempää tietoa kapeammin määritellyltä alueelta – eli olla ”T-kirjaimen muotoinen generalisti”.

(Lisäksi avauspuheenvuorossa esiteltiin koko konferenssin henkilökohtainen suosikkikohokohtani, Teachable Machine. Se tekee koneoppimisen käytöstä niin helppoa, että on melkein hölmöä olla rakentamatta heti jotain sen avulla. Todella inspiroivaa!)

Haasta itseäsi tänään

Kaiken kaikkiaan konferenssi oli ehdottomasti menestys, ja se piti lupauksensa olla kehittäjiä varten. Jokaisella esityksellä oli paljon tarjottavaa, ja voi olla vaikeaa yrittää valita, mitä ottaa mukaansa kaikkien ideoiden joukosta. Pidä siis mielessä aloituspuheessa esitetyt neuvot: älä liioittele, on täysin ookoo valita vain yksi aihe, josta haluat oppia lisää, ja aloittaa siitä. Pidä mielessä myös proksimaalisen kehityksen vyöhyke: et tiedä mitä et tiedä, joten askel taaksepäin voi auttaa sinua ottamaan kaksi askelta eteenpäin.

Itselleni koneoppiminen on yleensä vaikeasti ymmärrettävä aihe. Olen muusikko, ja minulla oli projekti-idea, että voisin ohjelmoida rumpukoneen ymmärtämään käsieleitä. Esimerkiksi avoimen käden näyttäminen tarkoittaisi, että soiton tulee loppua. Luovuin projektista tajuttuani, ettei osaamisena koneoppimisen alueella ollut riittävän hyvällä tasolla. Nyt kun tiedän, että Teachable Machine on olemassa, projekti-idea nousi uudelleen esille, koska vaikea osa ideasta on selvitetty.

Jos osallistuit, olemme kiinnostuneita kuulemaan, mistä aiheista olet päättänyt oppia enemmän. Vaikka et osallistunutkaan tai et kokenut mitään esitellyistä aiheista juuri sinulle oikeaksi, olet varmasti törmännyt johonkin mielenkiintoiseen asiaan, jonka opettelemista olet lykännyt. Pyydämme sinua tekemään tietoisen valinnan, että aloitat nyt!

Tiedon puoliintumisaika voi olla lyhyt, mutta oppiminen tuo mukanaan viisautta ja kokemusta, jotka pysyvät matkassasi koko eliniän.

Hyvää oppimista ja nähdään fooConf 2024 -tapahtumassa!

Tietoja kirjoittajasta: Andy Valjakka on full stack -kehittäjä ja tuleva arkkitehti, joka liittyi Codentoon vuonna 2022. Andy aloitti uransa vuonna 2018 tarttumalla monimutkaisiin haasteisiin käyttämällä systemaattista lähestymistapaa, mikä johti hänen pro gradu -tutkielmaan käyttöliittymäkehysten vaihtamisesta 2019. Nykyään hän on sertifioitu Professional Google Cloud Architect, jonka erikoisalaa on löytää ne palapelin palat, joiden avulla mitä tahansa saa sopimaan yhteen.

Matkani monipilven maailmaan: johtopäätökset ja suositukset, osa 4/4

#NEXTGENCLOUD: Matkani monipilven maailmaan: johtopäätökset ja suositukset, osa 4/4

Kirjoittaja: Antti Pohjolainen, Codento

Tausta

Tämä on viimeinen osa neljän blogikirjoituksen sarjasta, joka kattaa matkani monipilven maailmaan. Aiemmat kirjoitukset ovat täällä: Osa 1, osa 2 ja osa 3.

Johtopäätökset

Lopputyöni tutkimuskysymys on ”Mitä liiketoimintahyötyjä on saatavilla monipilviarkkitehtuurista?” Kirjallisuusanalyysin mukaan merkittävimpiä etuja ovat kustannussäästöt, toimittajalukkojen välttäminen ja IT-valmiuksien parantaminen hyödyntämällä useiden julkisten pilvien tarjoamia kehittyneimpiä ominaisuuksia.

Haastatteluista saatujen tietojen mukaan toimittajalukkoja ei koeta suureksi ongelmaksi. Joidenkin haastateltavien mukaan eri julkisten pilvien parhaat ominaisuudet kannattaa hyödyntää. Monipilven käyttöönotto voi johtaa kustannussäästöihin. Kuitenkin näyttää siltä, että “monipilvi-uhkaa” käytetään sopimusten uusimisneuvottelujen aikana lähinnä neuvottelutaktiikkana. Tällä painostetaan nykyistä julkista pilven toimittajaa laskemaan kustannuksia, jotta uusi sopimus olisi edullilsempi.

Kirjallisuusanalyysi ja haastattelut paljastivat, että keskeisimmät ongelmat monipilviarkkitehtuurissa olivat sen lisääntynyt monimutkaisuus, turvallisuus ja taitovaatimukset. Haastattelujen suurin yllätys minulle oli se, ettei asiakkailla ollut valintakriteereita hyperskaalaajien valinnalle. Haastattelujen perusteella markkinoilla on selvä tilaus sekä Google Cloudille että monipilvelle.

Akateemisen tutkimuksen ja haastatteluista poimittujen tietojen mukaan useimmat asiakkaat valitsevat monipilviarkkitehtuurin siten kuin tässä tutkimuksessa monipilvi määriteltiin. Pilviteknologian hyödyntämisestä saatujen hyötyjen pitäisi olla suurempia kuin lisätyö, joka tarvitaan monipilviarkkitehtuurin rakentamiseen, vaikka monipilveen liittyykin useita riskejä.

Haastateltujen päättäjien mukaan heidän nykyinen päätöksensä on toteuttaa yksi, ensisijainen pilvi, jota täydennetään palveluilla yhdestä tai useammasta muusta pilvestä. Suurimman osan työkuormista odotetaan kuitenkin pysyvän nykyisessä ensisijaisessa pilvessä.

Suositukset

Suosittelen, että yritykset arvioisivat ja päivittäsivät säännöllisesti pilvistrategiaansa. Sen sijaan, että arkkitehtuurin annettaisiin kehittyä mielivaltaisesti pelkästään palvelutoimittajien tai ulkoistettujen kumppaneiden tarpeiden perusteella, yrityksen tulisi ottaa strategia täysin hallintaansa.

Yritysten tulee minimoida pilvipalveluntarjoajien omistamien rajapintojen ja tekniikoiden käyttö, ellei 1) siitä ole todistettavissa olevaa taloudellista hyötyä, 2) muita teknisiä vaihtoehtoja ole olemassa, esimerkiksi muut palveluntarjoajat eivät tarjoa kyseistä toiminnallisuutta tai 3) niistä saada muita teknisiä hyötyjä, kuten merkittäviä suorituskyvyn parannuksia. Yritykset voivat vähentää toimittajalukkojen todennäköisyyttä noudattamalla näitä neuvoja.

Jos yritys käyttää tällä hetkellä vain yhden hyperskaalaajan pilvipalveluita, kannattaa konseptin testaus (Proof-of-concept, PoC) muiden pilvipalveluntarjoajien kanssa aloittaa heti, kun liiketoimintatarve syntyy. Jos mahdollista, toimittajakohtaisia teknologioita, API:ita tai palveluita tulisi välttää konseptitoteutuksissa.

Suosittelen, että yritykset luovat pilvitoimittajien hallintakäytännöt, jotka kattavat kaiken hankinnasta operatiiviseen hallintaan. Toimittajien hallinta monipilviympäristössä vaatii enemmän suunnittelua ja taitoa verrattuna vain yhteen hyperskaalaajaympäristöön.

Lisäksi suosittelen rakentamaan käytäntöjä ja menetelmiä kustannusten seurantaan, sillä pilvipalvelun käytön odotetaan lisääntyvän tulevina vuosina.

Lopuksi

Tämä blogikirjoitus päättää Matkani monipilven maailmaan -sarjan. Me täällä Codentossa autamme mielellämme sinua matkallasi monipilven maailmaan. Ota rohkeasti yhteyttä minuun keskustelun aloittamiseksi. Tavoitat kollegani tai minut täältä.

Kirjoittaja: Antti Pohjolainen, Codento

Kirjoittajasta: Myyntijohtaja Antti “Apo” Pohjolainen aloitti Codenton palveluksessa vuonna 2019. Antti on johtanut Innofactorin Suomen myyntiorganisaatiota (pohjoismainen Microsoftin IT-toimittaja) ja työskennellyt sitä ennen Microsoftin julkisen sektorin johtotehtävissä Suomessa ja Itä-Euroopassa. Apo on työskennellyt eri myyntitehtävissä kauemmin kuin hän muistaa. Hän saa ”myyjän onnistumisen tunteen” tavatessaan asiakkaita ja etsiessään ratkaisuja, jotka tarjoavat arvoa kaikille osapuolille.

Tutustu Codenton online-tapahtumien nauhoituksiin, niin kuulet lisää:

Matkani monipilven maailmaan: näkemyksiä haastatteluista, osa 3/4

#NEXTGENCLOUD: Matkani monipilven maailmaan:näkemyksiä haastatteluista, osa 3/4

Kirjoittaja: Antti Pohjolainen, Codento

Tausta

Tämä on kolmas osa neljän blogikirjoituksen sarjasta, joka kattaa matkani monipilven maailmaan. Aiemmat kirjoitukset ovat täällä: Osa 1 ja osa 2.

Tämä kirjoitus kuvaa joitain oivalluksia, joita sain varsinaisista haastatteluista. Kuten osassa 1 kerrottiin, minulla oli tilaisuus haastatella 11 yritysjohtajaa ja alan asiantuntijaa.

Monipilviinfrastruktuurin käytön edut

Haastatteluista saatujen tietojen perusteella suomalaiset asiakkaat käyttävät enimmäkseen yhtä julkista pilveä hoitaakseen suurimman osan työkuormistaan. Nykyisen ajattelun mukaan, jos olemassa oleva pilvipalveluntarjoaja ei tarjoa tiettyä palvelua, voidaan pilven tueksi lisätä pistemäisiä ratkaisuja muista pilvistä. Näin ollen muiden pilvipalveluntarjoajien täydentävät tekniset valmiudet ovat ensisijainen perustelu rakennettaessa monipilviarkkitehtuuria.

Toisin kuin akateemisessa kirjallisuudessa (katso lisätietoja osasta 2), jossa säästöt mainitaan usein yhtenä tärkeimmistä kriteereistä monipilven valinnassa, suurin osa haastatelluista ei pitänyt monipilviä merkittävänä kustannussäästökeinona.

Kustannussäästöjä on vaikea arvioida, ja haastattelujen perusteella useimmat yritykset eivät tällä hetkellä ole asiantuntijoita pilvikäsittelyn kustannusten seurannassa. Hinnoittelukäytännöt vaihtelevat hyperskaalaajien välillä, ja niiden katsotaan muuttuvan usein.

Lisäksi haastateltavat eivät olleet huolissaan mahdollisista toimittajalukoista. Tämä havainto on tärkeä ja se poikkeaa akateemisesta kirjallisuudeta, jossa toimittajien sulkemista pidetään tärkeänä, kenties kriittisimmäksi ongelmaksi yrityksille.

Haasteet ja riskit tunnistettu monipilviympäristöissä

Useiden haastateltujen, jotka edustivat kaikkia tutkittuja ryhmiä, mukaan merkittävin este monipilveen sopeutumiselle on osaamisen ja valmiuksien puute. Tämä johtuu kahdesta taustalla olevasta tekijästä:

Asiakkaat sitoutuvat usein opiskelemaan vain yhtä pilviarkkitehtuuria tai parhaimmillaan hybridipilviarkkitehtuuria ja
Nykyinen kumppaniverkosto näyttää keskittyvän enimmäkseen yhden tyyppiseen pilviarkkitehtuuriin monipilven hyödyntämisen sijaan.

Suomessa IT-palvelujen ulkoistustaso on poikkeuksellisen korkea. Haastattelut osoittivat, että Suomen korkealla ulkoistamisella on merkittävä negatiivinen vaikutus pilvipalveluiden käyttöönottoon.

Asiakkaiden ulkoistamat konesali-infrastruktuurit ja hosting-palveluntarjoajan omat palvelimet tuottavat merkittävän osan ulkoistuskumppaneiden liiketoiminnasta. He ovat investoineet rakennuksiin ja IT-laitteisiin, joten he menettävät rahaa, jos asiakkaat käyttävät laajasti pilvilaskentaa.

Kerätyt vastaukset jakautuivat turvallisuus- ja tietosuojakysymyksissä. Jotkut haastateltavat pitivät pilviturvallisuutta suurinpana esteenä kriittisten sovellusten pilveistämisessä. Yksikään haastattelemista tietotekniikan palveluntarjoajista ei kuitenkaan pitänyt tätä aitona huolenaiheena.

Julkinen sektori – erityisesti valtionhallinto – on ollut hidas julkisen pilven käyttöönotoissa. Joidenkin haastateltujen mukaan hallinnonalan laajuiset politiikat pilvipalveluiden käyttöönotossa ovat epäselviä.

Monet kyselyyn vastanneista uskoivat, että koska pilvipalvelun käyttöönotosta ei ollut vakiintuneita, selkeitä valtionhallinnon laajuisia säännöksiä, organisaatiot viivyttelivät valintaansa sopeutua pilveen.

Jotkut haastatelluista olivat huolissaan siitä, että heidän yritykseltään tai asiakkaaltaan puuttui selkeä pilvistrategia, pilvipalvelun valintastandardit tai pilvipalvelun toteutusstrategia. Tämän huolen esittivät haastateltavat kaikista kolmesta ryhmästä.

Yritykset hyötyisivät selkeästi muotoillusta suunnitelmasta ja valintakriteeriluettelosta, kun ne harkitsevat uusien ominaisuuksien lisäämistä olemassa olevaan pilviarkkitehtuuriinsa, koska yhä useampi henkilö on mukana valitsemassa pilvipalveluita.

Mitä blogisarjassa seuraavaksi?

Sarjan viimeinen blogikirjoitus on nimeltään ”Johtopäätös ja suositukset”. Pysy kanavalla!

Kirjoittaja: Antti Pohjolainen, Codento

Tutustu Codenton online-tapahtumien nauhoituksiin, niin kuulet lisää:

Matkani monipilven maailmaan: hyödyt ja huomioita, osa 2/4

#NEXTGENCLOUD: Matkani monipilven maailmaan: hyödyt ja huomioita, osa 2/4

Kirjoittaja: Antti Pohjolainen, Codento

Taustaa

Tämä on toinen osa neljän blogikirjoituksen sarjasta, joka kattaa matkani monipilven maailmaan. Edellisessä postauksessa kerrottiin tämän sarjan taustasta.

Tämä postaus esittelee lyhyesti, mitä akateemisessa kirjallisuudessa yleensä luetellaan monipilviarkkitehtuurin hyödyiksi ja haasteiksi.

Monipilvi-infrastruktuurin hyödyt

Akateemisessa kirjallisuudessa mainitaan yleisesti seuraavat monipilviarkkitehtuurista koituvat hyödyt:

Kustannussäästöt
Paremmat IT-toiminnallisuudet
Toimittajalukon välttäminen

Kustannussäästöt johtuvat siitä, että hyperskaalaajien markkinaosuuskilpailu on kovaa, mikä on johtanut laskenta- ja tallennuskustannusten laskuun.

Lisääntynyt saatavuus (availability) ja redundanssi, katastrofipalautus ja geolokaatiot ovat usein esimerkkejä paremmista IT-ominaisuuksista, jotka voidaan saavuttaa käyttämällä useamman kuin yhden hyperskaalaajan tarjoamia pilvipalveluita.

Ehkä tärkein syy, ainakin akateemisen kirjallisuuden näkökulmasta katsottuna, usean pilven arkkitehtuurin toteuttamiseen on toimittajalukon välttäminen. Palvelujen hankkiminen vain yhdeltä hyperskaalaajalta luo suuremman riippuvuuden toimittajaan verrattuna tilanteeseen, jossa pilvipalveluntarjoajia on useampi kuin yksi.

Siten termi ”toimittajalukko”. Tyypillisesti pilvipalveluntarjoajalta vaihtaminen aiheuttaa huomattavia kuluja, sillä palveluntarjoajan vaihtaminen vaatii usein järjestelmän uudelleensuunnittelua, uudelleenkäyttöönottoa ja datan siirtoa.

Yhteenvetona voidaan todeta, että valitsemalla parhaan laajasta pilvipalveluiden valikoimasta monipilviinfrastruktuuri lupaa ratkaista toimittajalukot ja johtaa käyttäjien tarpeiden optimointiin.

Monipilvi-infrastruktuurin haasteita

Monipilvi-infrastruktuurin käyttöönotto tuo mukanaan useita haasteita, joihin tulisi vastata, jotta niistä saataisiin täysi hyöty. Seuraavat kappaleet käsittelevät yleisimmin akateemisessa kirjallisuudessa viitattuihin haasteisiin.

Kun data, alustat ja sovellukset ovat hajallaan useissa paikoissa, kuten erilaisissa pilvissä ja yrityspalvelinkeskuksissa, syntyy uusia haasteita. Eri toimittajien hallinta kaikkien sovellusten näkyvyyden varmistamiseksi, erilaisten järjestelmien ja tietokantojen suojaaminen sekä kulujen hallinta lisäävät monipilvistrategian monimutkaisuutta.

Monimutkaisuus lisääntyy, kun kunkin toimittajan tarpeet ja vaatimukset ovat tyypillisesti erilaisia, ja niitä on käsiteltävä erikseen. Esimerkiksi hyperskaalaajat vaativat usein omat rajapinnat antaakseen pääsyn resursseihin ja palveluihin.

Tietoturva on yleisesti ottaen monipilviympäristössä monimutkaisempi toteuttaa kuin yhden pilvipalveluntarjoajan arkkitehtuurissa.

Monipilvi vaatii erityisosaamista ainakin tekniseltä ja liiketoimintalähtöiseltä henkilökunnalta sekä toimittajanhallintaryhmältä. Rekrytointi-, koulutus- ja monipilvistrategiainvestointien budjetit kasvavat, mikä pakottaa yritykset hankkimaan uutta tietoa ja kykyjä esimerkiksi ylläpidon, toteutuksen ja kustannusten optimoinnin aloilla.

Lisäksi sanotaan, että pilvipalvelun avulla voidaan edistää innovaatioita, muuttaa IT-osaston roolia rutiinihuollosta liiketoiminnan tukemiseen sekä tehostaa yritysten sisäistä ja ulkoista yhteistyötä. Siten IT:n roolia voidaan joutua säätämään monipilviarkkitehtuuria toteutettaessa.

Toimittajahallinta– tai hankintatiimien on ehkä opittava uusia taitoja ja menetelmiä voidakseen valita sopivan hyperskaalaajan erilaisiin tarpeisiin. Jokaisella hyperskaalaajalla on erilaiset palvelut ja hinnoittelumenetelmät, ja niiden ymmärtäminen vaatii asiantuntemusta, jota ei välttämättä tarvita, jos työskentelee vain yhden hyperskaalaajan kanssa.

Mitä blogisarjassa seuraavaksi?

Seuraavassa postauksessa kerron, mitä opin tätä tutkimusprojektia varten tekemistäni haastatteluista. Pysy kanavalla!

Kirjoittaja: Antti Pohjolainen, Codento

Tutustu Codenton online-tapahtumien nauhoituksiin, niin kuulet lisää:

Matkani monipilven maailmaan: hyödyt ja huomioita, osa 1/4

#NEXTGENCLOUD: Matkani monipilven maailmaan: hyödyt ja huomioita, osa 1/4

Kirjoittaja: Antti Pohjolainen, Codento

Taustaa

Tämä on ensimmäinen neljästä blogikirjoituksestani, jotka kattavat matkani monipilven maailmaan.

Työskennellessäni Codenton myyntijohtajana olen aina ollut intohimoinen kehittämään ymmärrystäni siitä, miksi asiakkaat valitsevat tietyt liiketoiminta- tai teknologiasuunnat.

Tämä oli yksi syistä, miksi aloitin osa-aikaisen MBA (Master of Business Administration) -opinnot syksyllä 2020 yhdessä 20 muun osa-aikaisen opiskelijan kanssa. MBA-koulutus oli The University of Northampton ohjelma, joka on saatavilla Helsinki School of Businessista (Helbus).

Viimeinen yritystutkimusprojekti oli ohjelman huipentuma, ja lopputyöni hyväksyttiin lokakuussa 2022. Tutkimusprojektini otsikko oli ”Multi-pilvi – liiketoiminnan hyödyt, haasteet ja markkinapotentiaali”.

Tämä blogikirjoitussarja perustuu kyseisen tutkimuspaperiin ja siinä esitettyihin havaintoihin.

Monipilviarkkitehtuurin määritelmä

Monipilvi on arkkitehtuuri, jossa pilvipalvelut ovat käytettävissä monien pilvipalvelutarjoajien kautta (Mezni ja Sellami, 2017). Lisäksi termi viittaa arkkitehtuuriin, jossa käytetään useita pilvilaskenta- ja tallennuspalveluita yhdessä heterogeenisessä arkkitehtuurissa (Georgios et al., 2021).

Rajoitin tutkimukseni skenaarioihin, joissa julkiset pilvipalvelut perustuivat vain Infrastructure as a Service (IaaS) ja Platform as a Service (PaaS) -palveluihin. Näin ollen Software as a Service – esimerkiksi sähköposti, kuten gmail.com – ei sisälly tutkimukseen. Seuraava kuva havainnollistaa SaaS-, Paas- ja IaaS-komponentteja:

Kuva 1. SaaS-, PaaS-, IaaS-komponentit. Lähde: Nasdaq (2017).

Tutkimuksen perusteet, tutkimuskysymykset ja tutkimusmetodologia

Halusin ymmärtää paremmin monipilviarkkitehtuurin tarjoamia liiketoimintaetuja.

Työnantajani – Codento Oy – on suomalaisten Google Cloudiin perustuvia palveluita tarjoavien yritysten edelläkävijä, ja useimmissa tapauksissa Google Cloud olisi asiakkaillemme toinen tai kolmas pilvipalveluntarjoaja. Näin ollen monipilviosaaminen on elintärkeää asiakaskeskusteluissamme ja toteutusprojekteissamme.

Tutkimusprojektin laajuuden kaventamiseksi painopisteeksi asetettiin suomalaiset pienet ja keskisuuret yritykset sekä julkisen sektorin organisaatiot.

Pääasiallinen tutkimuskysymys, johon projekti halusi löytää vastauksen, oli ”Mitä liiketoimintahyötyjä on saatavilla monipilviarkkitehtuurista?”

Toissijaiset kysymykset olivat

Mitkä ovat usean pilviarkkitehtuurin käytön tärkeimmät haasteet?
Mitkä tekijät vaikuttavat julkisten pilvipalveluntarjoajien (tunnetaan myös nimellä ”hyperscaler” eli hyperskaalaajat) valintaan? sekä
Mikä on markkinapotentiaali monipilviratkaisuille, joissa Google Cloud on yksi komponenteista seuraavan kolmen vuoden aikana?

Valitsin kvalitatiivisen lähestymistavan, jotta pääsisin syvällisiin keskusteluihin useiden eri organisaatioiden IT- ja yritysjohtajien kanssa.

Haastateltavat edustivat kolmea eri ryhmää:

Asiakkaat
IT-palveluyritykset
Hyperskaalaajat

Heinä-elokuussa 2022 toteutin yhteensä 11 haastattelua:

IT-palveluntarjoajat: toimitusjohtaja, teknologiajohtajat
Hyperskaalaajat: Pilvitiimin johtaja, asiakkuusvastaava
Asiakkaat: toimitusjohtaja, tietohallintojohtaja, teknologiajohtajat

Tutkimuksen tuloksia avataan seuraavissa blogikirjoituksissani 2-4. Pysy mukana!

Tutustu Codenton online-tapahtumien nauhoituksiin, niin kuulet lisää:

Cloud Digital Leader -sertifikaatti – miksi ja miten?

#GOOGLECLOUDJOURNEY: Cloud Digital Leader -sertifikaatti – miksi ja miten?

Kirjoittaja: Anthony Gyursanszky, toimitusjohtaja, Codento

Esipuhe

Koska meidän Codenton tekniset konsulttimme ovat olleet kiireisiä Google Cloud -sertifikaattien suorittamisessa, minä ja enemmän kaupalliset kollegani olemme yrittäneet pysyä tahdissa käymällä Googlen myyntikurssit (nämä vaaditaan yritystason kumppanistatuksen saavuttamiseksi) ja opiskelemalla perusasiat Courseran Google Cloud -peruskurssien avulla. Vaikka jälkimmäisten kurssien tekniset labrat olivatkin mielenkiintoisia ja konkreettisia, niitä ei niinkään tarvita omissa tehtävissämme.

Näistä näkökulmasta heräsikin kysymys: mikä on oikea tapa hankkia riittävästi tietoa pilviteknologiasta ja digitaalisesta transformaatiosta liiketoiminnan näkökulmasta sekä oppia uusimmat Google Cloud -tuotteet ja tiekartat?

Olenkin viime aikoina huomioinut, että monet kollegani muissa ekosysteemiyrityksissä ovat suorittaneet Googlen Cloud Digital Leader -sertifikaatin. Uteliaisuuteni heräsi: olisiko tämä sertifikaatti hyödyllinen myös minulle?

Miksi ylipäätään vaivautua?

Googlen sanoin ”Cloud Digital Leader on lähtötason sertifiointikoe, ja sertifioitu voi osoittaa Google Cloud -ydintuotteiden ja -palveluiden ominaisuudet ja niiden hyödyn organisaatioille. Cloud Digital Leader voi myös kuvata yleisiä yrityskäyttötapauksia ja kuinka pilviratkaisut tukevat yritystä.”

Oletin aiemmin, että tämä sertifikaatti kattaa sekä Google Cloudin että Google Workspacen ja erityisesti miten kulttuurinen muutos johdetaan Workspace-alueella, mutta tämä oletus osoittautui täysin vääräksi. Workspacea ei käsitellä, kyse on pelkästään Google Cloudista. Tämä oli hyvä uutinen minulle, sillä vaikka olemmekin tyytyväisiä Workspacen käyttäjiä Condetolla, konsultointiliiketoimintamme perustuu yksinomaan Google Cludiin.

Mitä sertifikaatti sitten kattaa? Kuvailisin sisältöä seuraavasti:

Pilviteknologian perusteet ja mahdollisuudet organisaatioille
Erilaiset datahaasteet ja -mahdollisuudet sekä miten pilvi ja Google Cloud voivat olla avuksi, huomioiden myös koneoppiminen ja tekoäly
Erilaisia polkuja organisaatioiden pilvisiirtymään ja miten Google Cloudia voidaan hyödyntää sovellusten modernisoinnissa
Kuinka suunnitella, ajaa ja optimoida pilvi pääasiassa liiketoiminnan ja vaatimustenmukaisuuden näkökulmasta

Mikäli nämä aiheet ovat sinulle tärkeitä ja haluat ottaa vastaan sertifiointihaasteen, Cloud Digital Leader on sinua varten.

Kuinka valmistautua testiin?

Kun etenin sertifikaattimatkassani sain tietää, että Google tarjoaa ilmaisia koulutusmoduuleja kumppaneille. Kumppanien tekninen koulutussisältö on saatavilla kumppaneille Google Cloud Skills Boost for Partners -palvelussa. Mikäli et ole Google Cloud -kumppani, sama koulutus on saatavilla myös ilmaiseksi täältä.

Koulutusmoduulit ovat korkealaatuisia, erittäin selkeitä ja helppoja seurata. Jokaisessa neljässä moduulissa on kalvopaketti, jossa kussakin on noin 70 kalvoa. Tekstin ja tiedon määrä kalvoa kohden on pieni, eikä niiden läpikäyminen vie montaa minuuttia.

Varsinaiset koulutusvideot voi katsoa läpi kaksinkertaisella nopeudella, ja jokaisen osion jälkeen on vastattava 80 %:n oikein. Toisin kuin varsinaisessa sertifiointitestissä, kysymykset osoittautuivat hieman vaikeammiksi, koska vastaan tuli myös monivalintakysymyksiä.

Kokemukseni mukaan koulutuksen läpikäymiseen ja varsinaisen sertifikaatin suorittamiseen menee noin 4-6 tuntia. Tämä on siis hyvin erilainen vaatimustasoltaan kuin tekniset sertifikaatit, joissa on kyse viikkojen ponnisteluista ja tarvittavista kattavista esitiedoista.

Kuinka rekisteröityä kokeeseen?

Helpoin tapa suorittaa sertifikaatti on varata verkossa valvottu testi Webasessorin kautta. Hinta on 99 USD plus ALV, joka tulee maksaa etukäteen. Etätesteille on tarjolla runsaasti aikoja 15 minuutin välein käytännössä kaikkina arkipäivinä. Ja kyllä, jos mietit, aikavälit esitetään paikallisessa ajassasi, vaikka sitä ei mainitatkaan.

Kuinka suorittaa online-testi? Ennen koetta on muutama asia varmistettava:

Työskentelyhuone, jossa voit työskennellä yksityisesti
Pöytä oltava kohtuu tyhjä
Henkilöllisyystodistus saatavilla
Sinun on asennettava suojattu selain ja lähetettävä valokuvasi etukäteen (vähintään 24 tuntia)
Muut ohjeet kuten ilmoittautumisprosessissa

Tenttilinkki ilmestyy Webassessor-sivustolle muutama minuutti ennen suunniteltua ajankohtaa. Tämän jälkeen joudut odottamaan ensin 5-15 minuuttia aulassa ja sinut ohjataan muutaman vaiheen läpi, kuten henkilöllisyystodistuksesi näyttäminen ja huoneesi ja pöytäsi näyttäminen web-kamerallasi. Tämä osa kestää noin 5-10 minuuttia.

Kun olet ilmoittautunut kokeeseen, aikalaskuri näkyy koko kokeen ajan. Vaikka enimmäisaika on 90 minuuttia, kaikkiin 50–60 kysymykseen vastaaminen vie todennäköisesti vain noin 30 minuuttia. Kysymykset ovat melko lyhyitä ja yksinkertaisia. Vaihtoehtoja ehdotetaan neljää ja vain yksi on oikea. Jos epäröit kahden mahdollisen oikean vastauksen välillä (kuten minulle kävi muutaman kerran), voit palata niihin lopuksi. Joidenkin lähteiden mukaan riittää, että 70 prosenttiin kysymyksistä on vastattava oikein.

Kun olet lähettänyt vastauksesi, saat heti tiedon siitä läpäisitkö vai et. Tietoja arvosanoista tai oikeista/vääristä vastauksista ei kuitenkaan anneta. Google lähettää sinulle varsinaisen todistuksen muutaman arkipäivän kuluessa. Mahdollinen uusi testi voidaan ajoittaa aikaisintaan 14 päivän ajanjakson jälkeen.

Oliko se sen arvoista?

Cloud Digital Leader -sertifikaattia ei lasketa varsinaisesti Googlen ammattisertifikaatiksi, ja sitä ei sisällytetä yritystason kumppanistatuksiin tai spesialisaatioihin. Tämä saattaa kuitenkin muuttua tulevaisuudessa.

Oletan, että Googlella on seuraavat tavoitteet tälle sertifikaatille:

Tarjoaa rooliriippumattomia entry-sertifikaatteja, myös yleisille rooleille, kuten muissa ekosysteemeissä (Azure / AWS Fundamentals)
Tuoda Google Cloud -ekosysteemi paremmin yhteen oikeanlaisen yhteisen kielen ja näkemyksen kautta, mukaan lukien kumppanit, kehittäjät, Googlen työntekijät ja asiakkaiden päätöksentekijät
Kohdistaa liike-elämän ja tekniset ihmiset työskentelemään paremmin yhdessä puhumaan samaa kieltä ja ymmärtämään korkean tason käsitteitä samalla tavalla
Tarjota myynnin peruskoulutusta laajemmalle yleisölle, jotta myyjät voivat tuntea itsensä ”sertifioiduiksi”

Sertifiointi on voimassa kolme vuotta, mutta vaikka perusperiaatteet pätevät jatkossakin Google Cloud -tuotetuntemus vanhenee melko nopeasti.

Oliko ajankäyttö panostuksen arvoista? Minulle ehdottomasti kyllä. Kävin käytännössä läpi aineiston yhdessä iltapäivässä ja varasin serttitestin seuraavalle aamulle, joten tähän ei mennyt liikaa aikaa. Mutta koska olen jo jonkinlainen pilviveteraani ja Google Cloudin puolestapuhuja, olettaisin, että tämä olisi arvokkaampi silmien avaaja AWS/Azure-kannattajille, jotka eivät vielä ole perehtyneet Google Cloudin laajaan potentiaaliin. Peukut pystyssä myös meille kaikille Googlen ekosysteemissä oleville liiketoiminnan ammattilaisille – tämä on käytännössä pakollinen portti ekosysteemissämme työskentelemiseen.

Blogin kirjoittajasta:

Anthony Gyursanszky, toimitusjohtaja, liittyi Codentoon vuoden 2019 lopulla yli 30 vuoden kokemuksella IT- ja ohjelmistoalalta. Anthony on aiemmin toiminut johtotehtävissä F-Securessa, SSH:ssa, Knowit / Enderossa, Microsoft Finlandissa, Tellabsissa, Innofactorissa ja Elisassa. Gyursanszky on toiminut myös ohjelmistoyritysten hallituksissa, mukaan lukien Arc Technology ja Creanord. Anthony toimii myös arvokartoituspalveluiden johdon konsulttina. Anthonyn kokemus kattaa liikkeenjohdon, tuotehallinnan, tuotekehityksen, ohjelmistoliiketoiminnan, SaaS-liiketoiminnan, prosessihallinnan ja ohjelmistokehityksen ulkoistamisen. Ja Anthony on nyt myös sertifioitu Cloud Digital Leader.

Ota yhteyttä ja kysy lisää Codenton palveluista:

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:

Lähdetään ratkaisemaan alunperin väärää ongelmaa
Jäädään olemassaolevien sovellusten ja infrastruktuurin vangiksi
Jäädään nykyisten toimintamallien vangiksi
Ei hyödynnetä optimaalisesti uusien pilviteknologioiden mahdollisuuksia
Dataa ei hyödynnetä liiketoiminnassa riittävästi
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:

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

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:

Uusien palveluiden kehittäminen
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ää:

Sertifikaatit luovat tavoitteellisuutta

Author: Jari Timonen, Codento Oy

Mistä IT-alan sertifikaateista on kyse?

Henkilökohtaiset sertifikaatit tarjoavat IT-palveluyrityksille keinon kuvata omien konsulttien osaamisen taso ja laajuus. IT-palveluiden hankkijalle sertifikaatit ainakin teoriassa takaavat, että henkilö osaa asiansa.

Sertifikaattitesti suoritetaan valvotuissa olosuhteissa ja sisältää yleensä monivalintakysymyksiä. Lisäksi markkinoilta löytyy myös tehtäväpohjaisia kokeita, jolloin vaadittu tehtävänanto tehdään vapaasti kotona tai töissä.

Sertifikaatteja on monen tasoisia erilaisille kohderyhmille. Yleensä ne ovat hierarkkisia, jolloin täysin vieraan aiheen voi aloittaa helpoimmasta päästä. Korkeimmalla tasolla ovat vaikeimmat sekä arvostetuimmat sertifikaatit.

Henkilökohtaiset sertifikaatit kuuluvat Codentolla olennaisena osana itsensä kehittämiseen. Ne ovat yksi mittari osaamisesta. Tuemme sertifikaattien suorittamista mahdollistamalla työajan käyttämistä opiskeluun sekä maksamalla kursseja ja itse tentin. Googlen valikoimasta löytyy jokaiselle oikean tasoinen ja aiheinen sertifikaatti suoritettavaksi.

Ajantasainen lista sertifikaateista löytyy Google Cloudin sivuilta.

Tavoitteellisuus keskiössä

Sertifikaattien suoritus pelkän “plakaattien” vuoksi ei ole kovin järkevä lähestymistapa. Sertifikaattien saavuttaminen pitäisi nähdä tavoitteellisena maalina, jota kohti opiskellessa tulee luettua rakenteellisesti. Tämä tarkoittaa, että itsensä kehittämisessä on jokin punainen lanka, jota noudattaa.

Tavoitteellisuus voi olla ainoastaan yhden sertifikaatin suorittaminen tai esimerkiksi suunniteltu polku kolmen eri tason läpi. Tällä tavalla itsensä kehittäminen on paljon helpompaa, kuin lukea artikkeli sieltä täältä ilman päämäärää.

Aikataulu sitoutumisen pohjana

Päämäärän asettamisen jälkeen tulee valita aikataulu kokeen suorittamiselle. Tämä vaihtelee todella paljon riippuen lähtötasosta ja suoritettavasta sertifikaatista. Jos olemassa olevaa osaamista on ennestään, lukeminen saattaa olla pelkkää kertaamista. Yleisesti ajatellen lukemiseen tulisi varata muutamia kuukausia. Pidemmällä aikavälillä opiskelusta jää enemmän muistiin ja siten opiskelusta on enemmän hyötyä.

Aika ajoin tulisi tehdä testitenttejä. Ne auttavat selvittämään, mitä kokeen osa-aluetta tulisi lukea enemmän ja mitkä alueet ovat jo hallussa. Testitenttejä kannattaa tehdä jo lukemisen alkuvaiheilla vaikka tulos olisi huono. Näin kertyy kokemusta varsinaista koetta varten eivätkä kokeen kysymykset tule täytenä yllätyksenä.

Koe tulisi varata noin 3-4 viikkoa ennen aikataulutettua suorituspäivää. Tässä ajassa ehtii tekemään tarpeeksi testitenttejä sekä vahvistamaan osaamista.

Lukemista sekä töissä että vapaa-ajalla

Lukeminen kannattaa aloittaa koealueen ymmärtämisellä. Tämä tarkoittaa kokeen eri painotuksien selvittämistä ja asioiden listaamista. Lukemisesta kannattaa tehdä karkea suunnitelma aikataulutettuna eri osa-alueiden mukaan

Suunnitelman jälkeen opiskelun voi aloittaa aihealue kerrallaan. Aiheita voi lähestyä ylhäältä alaspäin, eli yrittää ensin ymmärtää kokonaisuus, jonka jälkeen pureutua yksityiskohtiin. Yksi tärkeimmistä työkaluista pilvipalveluiden sertifikaatteihin opiskelussa on tekeminen. Asioita tulisi tehdä itse, eikä pelkästään lukea kirjoista. Muistijälki on paljon vahvempi, kun pääsee itse kokeilemaan, miten palvelut toimivat.

Lukemista ja tekemistä tulisi tehdä niin töissä kuin vapaa-ajalla. Yleensä kannattaa varata kalenterista aikaa opiskeluun. Sama kannattaa aikatauluttaa myös vapaa-ajalle, mikäli se on mahdollista. Tällöin opiskelu tulee tehtyä suuremmalla todennäköisyydellä.

Opiskelu säännöllisesti kannattaa

Vuosien saatossa olen suorittanut useita eri sertifiointeja eri aihealueilta: Sun Microsystems, Oracle, AWS ja GCP. Kaikissa näissä ratkaisee oma into ja halu oppia. Edellisistä sertifioinneista saa aina pohjaa seuraavalle, joten lukeminen helpottuu ajan myötä. Esimerkiksi jos olet suorittanut AWS:n arkkitehti -sertifiointeja, voi niistä ponnistaa GCP:n vastaaviin sertifikaatteihin. Teknologiat ovat erilaisia, mutta arkkitehtuurissa ei ole juurikaan eroa, koska pilvinatiivi arkkitehtuuri ei ole pilviriippuvainen.

Tärkein asia minkä olen oppinut: Opiskele säännöllisesti ja asia kerrallaan.

Loppusanat: sertifikaatit ja käytännön kokemukset takaavat yhdessä menestyksen

Sertifikaatit ovat hyödyllisiä välindeitä itsensä kehittämiseen. Ne eivät vielä takaa täyttä osaamista, vaan antavat hyvän pohjan ponnistaa ammattilaiseksi. Sertifiointi yhdistettynä arkipäivän tekemiseen on yksi vahvimmista tavoista opiskella moderneja pilvipalveluita josta hyötyvät kaikki – työntekijä, työnantaja ja asiakas – riippumatta osaamistasosta.

Uskomme Codentolla jatkuvaan kehitykseen. Tule kuulemaan lisää #GCPJOURNEY pilviammattilaisten ja sellaisiksi haluavien online-tapahtumassa 28.1.2022 klo 10-11! Rekisteröidy tapahtumaan täältä.

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

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.

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.

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