Johdanto

Globaalille X-Roadtiedonsiirtoalustalle on kehitetty uusi liityntäpalvelinvaihtehto ”Sidecar. Se on Docker-teknologiaa hyödyntävä kontitettu liityntäpalvelin, joka voidaan asentaa samaan ympäristöön, jossa integroitava tietojärjestelmäkin sijaitsee. Konttitettu ratkaisu tekee liityntäpalvelimen käyttämisestä kustannustehokkaampaa, ja se sopii erityisesti ympäristöihin, joissa tietojärjestelmät jo käyttävät konttiteknologiaa. Uusi liityntäpalvelin on kehitetty Suomen Digi- ja Väestötietovirastolle, ja se julkaistaan MIT-lisensoituna avoimen lähdekoodin komponenttina X-Road-tiedonsiirtoalustan yhteydessä. X-Roadia hallinnoi ja kehittää Nordic Institute for Interoperability Solutions (NIIS). 

Asennus

Sidecarin myötä liityntäpalvelimen asennusprosessi yksinkertaistuu verrattuna perinteiseen palvelinkeskusasennukseen. Kontitettu liityntäpalvelin vaatii ympäristökseen vain Dockerin Linux-alustalle. Windowsia ja MacOS:ää ei vielä tueta virallisesti, mutta niitäkin voidaan käyttää testaus- ja kehitystarkoituksiin.  

Suomi.fipalveluväylään liittymisessä voi käyttää NIIS:in Dockerhub:ssa julkaistuja kontitettuja liityntäpalvelimia. Käyttöönotossa määritellään tarvittavat parametrit, joilla varmistetaan liityntäpalvelimen oikeanlainen ja ekosysteemiin yhteensopiva konfiguraatio. Samassa yhteydessä liityntäpalvelin luo tarvittavat TLS-avaimet ja varmenteet, sekä määrittää järjestelmävalvojan tunnistetiedot ja ohjelmiston PIN-koodin. 

Kontitettuun liityntäpalvelimeen voidaan määrittää myös ulkoinen tietokanta. Tällöin parametreiksi tarvitaan tietokantapalvelimen nimi, portti ja pääkäyttäjän tunnistetiedot. Liityntäpalvelin tukee myös erilaisia PostgreSQLyhteensopivia pilvitietokantoja, kuten AWS, RDS ja Azure.

Ohjelmistopaketit 

Kontitetusta liityntäpalvelimesta on saatavilla useita versioita, joista Suomi.fipalveluväylän jäsenet voivat valita sopivimman. Ohjelmistopaketit asentavat määritellyt moduulitjoko pelkän perusversion tai haluamansa lisäosat. Esimerkiksi versiossa 6.25.0 on mukana viestiloki, sekä operoinnin ja ympäristön seurannan moduulit, kun taas 6.25.0-slim versio ei niitä sisällä. Slimversiota suositellaan käytettäväksi ensisijaisesti X-Road palveluiden hyödyntäjille. Lisäksi saatavilla on maakohtaisia kokoonpanoversioita, esimerkiksi 6.25.0-fi -versio suomalaiselle palveluväylälle.  

 

Käyttöönotto 

Merkittävin kontitetun liityntäpalvelimen eduista on, että se toimii asiakkaan tai palvelun tietojärjestelmän kanssa samassa ympäristössä, mutta omassa erillisessä kontissaan. Kontitettua liityntäpalvelinta voi saman verkon/klusterin kautta käyttää yksi tai useampi tietojärjestelmä. Kehitteillä on myös liityntäpalvelin-klusterin automaattinen skaalautuvuus kuormitusvaihtelujen hallintaan ja tämä tulee auttamaan liityntäpalvelinklusterin asianmukaisessa mitoituksessa. 

Kun liityntäpalvelin viedään tuotantoympäristöön, pitää kiinnittää erityistä huomiota sen vikasietoisuuteen. Myös kontitetulla liityntäpalvelimella voidaan täyttää korkean saavutettavuuden vaatimukset kuormanjaon avulla. X-Roadin sisäistä kuormanjakoa käytettäessä on määritettävä useita liityntäpalvelinkontteja samalla jäsen- ja palvelukoodiyhdistelmällä – näin Suomi.fi-palveluväylä reitittää yhteyspyynnöt nopeimmin vastaavalle liityntäpalvelimelle. 

 

Ulkoiset tietokannat 

Toinen kontitetun liityntäpalvelimen mukanaan tuoma etu on mahdollisuus käyttää sisäistä tai ulkoista tietokantaa. Tuotantoympäristössä on erittäin suositeltavaa määrittää kontitettu liityntäpalvelin käyttämään ulkoista tietokantaa. Näin liityntäpalvelimen konfiguraatiota ei menetetä, vaikka kyseinen kontti tuhotaan. Docker sallii saman konfiguraation käyttämisen usealle liityntäpalvelinkontille, mikä mahdollistaa esimerkiksi suoraviivaiset versiopäivitykset. Ensin luodaan varmuuskopio konfiguraatiosta. Sitten tuodaan uusi ohjelmistoversio tuotantoympäristöön ja palautetaan sille varmuuskopioitu konfiguraatio – tai asetetaan se käyttämään tallennustilaa, jossa konfiguraatio on määritelty.

 

Turvallisuus 

Turvallisuusmielessä Docker takaa, että kontitetut sovellukset pysyvät täysin erillään. Kontitetun liityntäpalvelimen yhteydessä pitää kuitenkin huomioida joitain tietoturvariskejä, jotka johtuvat sovelluskerroksen ja infrastruktuurikerroksen erottamisesta. Käyttäjän tulee tarkistaa huolellisesti Docker-tietoturvakäytännöt (englanniksi) liityntäpalvelimen suojaamiseksi. Kattava tietoturvaopas löytyy dokumentaatiosta, jossa kuvataan tärkeimmät suositukset yleisten turvallisuusongelmien välttämiseksi.  

Samassa ympäristössä ajettavien sovellusten ja konttien yhteydet kontitettuun liityntäpalvelimeen tulee estää määrittämällä yhteydet vain sallituille konteille. On myös erittäin suositeltavaa tallentaa tietoturvallisuuden kannalta arkaluontoiset tiedot käytetyn kontin ulkopuolelle. 

 

Katso myös: Digi- ja Väestotietoviraston tiedote 

Raul Martinez

Raul Martinez

Raul is a Software Engineer with more than 10 years of international experience in Software Consultancy firms around Europe with experience in Software Architecture, Systems Integration, and Project Management. Besides managing the operations of Gofore Spain, Raul works in Digital Transformation projects with the Finnish Digital Agency and Nordic Institute for Interoperability Solutions (NIIS) on the X-Road secure data exchange platform. Enthusiast of applying new technologies to make the world a better place bit by bit. Tireless traveler loves to meet people from different cultures and enjoys practicing his skills in food and music in his spare time.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Kiihtyvässä muutoksessa liiketoiminnan jatkuvuuden perustana on kyky uudistua ja hyötyä uusista toimintamalleista ja ratkaisuista. Tämä edellyttää uutta ajattelua sekä uusia johtamistapoja ja -välineitä.

Suunnitelmatalouden periaatteet, tiukat pitkäjänteiset strategiat ja tarkat suunnitelmat, ovat kiihtyvässä muutoksessa liian hitaita ja epävarmoja. Muuttuva liiketoimintaympäristö ei yleensä piittaa suunnitelmistasi.

Kun et voi estää toimintaympäristön muutoksia etkä hallita niitä (pandemia, digitalisaatio, asiakaskäyttäytymisen muutokset, työn tekemisen muutokset, digimurros jne.), on sekä sopeuduttava muutokseen että hyödynnettävä sen mukanaan tuoma potentiaali. Ratkaisevinta on ihmisten suhtautuminen muutokseen. Tulevaisuuden onnistujat rakentavat uudistumiskykyisen, ympäristöä uteliaasti tutkivan organisaation, jossa ihmisillä on paitsi halu ja kyky oppia jatkuvasti, myös mahdollisuus kokeilla ketterästi.

