#GOOGLECLOUDJOURNEY: 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ää

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

#GOOGLECLOUDJOURNEY, Sertifikaatit luovat tavoitteellisuutta

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

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