Tiedän kokemuksesta, että uudistumiskyky on eräs keskeisimmistä strategisista kyvykkyyksistä, ja että se on digitalisaation keinoin lähes loputtomasti skaalattavissa. Uudistumiskyky oli avain esimerkiksi Goforen tytäryhtiön Silver Planet Oy:n kasvutarinassa. Seitsenkertaistimme liikevaihtomme erittäin hyvällä kannattavuudella vain puolessatoista vuodessa, kun aloimme itse systemaattisesti noudattaa niitä menetelmiä, joilla autamme asiakkaitammekin.

Luo uudistumiskykyä normalisoimalla muutos

Luonnontieteissä hallitsemattomaksi muuttuvia teoreettisia yhtälöitä voidaan hallita niin sanotulla renormalisoinnilla. Vaikka liiketoimintaa ja yhteiskuntaa ei voidakaan mallintaa kuten luonnontieteitä, renormalisoinnin perimmäistä ideaa voidaan kuitenkin lainata.
Sen ensimmäinen askel on hyväksyä tosiasiat. Entinen ei palaa, eivätkä vanhat lääkkeet tuo uusia ratkaisuja. Albert Einsteinia mukaillen: Hulluutta on tehdä asia uudestaan ja uudestaan samalla tavalla ja odottaa joka kerta eri tuloksia.

Sen jälkeen voit vakiinnuttaa kaoottisesta muutoksesta jatkuvasti organisaatiosi uutta normaalia:

  1. Siirrä johtamisen painopiste yksittäisten hankkeitten tai prosessien johtamisesta kokonaisvaltaiseen visiolla ja tuloksella johtamiseen (linkki Pasin blogiin).
  2. Seuraa onnistumista datan avulla kaikilla organisaation tasoilla. Et voi etukäteen tietää, mitkä ovat parhaat mahdolliset ratkaisut. Selvitä jatkuvasti kokeillen, mikä toimii, edistä toimivia malleja ja hylkää tai muuta tuloksia tuottamattomia toimintamalleja ja ratkaisuja. Investoi vain uudistuksiin, jotka pienessä kokeilussa osoittavat aitoja tuloksia.
  3. Auta muitakin pääsemään irti ”näin meillä on aina tehty” -ajattelusta. Luovuutta ja itsenäistä päätöksentekoa tukevat rakenteet ja työkalut tai uuden normaalin vaatimat työntekijätaidot eivät synny itsestään.

Kiihdytä uudistumiskykyä uusilla liiketoimintamalleilla

Kun uudistumisen perusta on rakennettu, on valittava, jatketaanko horisontaalista, tuotetta jatkuvasti paremmaksi iteroivaa uudistumista vai tarvitaanko todellinen liiketoiminnan vertikaalinen transformaatio, jossa liiketoimintamallia muutetaan kokonaan toiseksi ja osaaminen viedään kokonaan uuteen kontekstiin.

Esimerkiksi musiikin jakelusta alkaneesta jatkuvan tilauksen ja alustaekosysteemiin perustuvasta subscription-liiketoimintamallista on nopeasti tullut median kuluttamisen uusi normaali elokuvista kirjoihin. On varsin epätodennäköistä, että toimintamalli, jossa fyysinen elokuva haetaan videovuokraamosta ja se käydään seuraavana päivänä palauttamassa, enää palaisi. Subscription-mallin innovaatio ei ole sisältöjen määrä tai laatu, teknologia tai edes alustatalous sinänsä, vaan kaiken tämän mahdollistamana se, että ostopäätös tehdään vain kerran.

Kumman tahansa polun valitset, uudistumiskyvyn kiihdyttämisen mahdollisuuksia selvittäessäsi määritä ihmiskeskeinen haluttava visiosi, tunnista sen saavuttamiseen tarvittavat kyvykkyydet kokonaisvaltaisesti ja uudista toimintaa rohkeasti, mutta pienissä palasissa kokeillen. Tutustu myös ekosysteemeihin ja alustatalouteen, automatisoi ja oikaise toimintamallejasi digitransformaatiolla, huolehdi systemaattisesti asiakas- ja työntekijäkokemuksesta, hyödynnä dataa ja varmista palvelusi haluttavuus.

Tärkeintä on, ettet laita päätä pensaaseen tai ajattele, ettei muutos koske sinua. Se ei mene ohi, eikä maailma odota. Muutoksen aika on aina.

Mika Karjalainen

Mika Karjalainen

Goforen kyvykkyys- ja ekosysteemikonsultoinnin kehittäjä ja perimmäinen konsultti Mika Karjalainen, joka on ollut mukana satojen menestystarinoiden rakentamisessa asiakkaillamme. Mika uskoo, että uudistumisen aika on aina.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Nykypäivänä pilvipalveluiden hallinnasta, hallintamalleista ja Governancesta käydään todella paljon keskustelua. Kuitenkin kun aiheista keskustelee asiakkaiden kanssa, tuntuu, että termit ja käsitteet ovat kaikilla hieman erilaisia.

Joidenkin mielestä hallintamalli on tekninen dokumentti, jossa on kuvattu miten pilvipalvelu on rakennettu vaikka Azureen ja miten sitä tulisi operoida, mitä ominaisuuksia kyseisestä pilvipalvelusta on käytössä ja miten ylipäätään ympäristöä ylläpidetään.

Toisen mielestä se on kuvaus siitä, miten kaikkea tekemistä pilvipalvelujen ympärillä pyöritetään. Mitkä ovat vastuut, miten oma Cloud Center of Excellence on miehitetty ja mitä tukifunktioita tarvitaan holistiseen tekemiseen pilven ympärillä.

Me Goforella autamme asiakkaitamme jokaisessa pilvisiirtymän vaiheessa, joten jaan hieman kokemuksiani aiheen ympäriltä.

Markkinassa nähtyä

Suomessa pilvipalveluiden käyttö on monessa yrityksessä tai yhteisössä osa arkea ja pilvipalveluita on otettu käyttöön jo useita. Microsoft 365 saattaa olla koko organisaation käytössä, markkinoinnilla työkaluna HubSpot, Data ja AI-tiimi rouskuttaa dataa Azuressa ja joku nimeltä mainitsematon devaaja on vielä keksinyt viedä tärkeän testiympäristön Google Cloudiin. Kaikki nyökyttelevät, että homma on hanskassa ja ympäristöt asian mukaisessa hallinnassa ja homma toimii. Vai toimiiko? Tilanne tulee nykypäivänä usein vastaan ja harvemmin yllä mainituille palveluille on yhteisiä pelisääntöjä olemassa.

Mihin niitä yhteisiä pelisääntöjä sitten tarvitaan?

Pilvipalvelut aiheuttavat organisaatioissa runsaasti kiinnostusta ja mielipiteitä ja välillä metsä hukkuu puilta. Mielipiteitä esitetään faktoina kun keskustellaan tietoturvasta tai tietosuojasta, palveluita tilataan ohi prosessien ja laskutus hoidetaan kätevästi luottokortilla. Ei tunnu oikein kestävältä pohjalta. Vaikka me Goforellakin rakastamme teknologiaa ja varsinkin sen tuomia mahdollisuuksia, haluamme auttaa asiakkaitamme luomaan parhaan mahdollisen pohjan myös muistakin näkökulmista. Pilvipalveluiden hallintamallissa tulisikin ottaa huomioon kaikki ne tylsät ei-tekniset asiat, joita tarvitaan arjen sujumiseen ja liiketoiminnan jatkuvuuteen liittyen.


Hyvän pilven hallintamallin perusta

Pilven hallintamallin tulisi ottaa kantaa siihen, mitä ja miten pilvipalveluita yrityksessä käytetään sekä ylläpidetään. Lisäksi tulee huomioidaan uusien tuotteiden tai palveluiden kehitys. Ovatko kaikki palvelut yrityksen omassa hallinnassa, toimittajan hallinnassa vai kenties Cloud Center of Excellencen, joka joustavasti käyttää tarvittavia resursseja sieltä, mistä niitä on saatavilla? Miten liiketoiminta saa apuja, kun uutta palvelua ollaan miettimässä ja tarvittaisiin teknistä osaamista projektiin? Miten palveluiden tietoturva ja tietosuoja varmistetaan ja mitkä ovat yhteiset pelisäännöt? Miten pilvipalvelut viedään tuotantoon, niin että arki on sujuvaa projektin jälkeenkin?

Näemme liian usein, että vain teknisiin asioihin otetaan kantaa ja kaikki on kivaa, kunnes kehittäjät siirretään seuraavaan mielenkiintoiseen projektiin. Organisaation IT-osastolle jää pahimmassa tapauksessa tekemätön paikka, kun sovellus tarvitsee jatkokehitystä tai vaativampia muutoksia.

Olemme vahvasti sitä mieltä, että pilven hallintamallin pitää kattaa vastuut, käytännöt ja prosessit pilvipalveluiden kehittämiseen ja ylläpitoon liittyen. Tukea tarvitaan ideasta ja tuotantoon, jotta homma oikeasti toimii.

Teoriasta käytäntöön

Koskaan ei ole liian myöhäistä aloittaa – hyvä pilven hallintamalli on tulevaisuudessa elintärkeä asia on monille organisaatioille.

Asioita, joita painotamme, kun autamme asiakkaitamme rakentamaan toimivaa hallintamallia:

  • Selkeät vastuut
    • Mistä asiakas itse vastaa ja mitkä asiat ovat puolestaan toimittajan vastuulla ja päätettävissä – sopiva kombinaatio valtaa ja vastuuta
  • Organisointi
    • Miten pilvipalveluiden ympärille järjestäydytään? Miten projektit saavat apua teknisiin tai arkkitehtuurillisiin kysymyksiin? Miten projektit viedään tuotantoon?
  • Yhteiset pelisäännöt tietoturvan ja tietosuojan osalta
    • Pilvipalveluiden välillä on eroa esimerkiksi lokituksessa ja valvonnassa. Miten varmistetaan, että kaikki palvelut ovat samojen pelisääntöjen piirissä ja järkevästi hallittuja?
  • Pilvipalveluiden ylläpito
    • Arkkitehtuuri ja teknologia ovat tärkeitä, mutta myös prosessit ja käytännöt näiden ympärille. Missä sijaitsevat ohjeet, mitä työkaluja käytetään, mitä tukimallia sovelletaan sovelluksille ja miten yhteistoiminta muiden kumppaneiden kanssa onnistuu?

Mikäli tuntuu, että tarvitset näiden asioiden kanssa tukea, olehan epäröimättä meihin yhteydessä.

 


Haluatko pilvipalveluista aidon hyödyn irti?

 

Ota askel tavoitetta kohtaan ilmoittautumalla maksuttomaan GTalks-webinaariimme ”Pilven hyvät perusteet”, joka pidetään 9.3.2021 klo 09.00-10.30. Webinaarin asiantuntijoina toimivat blogin kirjoittaja Joonas Vuorela sekä Goforen pilvikonsultti Jussi Puustinen. Webinaarin juontaa Goforen pilvikumppanuuksista ja -koulutuksista vastaava Tiia Hietala.

LISÄTIETOJA JA ILMOITTAUTUMINEN

Joonas Vuorela

Joonas Vuorela

Joonas Vuorela toimii Goforella johtavana ICT-konsulttina ja häntä motivoi asiakkaiden auttaminen ICT-infrastruktuurien, pilvipalveluiden sekä pilven paremman hallinnan parissa. Mikään ei ole Joonaksen mielestä (ammatillisesti) hienompaa kuin asiakkaan johdattaminen kestävämmälle ja innostavammalle polulle pilviteknologioiden kanssa.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Julkipilvialustoiden käyttöönotto on vaivatonta ja nopeaa. Aloittelijakin saa nopeasti näkyvää aikaiseksi, virtuaalikoneen pystyttäminen käy kymmenissä sekunneissa. Luottokortti sisään ja projekti käyntiin, se mitä ei osata voidaan opetella matkan varrella, eikö niin?

Helppoudessa piilee myös riskinsä. Vaikka alustatoimittajat panostavat paljon esimerkiksi turvallisuuteen, kokematon voi helposti rakentaa turvattoman ympäristön. Ammatitaitoa tarvitaan myös kuhunkin käyttötapaukseen tarkoitetun ratkaisun valinnassa. Esimerkiksi varattu, mutta käyttämätön kapasiteetti voi kerryttää tarpeettomia kustannuksia.

Projekteille annettu täysi vapaus toimia voi myöhemmin kostautua myös hallinnoinnin hankaluutena sekä kohonneina kustannuksina. Luottokorttien varaan nopeasti projektien tarpeisiin pystytetyt ympäristöt saattavat koostua tarpeettomista päällekkäisistäkin ratkaisuista.

Vankan perustan päälle on turvallista rakentaa

Aivan kuten rakennushankkeissakin, turvallinen ja vakaa perusta takaa pohjan, jonka päälle on turvallista lähteä rakentamaan. Hyvä perusta tarjoaa mahdollisuudet myös laajennuksille. Perustan korjaaminen jälkikäteen saattaa olla työlästä ja sitä kautta kerryttää turhia kustannuksia.

Pilviprojektin alussa ei asioita kuitenkaan valeta betoniin, vaan konfiguraatiota voidaan päivittää tarpeen mukaan käytön laajentuessa. On hyvä varmistaa, että seuraavat kokonaisuudet on huomioitu jo projektin alkuvaiheessa:

  • Esimerkiksi tilirakenteiden, verkkoyhteyksien sekä tunnistautumiseen liittyvien peruskomponenttien suunnittelu. Niiden avulla perustan hyödyntäminen lähtee oikein liikkeelle.
  • Roolipohjainen pääsyn- sekä käyttäjienhallinta luo selkeyttä ja parantaa turvallisuutta.
  • Hyvin suunnitellut verkkojen rakenteet myös pilven sisällä parantavat turvallisuutta sekä käytön selkeyttä.
  • Salaisuuksien hallinnointi on myös syytä suunnitella ja kommunikoida selkeästi.

Tarpeen mukaan myös tiettyjä pilven tarjoamia palveluita voidaan rajata normaalikäytön ulkopuolelle – harva käyttötapaus tarvitsee vaikkapa supertietokoneiden laskentatehoa. Kustannuksia niillä kuitenkin voi nopeasti kerryttää. Maantieteellisen sijainnin rajaaminen on usein myös perusteltua, käyttäjiä lähinnä olevan kohteen (regioonan) valinta on usein luonnollinen tapa aloittaa, varsinkin jos se tarjoaa riittävän laajan palveluportfolion. Rajaus voidaan tehdä johonkin tiettyyn yksittäiseen regioonaan vai vaikkapa EU/ETA alueelle.

Käytön laajentuessa tyypillisesti vastaan tulevat myös erilaiset monitorointiratkaisut, logien hallinnointi ja esimerkiksi vikasietoisuuden lisääminen ja varmistaminen.

Osaava kumppani auttaa oikeiden valintojen tekemisessä ja perusperiaatteiden määrittämisessä. Piirrustusten tekemiseen ei suinkaan tarvitse käyttää viikkoja ja samalla tulee varmistettua se, että pilviperusta noudattelee alustatoimittajien suosittelemia parhaita käytänteitä.

Cloud Foundation vai Landing Zone?

Termiviidakkoon on helppo eksyä. Eri alustat puhuvat pilviperustasta hiukan eri nimillä tavoitellen kuitenkin samaa asiaa. Helpoimmillaan toimittaja tarjoaa valmiita aihioita, joissa perustan luominen onnistuu koodia hyödyntäen.

Perustan suunnittelu ei siis suinkaan muodosta projektin aloitukselle hidastetta, vaan ennemminkin varmistaa sujuvan työskentelyn ja resurssien tehokkaan käytön jatkossa.

Laajempien kokonaisuuksien osalta on järkevää miettiä myös oman pilveen keskittyneen osaamiskeskuksen perustamista, mikä tarjoaa projekteille tukea ja asiantuntemusta tehokkaan pilven hyödyntämisen varmistamiseksi.

Laajenna hallitusti, operoi tehokkaasti

Järkevä ja hallitusti rakennettu perusta tarjoaa mahdollisuudet myös laajentaa käyttöä uusiin käyttötapauksiin; perustan päälle voi rakentaa kokonaan uusia ratkaisuita tai vaikkapa siirtää olemassa olevia. Keskitetty kustannusten hallinta mahdollistaa kulujen optimoinnin ja varmistaa näkyvyyden kokonaisuuteen.

Tuotekehityksen tehostaminen keskitettyjen Devops-käytänteiden avulla sekä pilviarkkitehtuurin korkea automaatioaste minimoivat tarpeen manuaalisille operaatioille varmistaen tehokkaan ja modernin pilven operoinnin. Automaattinen toipuminen virhetilanteista ei ole enää tieteiskirjallisuutta.

Kohti kestävämpää, aitoa hyötyä

Julkipilvialustoiden myötä ICT-arkkitehtuurien rakentamisen vauhti on muuttunut kuukausista ja viikoista tunteihin ja päiviin. Vauhti ei kuitenkaan saa olla niin suuri, etteikö alussa kannattaisi pysähtyä muutamien perusasioiden äärelle ja sitä kautta varmistaa tehokas ja turvallinen pilven hyödyntäminen myös jatkossa. Turvallisuus, skaalautuvuus ja operoinnin vaivattomuus eivät ole itseisarvoja pilvessäkään, mutta hyvin suunnitellun perustan avulla voidaan varmistaa aidon hyödyn saavuttaminen.

 


Haluatko pilvipalveluista aidon hyödyn irti?

Ota askel tavoitetta kohtaan ilmoittautumalla maksuttomaan GTalks-webinaariimme ”Pilven hyvät perusteet”, joka pidetään 9.3.2021 klo 09.00-10.30. Webinaarin asiantuntijoina toimivat blogin kirjoittaja Jussi Puustinen sekä Goforen johtava pilvikonsultti Joonas Vuorela. Webinaarin juontaa Goforen pilvikumppanuuksista ja -koulutuksista vastaava Tiia Hietala.

LISÄTIETOJA JA ILMOITTAUTUMINEN

Jussi Puustinen

Jussi Puustinen

Jussi Puustinen vetää Goforella Cloud&DevOps -yksikköä ja hän on ulkoilmaa rakastava IT-ammattilainen, jolle jatkuvan asiakasarvon luominen on lähellä sydäntä. Jussilla on kokemusta IT-palveluiden koko elinkaarelta yli 10 vuoden ajalta - aina strategisesta suunnittelusta toteutuksiin ja alasajoon asti. Hän kukoistaa saadessaan auttaa asiakkaita hyödyntämään uusia teknologioita tuloksellisesti.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Löydä organisaatiollesi sopiva lähestymistapa pilvipalvelujen hyödyntämiseen

Kaikki ovat varmasti kuulleet pilvipalveluista, osa jopa tietää, mitä ne ovat, mutta lähes kaikilla on niihin varsin vahva mielipide. Lähestyminen pilvipalveluihin näyttää olevan hyvin kaksijakoista.

Osa asiantuntijoista suhtautuu hyvin epäilevästi pilveen. Pilveä pidetään epämääräisenä ja erityisesti monessa suhteessa epäluotettavana. Pilvipalvelut ovat ”tuolla jossakin” ja niitä operoi ja käsittelee ”ties kuka” ja mitäs sitten tehdään, jos verkkoyhteydet ovat poikki. Monessa organisaatiossa epäillään, voidaanko mitään olennaisia palveluja siirtää pilveen ja joissakin pilvipalvelujen käyttö on kokonaan vielä kiellettyä. Tätä lähestymistapaa voidaan pitää kirjoittamattomana ”no cloud” -strategiana.
Toisessa ääripäässä ovat pilvihurahtaneet. Pilvi nähdään kiinnostavana teknologiana, joka sopii kaikkeen ja kaikki palvelut tulisi siirtää välittömästi pilveen ja hyödyntää ainoastaan pilvipalveluihin. Tätä innostunutta pilviteknologiapohjainen näkemys vastaa dokumentoimatonta ja hyväksymätöntä ”cloud only” -strategiana.

Koska usein näitä kahta hyvin vastakkaista lähestymistapaa esiintyy saman organisaation sisällä, organisaation kannattaa linjata, miten se suhtautuu pilvipalveluihin – tarvitaan dokumentoitu, käsitelty ja hyväksytty pilvivisio ja pilvistrategia.

Pilvi vai kattilasta nousevaa höyryä?

Tyypillinen ensimmäinen ongelma pilvipalvelukeskustelussa on, että eri ihmisillä on erilainen näkemys, mitä pilvipalvelut itse asiassa ovat. Osalle sana pilvi tarkoittaa ”mitä tahansa IT-jutskaa, joka ei oo meidän konesalissa”. Iso osa alkaa ottaa kiivaasti kantaa, onko AWS:n virtuaalialustat tai kehittämisvälineet parempia kuin MS Azuren. Joku muistaa, että järjestelmiä ollaan hankkimassa ehkä SaaSina.
Pilvipalveluiden käyttöä linjatessa on hyvä ottaa erityisesti kantaa julkipilvipalveluihin – vakiintuneisiin ja laajasti useille asiakkaille tarjottuihin tuotteistettuihin pilvipalveluihin, jotka joustavat ilman etukäteisvarausta hyvin asiakkaiden tarpeisiin. Jokainen toimittajan itse pyöräyttämä virtuaalialusta ei ole vielä pilvipalvelu.

Kovin usein pilvipalvelukeskustelut rajautuvat pilvialustoihin. Kuitenkin hyvä periaate, jota esim. Suomen julkisen hallinnon pilvilinjauksissa noudatetaan, on se, että pilvipalvelutarkasteluun sisällytetään kaikki pilvitoimintamallit, IaaS (Infrastructure as a Service), PaaS (Platform as a Service), SaaS (Software as a Service) ja BPaaS (Business Process as a Service). Hyvät pilvilinjaukset kattavat nämä kaikki.

Mustavalkoisesta harmaan eri sävyihin – fiksusti pilvestä

Pilvipalvelut ovat tulleet jäädäkseen. Niiden kategorinen kieltäminen on kuin kaasuvaloasiantuntijoiden kriittinen suhtautuminen sähköön – ei tule toimimaan ja varmaan on vaarallista. Esimerkiksi valmisohjelmistoissa on siirrytty tai ollaan aktiivisesti siirtymässä lähes yksinomaan pilvipalvelumalliin. Uusia valmisohjelmistoja ei kehitetä enää käytännössä lainkaan asiakkaan itse asennettavaksi. Jo lähivuosina voi olla vaikea edes löytää toiminnan tarpeisiin soveltuvia paikallisesti asennettavia aktiivisesti kehitettäviä valmisohjelmistoja. Kyse ei siis ole enää siitä, käytetäänkö pilvipalveluja lainkaan, vaan kuinka pilvipalveluja käytetään turvallisesti ja miten niistä saadaan hyödyt irti?

Pilvipalvelujen kohdalla tulisi luopua ”kaikki tai ei mitään” -asenteesta. Usein pilvipalveluja lähestytään nykyisin ns. Cloud Smart -lähestymistavalla, jossa pilvipalvelujen soveltuvuus arvioidaan tapauskohtaisesti. Aivan kaikkia palveluja ei määräysten tai jatkuvuustarpeiden takia kannata viedä pilveen, mutta suuren osan palveluista voi.

Pilvistrategia ja täsmällinen kehittämispolku muutoksesi tukena

Määritelkää organisaatiossanne oma strategianne pilvipalvelujen hyödyntämiseen:

  • Linjatkaa kattavasti, miten pilvipalveluja voidaan hyödyntää organisaatiossanne?
  • Millä periaatteilla ja linjauksilla pilvipalveluja hankitaan tai kehitetään ja mitä niillä tavoitellaan?
  • Tarkastele kaikkia pilvipalvelumalleja (IaaS, PaaS, SaaS, BPaaS) ja tarkastele koko pilviratkaisun elinkaarta.

Pilvivisio ja -strategia luovat erinomaisen yhdessä sovitun päämallin pilvipalvelujen hyödyntämiseksi organisaatiossa. Pilvipalvelujen hyötyjä ei kuitenkaan pystytä realisoimaan pelkällä strategialla. Suunnitelkaa systemaattinen ja kattava sekä mitattava kehittämispolku pilvipalvelukyvykkyyksien (osaaminen, teknologia, hallintamallit, ohjeet, hankintamenettelyt) kehittämiseen.

Linjaa rohkeasti, dokumentoi täsmällisesti, hyväksy ja sitoudu.

 


 

Haluatko pilvipalveluista aidon hyödyn irti?

Ota askel tavoitetta kohtaan ilmoittautumalla maksuttomaan GTalks-webinaariimme ”Pilven hyvät perusteet”, joka pidetään 9.3.2021 klo 09.00-10.30. Webinaarin asiantuntijoina toimivat Goforen johtavat pilvikonsultit Jussi Puustinen ja Joonas Vuorela. Webinaarin juontaa Goforen pilvikumppanuuksista ja -koulutuksista vastaava Tiia Hietala.

LISÄTIETOJA JA ILMOITTAUTUMINEN

Mika Karjalainen

Mika Karjalainen

Goforen kyvykkyys- ja ekosysteemikonsultoinnin kehittäjä ja perimmäinen konsultti Mika Karjalainen, joka on ollut mukana satojen menestystarinoiden rakentamisessa asiakkaillamme. Mika uskoo, että uudistumisen aika on aina.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Native DevOps

Native DevOps

Since DevOps as practice has gained huge amount of attention and popularity, new variants keep popping up like in the game whack-a-mole. Amidst this whirlwind, it is important to remind yourself – What is True DevOps?

DevOps lifecycle

The Problem

In a traditional setting, a gap exists between producing value (development) and delivering that value to the customers (operations). This gap slows down the production of any customer value, and in many cases, what is being produced does not have anything to do with the real value that is actually expected.

The second root cause for issues is speed and feedback. Traditionally, programming is a slow task to complete and so is the integration and deployment of changes. Also, the chasm between developers and end customers can be too wide to provide any sort of tangible feedback for the produced solutions, at any scale.

The third major problem is that Agile has become the driving force in software development. This new Lean based methodology promises distributed decision-making and faster time-to-market. Unlike traditional frameworks like ITIL, success is not built on a command-and-control structure. This means that development teams often try to optimize their work and outcomes without understanding the bigger picture. This has resulted in major issues in the operations of these solutions. The promise of faster time-to-market is often misinterpreted as releasing new features as fast as possible while ignoring everything else.

The Solution

Along came the idea of DevOps. The gap between Development and Operations is eliminated by combining the two into a single team. This team now has the responsibility and the freedom to develop and operate their software product without external dependencies. The foundation of DevOps was built on top of Lean principles and automation. The core pillars of DevOps are Flow, Feedback and Continuous Learning.

The Flow is based on Lean’s continuous flow of small batches. Continuous flow is often described as shortest sustainable lead time. Small batches refer to the fact the smaller the item size the easier it is to control the flow. The Flow in DevOps is achieved through Continuous Integration & Continuous Deployment (CI/CD) and Infrastructure as Code (IaC).

Feedback is the guiding light for DevOps. There is no DevOps cycle without fast and continuous feedback on every phase of the cycle. Continuous flow requires data-driven decision-making. Fast feedback is achieved through test automation and automated monitoring. There is no CI/CD without test automation. Automated monitoring enables e.g., proactive responses to potential incidents.

Continuous Learning is about e.g., failing often and failing fast. It also about using the received feedback to the betterment of the team and the product. Continuous Learning is mindset of never-ending experimentation in search of new and better practices, product features and flow optimization through automatization.

The cornerstone of DevOps is the phrase ’Automate Everything’. Automatization is the way of reaching flow, feedback, and continuous learning in the development & operation of a software product. Automation is present from start to finish in the DevOps cycle. Automation enables the DevOps team to focus on value adding tasks.

Key takeaways

  • DevOps is about Flow, Feedback and Continuous Learning
  • DevOps is a solution to a specific set of problems when creating customer value through a software product.
  • There is no DevOps without extensive automation.
Tommi Ferm

Tommi Ferm

At Gofore, Tommi works as the Head of Offering, Software Testing & Software Quality Assurance. His colorful journey took him from Software Testing, Management Consulting to Offering Development. Tommi is passionate about Value Creation, System Thinking and Continuous Improvement. He is also avid supporter of the Lean-Agile practices and DevOps.

Linkedin profile
Jani Haapala

Jani Haapala

Jani works as a DevOps architect at Gofore. He is passionate about measurement, feedback, and continuous automated quality feedback loops. Jani’s journey started from manual testing and has evolved to full-scale software development automation. Jani thinks that automation can help everybody and increase value in anything.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Lomalta palatessa Pasilan kohdalla alkoi olla epäuskoinen olo. Juna kulkee monen betonilähiön ohi. Täälläkö minä asun? Helsingin päärautatieasema. Junalaiturilta suoraan rullaportaisiin, betonibunkkeriin, toisiin rullaportaisiin ja metroon. Kävelen kasvottoman ihmisvirran keskellä. Se virtaa aivan liian lujaa. Mihin näillä ihmisillä on kiire Mitä helvettiä minä täällä teen?

Muutin valmistumisen jälkeen Helsinkiin töiden perässä. Jännittävät uramahdollisuudet odottivat ja olo oli innostunut. Oltiinhan sitä Suomen pääkaupungissa! Kotoa Itä-Suomesta Helsingissä ei oltu käyty turhan usein. Nyt menin hienoissa vaatteissa metrolla töihin ja harrastuksiin. Monipuoliset työmahdollisuudet ja työpaikan moderni kulttuuri viehättivät

Alun jännityksen haihtuessa aloin kokea oloni kuin maahanmuuttajaksi. Se oli kummallista. Olinhan sentään kotimaassani. Tunsin, että minun täytyi sopeutua ja kulkea läpi kulttuurillisesta integroitumisputkesta. Piti tottua puhumaan kuin helsinkiläinen, likistymään lähelle ihmisiä ruuhkaisessa metrossa ja sukkuloimaan sujuvasti vellovan ihmisjoukon osana. Reilun vuoden aikana minusta alkoi tulla siinä aika hyvä. Samalla koin, että olin itse muuttumassa. En ollut varma pidinkö uudesta minästäni.

Kuulin paljon puhetta siitä, miten pääkaupunkiseudulla on parhaat työmahdollisuudet. Vallalla tuntui olevan käsitys, että haastava tai kunnianhimoinen työ tehdään Helsingissä, ja muualla Suomessa työnteko on pelkkää puuhastelua. Lopulta jopa itsekin uskoin siihen. Ajattelin, että pääkaupunkiseudulta pois muuttaminen olisi hyvästit omille uramahdollisuuksille.

Matkustin pitkästä aikaa junalla pois kaupungista. Kehä kolmosen jäädessä taakse huomasin, miltä tavallinen maailma näyttää. Se oli päässyt unohtumaan. Oli metsää, puita, ränsistynyt lato pellon keskellä. Kohtapa ei ollutkaan enää muuta kuin metsää ja soita. Alkoi tuntua kotoisalta. Mieli alkoi rauhoittua. Saattoi melkein tuntea, kuinka verenpaine laski. Sain taas kosketuksen siihen, mikä minä olen, mikä on oikeasti tärkeää ja missä omat juuret ovat.

Huomasin, että Helsinkiin muuttamisen jälkeen elämä oli muuttunut kiireiseksi. Joka paikkaan liikkuminen vei paljon aikaa. Tunti töihin, tunti kotiin, tunti kaverin luo. Ehdinkö seuraavaan metroon? Kolmen minuutin odotus seuraavaan alkoi tuntua ikuisuudelta.

Koin olevani risteyksessä. Minulle tuli vahva kokemus siitä, että Helsingissä ei ole hyvä olla. En ollut kotonani, vaan tarvitsin pienemmät piirit ja oikeat talvet lähellä luontoa. Nyt oli lähdettävä.

Kun päätös oli tehty, muutos oli helppo. Halusin lähteä takaisin opiskelupaikkakunnalleni Jyväskylään. Kerroin asiasta meillä Goforella, eikä siinä nähty mitään ongelmia. Pakkasin laukut ja läppärin ja heitin hyvästit pääkaupunkiseudulle, kun koronakaranteenin pahin vaihe oli ohitse. Allekirjoitin lapun, jossa sovittiin kotitoimiston siirtymisestä Helsingistä Jyväskylään. Muuta byrokratiaa tai selityksiä ei vaadittu.

Jyväskylän toimistolla minut otettiin hyvin vastaan. Kaupungin ydinkeskustan konttori on vähintään yhtä hieno kuin Kampin yläkerran toimisto. Nyt saan olla osa ihmisen kokoista työyhteisöä, mikä sopii minulle paljon paremmin. Espressot saa yhä tehtyä, kuten kaupungissa kuuluu, mutta työmatka taittuu viidessä minuutissa.

Sain jatkaa töitä sujuvasti samoilla asiakkailla. Tälläkin hetkellä kilpailen Jyväskylästä käsin samoista asiakkuuksista helsinkiläisten kollegoiden kanssa. Etätyö toimii, ja asiakaskin on siihen sitoutunut. Tarvittaessa käyn asiakkaan toimistolla ja muuten kotoa on mukavaa tehdä töitä. Harha siitä, että vain Helsingissä voi olla kunnianhimoinen urallaan, on haihtunut.

Se, mikä sen sijaan on muuttunut, on oma elämä ja ajankäyttö. Ilman työmatkojen kulkemista aikaa jää kaikelle muulle: kitaransoitolle, kavereiden kanssa hengailulle ja ihan vaan oleilemiselle. Aika ei tuhraannu ruuhkabusseissa istumiseen. Elämä tuntuu taas normaalilta.

Etätöiden lisääntyminen vähentää työ- ja asuinpaikan välisiä ristiriitoja. Työpaikan ei tarvitse enää määritellä sitä, missä täytyy asua. Toivon, että koronan väistyttyä etätyöstä tulee uusi normaali. Etätyö toimii ja antaa liikkumavaraa elää sellaista elämää, mikä itselle sopii. Omalla kohdallani se tekee unelmista totta.

Haaveenani on oma asunto. Kolmesataatuhatta on sellainen laina, jonka diplomi-insinööripariskunta vielä maksaa menettämättä yöuniaan. Helsingin Kalliosta summalla saa vaivaisen hikimajan. Muualta Suomesta sillä saa hulppean omakotitalon.

Lähden helmikuun alussa viikoksi Lappiin etätöihin. Aion koodailla, lasketella ja katsella poroja. Matkalla pysähdyn hetkeksi sukuloimaan kotipaikkakunnallani. Työ ja vapaa-aika on tasapainossa eikä ole koko ajan kiire.

 

Goforella saat tehdä työsi siellä, missä sydämesi asuu – olipa se sitten maalla, kaupungissa, merellä tai metsän siimeksessä. Me nimittäin uskomme, että vapaus on paras työnjohtaja. Lue lisää: Paikatonta työtä

markusmulkahainen

Markus Mulkahainen

Markus on ohjelmistosuunnittelija ja tanssiharrastaja. Hän aloitti koodaamisen työskennellessään Nesteen öljytankkerilla, josta palautti ohjelmointitehtäviä satelliitti-internetin välityksellä Helsingin yliopiston ohjelmoinnin mooc-kurssille. Innostus vei lopulta yliopisto-opintoihin ja Markus valmistui 2019 diplomi-insinööriksi Tampereen teknillisestä korkeakoulusta pääaineina ohjelmistotuotanto ja koneoppiminen. Markus työskentelee full stack -kehityksen parissa ja on kiinnostunut pilvipalveluista ja tekoälystä.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Paikaton työ tuli jäädäkseen

Liki vuosi on jo vierähtänyt tämän ”uuden normaalin” työelämän parissa, jonka Covid-19 toi tullessaan. Virus pakotti muuttamaan työn tekemisen tapoja ennennäkemättömällä rytinällä, sillä vaihtoehtoja ei juuri ollut. Vielä pandemian alussa odotimme, milloin pääsisimme palaamaan vanhoihin, tuttuihin työrutiineihin, mutta nyt, vuoden vierittyä, vanhaan palaaminen alkaa tuntua… noh, vanhalta. Olemme siirtymässä uuteen post-covid -työelämään ja yritykset sekä työntekijät jo kilvan visioivat, millainen se voisi olla ja mitkä poikkeusajan käytännöt ovat kenties tulleet jäädäkseen.

Elämme siis sangen mielenkiintoisia ja inspiroivia, jopa historiallisia aikoja. Harvoin on ollut mahdollista muotoilla ja suunnitella työelämää haluamaksemme samalla tavoin kuin nyt. Samalla järkähtämättöminä pidetyt lainalaisuudet, kuten se, että työ sitoo ihmisen yhteen, vakituiseen asuinpaikkaan, ovat murtumassa.

Vuosia IT-rekrytoinnissa työskennelleenä voin yhtyä näkemykseen, että alan osaajamarkkina kuhisee kuumempana kuin koskaan. Asiantuntijoille riittää ottajia ja työnantajat pohtivat otsat hiessä, miten pysyä mukana kilpailussa todellisista osaajista ja löytää töihin parhaat tekijät. Me Goforella haluamme luoda erilaisia työnteon muotoja, joista jokainen voi valita omaan elämäntilanteeseensa ja arvoihinsa sopivan – sellaisen, jossa työntekijä voi parhaiten ja tekee siksi myös parasta jälkeä. Me nimittäin uskomme, että valinnanvapaus ja luottamus ovat mitä parhain työnjohtaja ja motivaattori. Siksi päätimme tarjota mahdollisuuden paikattomaan työhön.

Tiedämme toki, että ihmiset ovat erilaisia ja arvostavat eri asioita. Siksi paikaton työ ei sido sen enempää paikkaan kuin paikattomuuteenkaan. Se vapauttaa valitsemaan yhden tai yhdistelemään useita erilaisia vaihtoehtoja.

On heitä, jotka eivät enää koskaan mieli palata toimistolle. Heille on tärkeää, että työtä voi tehdä siellä, missä sydän asuu – olipa se sitten maalla, metsässä tai vaikka meren luodolla. Kaikki työ hoituu etänä. Toiset taas löytävät omansa hybridimallista: etätyö on iso osa arkea, mutta toimisto- ja asiakaskohtaamiset tuovat viikkoon vaihtelua ja makua. Tärkeintä on, että paikkaa voi vaihtaa niin halutessaan. Ja onpa heitäkin, jotka odottavat jo toimistolle pääsyä ja kokevat etätyön välttämättömänä pahana ja toivovat, että tulevaisuudessa palaverit pidettäisiin taas naamatusten.

Työnantajana meidän vastuullamme on tehdä kaikista näistä työtavoista ja niiden yhdistelmistä mahdollisia ja tarjota kaikkiin tarvittava tuki ja puitteet. Mielikuvissamme kajastelee jo tulevaisuus, jossa meitä goforelaisia työskentelee Helsingistä Lappiin ja Savon sydänmailta rannikkoseuduille!

Millainen sitten onkaan sinulle omin työnteon malli ja millaiseksi ikinä hyvän työelämän määritteletkään, me haluamme olla jakamassa sen kanssasi. Emme vielä ole täydellisiä virtuaalisia perehdyttäjiä emmekä varmaan osaa vielä kuvitella kaikkia eteen sattuvia yllätyksiä, mutta haluamme – ja lupaamme – oppia. Sinä ja me, yhdessä.

Terveisin,
Anni

P.S. Lisää asiaa paikattomasta työstä: gofore.com/paikaton

Anni Roinila

Anni Roinila

Anni Roinila on rekrytoinnin ammattilainen ja vastaa nykyisessä roolissaan myös Goforen työnantajakuvasta. Hän on seurannut mielenkiinnolla rekrytoinnin murrosta viimeisten vuosien aikana, sekä sitä miten voimakkaasti sekä rekrytoijan että työnhakijan roolit ovat muuttuneet. Anni innostuu tavoitteellisesta tekemisestä ja näkee rekrytoinnin asiantuntemuksen tärkeänä tekijänä myös yrityksen kasvun mahdollistamisessa. Anni rakastaa nauramista, inspiroituu hyvistä keskusteluista ja seuraa mielellään pöhköjä Twitter -ketjuja.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Is your business Agile?

How to tell if your business is Agile? How to ask from a C- level people whether their organisation is Agile?

From small to big

There are tons of advice on how to measure agility at a team level; Velocity, Burndown, Planned vs Actual, Work in Progress, DevSecOps, etc. All these measures aim to estimate and optimize the long-term work capacity and work quality of a team.

However, when assessing overall Agility at an organisational level, we need to take a step back. The main idea of a business is to deliver maximum added value to stakeholders. Therefore, we need to bring our attention from “HOW” to “WHAT”. The main idea of Agile is to accelerate the decision-making-and-learning loop. The Decision Driven Organization by Harvard Business Review 06/2010 had a Quick Test of Decision Effectiveness, which describes nicely the Agile mindset:

  • Quality: When looking back on critical decisions, you find that you chose the right course of action most of the time.
  • Speed: You make critical decisions much faster than competitors.
  • Yield: You execute critical decisions as intended most of the time.
  • Effort: In making and executing critical decisions you put in exactly the right amount of effort.

Agile Leadership

Without leadership, an organisation slides down to an ad-hoc Limbo. While being agile, the organisation still needs a strategy, a long-term vision. Parallel, you must avoid mid-term planning. Mid-term planning turns into a middle-management, where both the long-term vision and the short-term agility is lost. Mid-term planning is a waste.

In Agile it is OK to fail. Failure means learning. Agile is about embracing the scientific approach: hypothesize, test, analyze and decide to preserve or pivot. It is OK to run multiple hypotheses’ in parallel with the ’Least-fit’ principle instead of selecting a single idea and running with it. Dare to start parallel strategic change projects and after some time kill the failing ones. A/B testing is a fast way to learn more.

Lean Management

Bureaucracy tends to fulfill all the gaps. Bureaucratic managers will always figure out new ways to measure, manage and control. Bureaucracy never leads to a better business.

Bureaucracy lives from the fear of uncertainty, but it will not fix the uncertainty.

Uncertainty is a byproduct of complexity. You can reduce both bureaucracy and uncertainty by making information transparent and keep the decision making as close to the operations as possible. As Scaled Agile Framework states, continuous learning focuses on relentless improvement, where improvement activities are fact-based, and increase the effectiveness of the entire system instead of silos.

Management is about making decisions. Making hard decisions is difficult. A weak manager easily lists a dozen of things where you must focus next. “Let’s first focus here, and then here, and let’s keep our options open also here”. This is slack decision making and a waste of energy. A strong manager lists only one thing. “Let’s focus here and say ‘No!’ to everything else”. In an Agile mindset, you focus a period of time on the thing that matters the most. Then you reflect and learn.

Complex Business

Reductionism means that you can solve a problem by breaking it down into smaller parts, solving the small problems, and then putting it all back together again. This works in a simple environment. However, the assumption that past experience leads to a deterministic future solution is valid only within an ordered system. With enough data, you can find a correlation between anything. “People drown when they eat more ice cream”. But this does not imply causation. Problems arise when the work is based on wrong assumptions. In a complex environment, you need trials, where you break the system into components, study their interactions and create a holistic model of the system as a whole. The situational awareness model helps you with such systemic decision making.

Small investments can be made into safe-to-fail experiments in a balanced portfolio before committing more resources. Traditional enterprise control mechanisms doesn’t work with Agile mindset, while traditional annual budgeting doesn’t support the fail-fast principle. Still, you can still make agile decisions along the way about what to do with the budget.

Agile Resiliency

Even an Agile organisation needs a fast re-planning mechanism, which triggers if a positive opportunity or a negative risk materializes. Re-planning means you stop the ongoing planning cycle, re-plan a new cycle and keep going. As long as the long-term strategy is viable, you need to reset only the latest short term cycle. You are able to make fast decisions concerning the short term direction.

Again, at the event of sudden change, a weak manager tends to re-plan everything from long term strategy to mid-term plan and finally to short term actions. This is slow, slobby and useless. At the event of a sudden change, you need to make fast decisions. Fast decisions are a sign of resilience. Fast decisions enable you to exploit sudden opportunities and avoid quick threats.

Agile Predictability

Embracing Agile by Harvard Business Review 05/2016 states ”Some executives seem to associate agile with anarchy.” While an Agile organisation can make fast adjustments, the wider direction is still based on a long-term vision. Often the vision translates into a short-term roadmap, which customers can use safely to plan their own activities. In addition, the roadmap prevents individual teams from being siloed off. Vision and roadmap empower decentralized decision making by enabling everyone to work towards a common goal.

Agile checklist

  • Have a transparent vision
  • Near term future is churned into a prioritized backlog
  • Most of the time is used on the items at the top of the backlog
  • Measures are transparent and they provide additional value for the stakeholders
  • Seek automate everything and have an effective DevOps running
  • Constantly innovate on how to deliver value faster for your stakeholders
  • People feel safe and they trust on each another
  • People start their own initiatives. The swarm intelligence produces new business opportunities
    Have an ability to have difficult conversations.

If the article got you interested, scared or angry, please do not hesitate to contact us. We are here to help.

Jari Hietaniemi

Jari Hietaniemi

Jari Hietaniemi is an enthusiastic digitalization consultant. He specialises in complex and vast software projects. His philosophy is based on thinking that a consultant must know technology, architecture, project management, quality assurance, human resources, coaching and sales. His versatile experience and constant quest for improvement help to finish projects successfully and to bring new drive into client organizations.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Testaus ja testiautomaatio on aiemmin mielletty lähinnä yhdeksi osaksi ohjelmistokehitystä, mutta digitalisaation kehityksen myötä aihe on tullut tutuksi lähestulkoon jokaisessa yrityksessä. Monessa tapauksessa testaaminen ja liiketoiminnalle kriittisten prosessien varmistaminen on pudonnut yrityksen syliin ostettujen järjestelmien mukana vähän yllättäen. Esimerkiksi pilvipohjaisiin järjestelmiin siirryttäessä ei ole välttämättä osattu ennakoida kuinka isosta ja pysyvästä muutoksesta testaamissa on kysymys.

Tilannetta vaikeuttaa se, että vaadittavassa laajuudessaan aihe on monelle yritykselle uusi eikä olemassa olevaa testauskulttuuria tai muuttuneeseen tarpeeseen skaalautuvia käytäntöjä vielä ole. Testausrupeamat ovat aiemmin hoituneet muutamien järjestelmäasiantuntijoiden johdolla ja kohdistuneet usein hyvinkin spesifeihin ja ennalta tiedettyihin muutoksiin. Mitään laajamittaista ja säännöllistä regressiotestausta ei ole tehty, tai sitä on tehty todella harvoin.

Kun järjestelmätoimittajien versiopäivityksiä alkaa yhtäkkiä valumaan vähintään kvartaaleittain ja kaiken testaamisen tapahduttava muutamassa viikossa, ollaan tilanteessa, jossa aiemmat käytännöt ja resurssit eivät enää riitä. Haastetta lisää kun järjestelmien liiketoimintaprosessit riittävän tarkasti tuntevia henkilöitä on yleensä vain kourallinen, koostuen suureksi osaksi liiketoiminnan asiantuntijoista. He toki tuntevat testattavat prosessit, mutta pitkässä juoksussa heitä ei voi kuormittaa testaamisella määräänsä enempää ilman negatiivista vaikutusta muuhun tuottavuuteen.

Kuvattujen haasteiden ja kasvavan testauskuorman kanssa päädytään nopeasti lopputulemaan, että testaukseen tarvitaan apua ja ison testaajajoukon sijasta järkevämmäksi lähestymistavaksi nähdään testiautomaatio.

Testiautomaatiotarpeen tiedostamisesta on usein pitkä matka tilanteeseen, jossa automaatio hoitaa mitään kokonaista osaa testaustarpeista. Yksi selkeä pullonkaula on tarvittavien resurssien kartoittaminen ja hankkiminen. Jos testauskokonaisuutta ja tarvittavan testauksen määrää oli aiemmin vaikea hahmottaa ilman suunnitelmallista työskentelyä aiheen parissa, niin vielä vaikeampaa on hahmottaa kaikkia testiautomaation vaatimuksia. Yhtäkkiä olisi saatava vastauksia siihen, millaisia kyvykkyyksiä tarvitaan, kuinka paljon niitä tarvitaan, kuinka kauan niitä tarvitaan, mistä niitä saadaan ja paljonko ne maksavat?

Tyypillisesti automaation käyttöönottoprojekti sisältää jonkinlaisen suunnittelu- ja valmisteluprosessin, jonka laajuus on usein suoraan verrannollinen yrityksen lähtötilanteeseen testauksen suhteen. Lopputuotoksena on vähintään testaussuunnitelma, riittävän yksityiskohtaisesti määritellyt käyttötapaukset, sekä tekninen analyysi testattavista prosesseista ja niiden soveltuvuudesta automatisoitavaksi. Lisäksi tarvitaan testiympäristöt, -käyttäjät ja -data. Lopuksi päätetään, miten asiat priorisoidaan, monitoroidaan, raportoidaan ja reagoidaan,sekä missä tätä kaikkea hallinnoidaan. Iso kasa erilaisia asioita osattavaksi useammallekin ihmiselle jaettuna.

Kun päästään teknisiin suoritteisiin, erilaisten kyvykkyyksien tarve kasvaa. Projektin tekninen toteutus vaatii infraosaajia, ohjelmistokehittäjiä ja testiautomaatioasiantuntijoita. Vaihtoehtoisesti voidaan valita jokin kaupallinen tuote, jolla osa haasteista saadaan valmiiksi taklatuksi.

Usein kaiken tarvittavan osaamisen määrä on niin vaikea hahmottaa etukäteen, että hankinta-, tai rekrytointipäätöksen jälkeen lähdetään etsimään sekalaista määrää konsultteja/henkilöitä ilman tietoa todellisesta osaamistarpeesta. Rekrytointiprosessit ovat tällöin usein tarpeettoman raskaita, vievät aikaa ja testiautomaation eteneminen käyttöönottopäätöksestä käynnistysvaiheeseen voi olla vielä useiden kuukausien – ja useiden testaussyklien – päässä.

Testing as a Service

Kuvitellaan jos esimerkiksi rakentamisen suhteen mentäisiin aiemman tyyppiseen hankintamalliin. Sivuutetaan vakiintuneet toimintamallit ja lasketaan itse tarvittavat resurssit seuraavalle kolmelle vuodelle tavoitteena saada toimitilat saneerattua. Suunnitellaan onnistuneesti kaikki tarpeet ja hankitaan ne onnistuneesti. Niinpä. Vaikeaa on jaa varmaan myös melko hidasta, kallista ja riskialtista.

Mitä jos käännetään asetelma toisin päin, entä jos testausta- ja testiautomaatioprojekteja voisi tilata ja toimittaa kuten putkiremonttia? Tai jos pilkotaan asiaa vielä pienempiin osiin. Miksi ostaa kerralla kokonainen projekti, jos ensi alkuun tarvitaan vain pienempi yksittäinen palikka, joka edistää asiaa hallitusti määränsä verran kerrallaan.

Tilaaja ostaa palveluna ja toimittaja huolehtii, että tilaajalla on aina projektin kulloisessakin työvaiheessa sillä hetkellä tarvittava ydinosaaminen käytössään. Työtä ja kustannuksia voidaan rytmittää ketterästi tilaajalle sopivimmalla aikataululla ja kapasiteetilla. Joissain tilanteissa palvelu voi olla muutama jatkuvasti projektissa tarvittava henkilö ja tarpeen tullen määrää voidaan skaalata tilanteeseen sopivaksi. Toisessa tapauksessa se voi olla yksi yleinen henkilöresurssi mallilla, jossa työpanoksen antaa tänään testimanageri, huomenna cloud-asiantuntija ja ensi viikolla testiautomaatiokehittäjä. Kolmannessa tapauksessa voidaan esimerkiksi sopia määrämittainen 2vko-1kk mittainen sprintti, jossa toimittaja toimittaa yhdessä määritellyn työmääräarvioon perustuvan työsuoritteen ja vastaa sen toteutumisesta (=remontti). Palvelu skaalaa kaikissa tapauksissa ylös ja alas. Tarpeen ja tilanteen mukaan.

Goforelta saat testiautomaatiota ketterästi palveluna

Nopeus ja ketteryys on suoraan toimintamallissa. Se ei sido tilaajaansa mihinkään muuhun kuin yhteen kioskiostokseen, joka voi olla vaikkapa tietty koulutus tai yhden käyttötapauksen automatisointi. Laskutus juoksee ainoastaan silloin kun tekeminen on käynnissä ja toimittaja varmistaa, että oikeanlainen osaaja varmistaa sovitun lopputuloksen. Yhden henkilön sijaan toteutuksen takana on aina isompi tiimi, josta löytyy kaikki tarpeellinen osaaminen mihin tahansa kohtaan projektin aikana.

Kasvata ohjelmistokehityksesi tuottavuutta — testiautomaation avulla. Haluatko tietää lisää testiautomaatiosta ja sen mahdollisuuksista? Lue lisää. 

Mika Lindh

Mika Lindh

Mika works as the Service Manager at Gofore Test Automation Hub. He is passionate about RPA and test automation. Mika has worked long as a Test Automation developer, consultant and he has long experience with ERP-systems.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.