Tilinpäätöksemme vuodelle 2014 on valmistunut. Liikevaihtomme oli 9,2 M€ ja liikevoittomme 1,4 M€ (14,9 % liikevaihdosta). Liikevaihtomme kasvoi vuodesta 2013 peräti 54 % ja liikevoittomme samaa tahtia 56 %. Henkilökunnan määrä kasvoi niin ikään yli 50 % liki sataan työntekijään.
Kannattava kasvu toteutui nyt kymmenentenä peräkkäisenä tilikautena. Viimeisten viiden tilikauden keskimääräinen kasvu on ollut 47 % ja liikevoitto 14 %.
Kasvu on syntynyt seurauksena jokaisen goforelaisen innokkuudesta työhömme. Goforessa koemme olevamme pelastamassa Suomea – digitalisaatio muuttaa maailmaa ja liiketoiminnan arvoketjuja kiihtyvällä tahdilla. Me olemme kehityksessä mukana, auttamassa suomalaisia yrityksiä ja organisaatioita tuottamaan state-of-the-art -ratkaisuja ja uusia digitaalisia palveluinnovaatioita.
Jo aiempina vuosina olemme saavuttaneet merkittävän aseman ketterän vaiheittaisen kehittämisen ja sen johtamisprosessin asiantuntijoina. Olemme avoimen, asiakaslähtöisen ja organisaatiorajat rikkovan yhteistyön tunnustettuja osaajia. Viime vuoden aikana kehityimme erityisesti palvelumuotoilun ja käyttäjäkokemuspalveluiden (UX) sekä tiedolla johtamisen palveluiden tarjonnassa.
Osallistuimme viime vuonna ensimmäistä kertaa Great Place to Work -tutkimukseen. Kaikista yleisen sarjan 90 osallistujista Gofore Oy valittiin kolmanneksi parhaaksi työpaikaksi. Ensikertalaiselle tämä tulos oli aivan poikkeuksellisen hyvä. Haluamme olla jatkossakin eturintamassa muuttamassa työelämää ja siten yleistä elämänlaatua parhaaksi mahdolliseksi. Uskomme, että myös asiakaskokemus rakentuu vahvan organisaatiokulttuurin ja henkilöstöviihtyvyyden varaan, ja täten myös asiakaskuntamme hyötyy tästä kehityksestä.
Tänä vuonna tavoittelemme yli 13 miljoonan euron liikevaihtoa. Henkilökuntamme määrän oletamme kasvavan noin 140 henkilöön vuoden loppuun mennessä.


Gofore Oy on tietoyhteiskunnan sähköisten palvelujen arkkitehtuuri- ja rakennustoimisto. Autamme asiakkaitamme kehittämään tietojärjestelmiään palvelulähtöisesti ja ketterästi pala palalta, arkkitehtuurilla ohjaten. Asiakkaitamme ovat esimerkiksi sosiaali- ja terveysministeriö, Opetushallitus, Liikennevirasto ja Fonecta. Toiminnallemme on ominaista huippuasiantuntemus, ripeys, aito vuorovaikutus sekä jatkuva, kannattava kasvu. Goforelaisia on Helsingissä ja Tampereella yhteensä 105 ja tavoittelemme tänä vuonna yli 13 miljoonan euron liikevaihtoa. Yritys on perustettu vuonna 2001. www.gofore.com

Avatar

Timur Kärki

Timur on Gofore Oy:n toimitusjohtaja ja yksi perustajaosakkaista. Hänellä on yli viidentoista vuoden kokemus haasteellisista tietojärjestelmien kehittämishankkeista. Erityisen kiinnostunut Timur on Suomen pelastamisesta onnistuneilla ja innovatiivisilla sähköisillä palveluilla yhdessä Goforen asiakkaiden ja työntekijöiden kanssa. Timur itse konsultoi asiakkaita liittyen kokonaisarkkitehtuurityöhön, vaatimusmäärittelyihin sekä kilpailutusprosesseihin.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

On tultu pitkälle siitä kun Suomen syrjäinen sijainti, pieni koko, vähän puhuttu kieli ja monopolit suojasivat suomalaisia yrityksiä kansainväliseltä kilpailulta. Eikä siitä ole kauaa kun suosikkisarjan seuraava jakso tuotiin fyysisen nauhan muodossa lentokoneella maahan ja lauantaisauna piti ajoittaa lempparisarjan ehdoilla. Meille kaikille tärkeistä asioista uutisoitiin kaksi kertaa päivässä, aamulla sanomalehden ja illalla puoli yhdeksän uutisten muodossa. Pizzerian puhelinnumeroa puolestaan etsittiin keltaisilta sivuilta, ja löydettiinkin mikäli kerran vuodessa päivittynyt opus oli ajan tasalla. 2000-luvulla muutos kohti digitaalista yhteiskuntaa on ollut räjähdysmäinen ja vauhti sen kun kiihtyy kohti 2020-lukua mentäessä.
Globalisaation ja Internetin kehittymisen myötä kilpailu ihmisten vapaa-ajan käytöstä on tullut äärimmäisen kovaksi kansainvälisten digitaalisten palveluiden tunkeuduttua myös tänne pohjolan perukoille. Nykyään kuluttajat voivat halutessaan viettää aikaa amerikkalaisten sosiaalisen median palveluiden äärellä. Salkkareiden sijaan he voivat valita helposti Netflixistä suosikkisarjan silloin kun se itselle parhaiten sopii tai lukea talousuutisensa suoraan Financial Timesin verkkopalvelusta. Pitääkö meidän siis nostaa kädet pystyyn ja tyytyä kohtaloomme? Ehdottomasti ei. Parhaat selviytyvät ja kääntävät digitalisoitumisen mahdollisuudeksi luoda täysin uusia palvelukonsepteja ja haastaa globaalit pelurit.
Me Goforessa olemme onnekkaita saadessamme palvella suomalaisia digitalisoinnin edelläkävijäyrityksiä. Esimerkiksi Fonectaa olemme auttaneet vuodesta 2010 alkaen koko palveluportfolion digitalisoinnissa. Tämän lisäksi olemme rakentaneet Fonectan kanssa täysin uusia palveluinnovaatioita joiden käyttökokemus yhdistettynä paikallistuntemukseen kestää vertailun esimerkiksi Googlen vastaaviin palveluihin. Fonectan Lauri Halkosaari kertoo Goforen Asiakkaat -sivulla lisää tästä digitalisoitumisen menestystarinasta.
Alma Media Oyj puolestaan oli ajautunut haastavaan tilanteeseen perinteisen printtimedian suosion hiivuttua. Merkittävät satsaukset digitaalisiin palveluihin ovat kuitenkin alkaneet kantaa hedelmää ja jopa avanneet uusia mahdollisuuksia bisneksen voimakkaaseen kasvattamiseen tulevaisuudessa. Olemme saaneet seurata läheltä Alma Median muutosta digitaaliseksi mediataloksi. Esimerkiksi Kauppalehti.fi-palvelun kehityskäytännöt ovat maailmanluokkaa, ja olemme ylpeitä saadessamme olla mukana luomassa kehittämisen kulttuuria. Kauppalehden palvelukehitystä kannattaa muuten seurata Alma developers-blogista.
Näitä edellä mainittuja yrityksiä yhdistää rohkeus kokeilla, oppia ja parantaa koko ajan olemassa olevaa tähdätessään parhaaseen mahdolliseen kuluttajalle muodostuvaan käyttäjäkokemukseen (UX). Ei ole varmasti liioittelua todeta, että ilman laadukasta käyttäjäkokemusta sinulla ei ole mitään. UX-palveluidemme vetäjä Arto Puikkonen kertoo tästä omassa blogissaan.
Kilpailussa pärjää ainoastaan koko ajan kehittymällä. Jatkuvan kehittämisen kulttuuri ei synny itsestään vaan se vaatii osaamista, systemaattista otetta, tinkimätöntä asennetta ja aitoa intohimoa tehdä asioita paremmin. Digitaalisten palvelujen kehittämisen yhteydessä puhutaankin monesti DevOps-kulttuurista, jonka rakentamisesta Tapio Rautonen kertoo oivallisesti blogissaan. Ville Seppänen puolestaan valottaa, miten DevOps näkyy käytännössä digitaalisen palvelutuotteen kehittämisestä. Jari Pääkkö taas tuntee parhaan mahdollisen DevOps-työkalupakin kuin omat taskunsa.
Tulemme mielellämme kertomaan tarinamme ja auttamaan sinun menestystarinasi alkuun.

Avatar

Juha Virtanen

Juhan vastuulla on Goforen myynnin ja asiakkuuksien johtaminen. Erityisesti Juhan sydäntä lähellä on maailman muuttaminen paremmaksi uusien digitaalisten innovaatioiden ja toimintatapojen kautta. Tällä hetkellä Juhan tärkeimpänä tehtävänä on kehittää Goforesta Suomen parasta asiakasarvoa tuottava digitalisoinnin kumppani.

Piditkö lukemastasi? Jaa se myös muille.

Etujärjestömme ottivat voimakkaan kannan valmisteilla oleviin Julkisen hallinnon IT-hankintojen sopimusehtoihin (JIT) Helsingin Sanomien mielipidekirjoituksessa, It-alan kilpailukyky pitää varmistaa vastedeskin, 10.3.2015.
Olen eri mieltä.
Valmisteilla olevan JIT:n mukaan tilaajan hankkiessa räätälöityä ohjelmistokehitystä, tilaajalle jää jatkokehitysoikeus tehtyyn ratkaisuun. Immateriaalioikeudet säilyvät kuitenkin myös toimittajalla. Tämä on viime vuosina ollut yleinen käytäntö, ja on erittäin hyvä, että käytäntö siirtyy myös yleisiin ehtoihin. Huomionarvoista on, että tällä ei ole mitään vaikutusta valmisohjelmistojen tai niihin liittyvien räätälöintien, eikä liioin pilvipalveluna toimitettavien ratkaisujen hankintaan.
Ymmärrän kyllä pointin siitä, että Suomi voisi tukea ohjelmistoyrityksiä siten, että julkisin varoin jokin yhtiö kehittäisi räätälöitynä ohjelmistoratkaisua, jota sitten tuotteistettaisiin samalla ja mahdollisesti jossain välissä ratkaisusta muodostuisi vientituote. Pitkälti näin on aikaisemmin toimittu (CGI, Tieto), mutta nyt trendi on aivan toinen – ja hyvä niin. Vendor lock-in -tilanteet ja suurten toimijoiden yksipuolisten sopimusten turvin ylläpitämä valta-asema ovat hidastaneet Suomen digitalisoitumista merkittävästi viimeisten 15 vuoden aikana. Tämä on ollut selvästi haitallisempaa, kuin räätälöidysti tuotetun lähdekoodin luovuttaminen tilaajan jatkokehitystä varten voi mitenkään olla.
En siis usko väitteeseen, että uudet ehdot (ja vallitseva käytäntö ainakin valtionhallinnon järjestelmäkehityksessä) estäisivät uuden liiketoiminnan syntymistä pk-ohjelmistoyrityksille. Asia on nimenomaan päinvastoin. Avoimuuden lisäännyttyä 2000-luvun kuluessa markkinoille on päässyt lisäksemme useita muita hyviä ohjelmistoyrityksiä, jotka kasvavat ja kehittyvät tällä hetkellä voimakkaasti.
Lähdekoodin, tiedon ja rajapintojen avoimuus sekä lainsäädännön kehittäminen poikkihallinnollisten sähköisten palveluiden mahdollistamiseksi – siinä lääkkeitä Suomen pelastumiseen digitalisaation keinoin. Avoimuuden lisääntyessä pelikenttä aukeaa uusille yrityksille ja teknologia- ja palveluinnovaatioille.  Odotan näkeväni tulevaisuudessa monia uudentyyppisiä palveluita, joita yksityiset yritykset tuottavat linkittyen julkisiin rajapintoihin ja -tietoon.
JIT:n linjaus siitä, että kun räätälöityä ohjelmistokehitystä tilataan tilaajakin saa tuotokseen oikeuksia, on nähdäkseni tervetullutta. Uskon tosissani, että tämä on myös ohjelmistoyrittäjien ja teknologiateollisuuden etu loppujen lopuksi.
 
 

Avatar

Timur Kärki

Timur on Gofore Oy:n toimitusjohtaja ja yksi perustajaosakkaista. Hänellä on yli viidentoista vuoden kokemus haasteellisista tietojärjestelmien kehittämishankkeista. Erityisen kiinnostunut Timur on Suomen pelastamisesta onnistuneilla ja innovatiivisilla sähköisillä palveluilla yhdessä Goforen asiakkaiden ja työntekijöiden kanssa. Timur itse konsultoi asiakkaita liittyen kokonaisarkkitehtuurityöhön, vaatimusmäärittelyihin sekä kilpailutusprosesseihin.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

DevOps – hitaista päivityssykleistä jatkuvaan parantamisen tielle

Fonecta.fi on suomen suosituin hakupalvelu ja valtakunnan suosituin verkkosivusto heti uutissivustojen jälkeen. Suosituimmuus syntyy Fonectan kyvystä kehittää palvelua erittäin nopeasti.
Ennen vuotta 2010 yrityksen kehitystavat olivat jäykkiä. Palvelimet pyörivät omassa konesalissa, muutostiketit viuhuivat ristiin rastiin, vanhan koodin painolasti kankeutti kehityksen ja työntekijät olivat tuskastuneita hitaisiin, neljännesvuosittaisiin päivityssykleihin.
Vuosien 2012 – 2014 välillä yritys on kehittänyt yhteensä 35 sovellusta tai palvelua. Uudet palvelunsa Fonecta on kehittänyt DevOps-ideologiaa käyttäen.
Kuinka Fonecta sai elefanttinsa tanssimaan? Fonectan IT-päällikkö Lauri Halkosaari kertoo.

Aloita puhtaalta pöydältä pienesti

Fonecta aloitti uusien työtapojen käyttöönoton pienellä projektilla. Vuonna 2010 yritys kehitti Osuma.fi -palvelua, joka sopi hyvin testausalustaksi. 
“Teimme ensin yhden palvelun, jolla näytimme mitä voimme saada aikaiseksi.“

“Meillä Fonectalla on vastuu tiimin toiminnasta ja tekemisen esteettömyydestä. Alihankkijoiden vastuulla on hankkia parhaat tekijät” - Lauri Halkosaari
“Kun jengi on hyvää ja kehittämisen esteet on raivattu pois, niin tekijöitä ei tarvita niin paljon.” – Lauri Halkosaari

Aiemman kehityksen hitauteen tuskastunut kehitysporukka oli muutokseen otollista maaperää. Työntekijät enemmänkin odottivat uusien tapojen käyttöönottoa kuin jarruttivat sitä. Kokeilun laajentaminen oli seuraava vaihe.
”Muulle organisaatiolle tarvitsimme perusteluita hieman enemmän. Osuma.fi:ssä pystyimme tiputtamaan kehitystyön kustannukset puoleen, viemään uusia versioita tuotantoon katkottomasti ja huoltokatkot mukaan lukien palveluiden saatavuudet olivat paremmat kuin ennen. Kun ensimmäisen kerran todistimme toimivuuden, niin sen jälkeen myyntityötä ei ole tarvinnut tehdä.”

Vaihda konesalit pilveen

Fonectan joustavuuden pohjana on irtautuminen raskaasta omien palvelimien hallinnoinnista. Vanhassa maailmassa palvelinmuutokset vaativat tiketin luontia ylläpidolle, jolloin muutokset olivat hitaita.
“Muutos on meillä jatkuvaa. Silloin on tärkeää pystyä muokkaamaan palveluiden infraa nopeasti.”
Pilvessä uuden palvelimen käyttöönotto on muutaman napin takana ja kehittäjä voi tehdä sen itse.
“Meillä ei ole enää 50 palvelinta konesalissa, että tässä on meidän infra. Me voimme pelkillä koodimuutoksilla heittää palvelimia pois tai ottaa niitä käyttöön”.

Rakenna kykenevä tiimi

Fonecta rakensi kehitystä varten oman tiimin. Se on suhteellisen iso moniosaajatiimi, johon kuuluu yli 20 henkeä. Toisaalta väkeä on melko vähän kun ottaa huomioon palveluiden lukumäärän ja käyttäjämäärät (Gofore on osa Fonecta-tiimiä, lue lisää täältä). 
“Kun jengi on hyvää ja kehittämisen esteet on raivattu pois, niin tekijöitä ei tarvita niin paljon.”
Tiimi pystyy toimimaan itsenäisesti mahdollisimman pitkälle. Tiimiin kuuluu osaamista markkinoinnista, analytiikasta, sovelluskehityksestä ja ylläpidosta. Sama tiimi tuottaa suurimman osan yrityksen kaikista palveluista.
“Meillä on yksi Fonecta-tiimi, jossa on parhaat tekijät. Meillä itsellä on osaamista sovelluskehityksestä, tuotekehityksestä ja projektijohdosta. Tekijöiksi olemme hankkineet sellaisia osaavia tyyppejä, jotka saavat paljon aikaan.”
Kehittäjät Fonecta on hankkinut alihankkijoilta. Halkosaari näkee, että useita alihankkijoita käyttämällä pystyy keräämään useiden eri yritysten parhaita toimintatapoja yhteen nippuun.

Automatisoi kaikki mahdollinen

Fonectan kehityskulttuurin ydin on kaiken mahdollisen automatisoinnissa.
“Lähdimme tekemään asioita tavalla, joka on kehittäjätaustaisille ihmisille järkevää. Heitimme turhat mallit pois ja mietimme miten ongelmat kannattaa oikeasti ratkaista.”
Ratkaisu on automatisoida kaikki mahdollinen eli tuotantoonviennit ja muut ylläpidolliset toimet, kuten palvelinten käyttöönotot ja alasajot. Automatisointi tarkoittaa sopivien työkalujen käyttämistä ja toimenpiteiden ilmaisemista koodilla.

Avatar

Tapio Rautonen

Tapio Rautonen <a href="https://twitter.com/trautonen">@trautonen</a> is software architect at Gofore and his job is to help businesses to win. He has years of experience building software for different cloud platforms with various technologies and programming languages. Tapio is regular guest lecturer at Tampere University of Technology teaching courses like Service-oriented systems and Software Architectures. He spends his limited spare time contributing to the open source software community and experimenting with new technologies and tools.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

DevOps on ideologia, jonka tavoitteisiin kuuluu ohjelmistotoimitusketjun nopeuttaminen ja automatisointi koodista julkaisuun. Tärkeä osa tämän tavoitteen saavuttamista on viestinnän ja yhteistyön parantaminen ennen kaikkea ohjelmistokehittäjien ja tuotantojärjestelmiä ylläpitävien järjestelmäasiantuntijoiden välillä.
Sekä viestinnän ja yhteistyön tukemiseksi että ohjelmistotoimitusketjun nopeuttamiseksi ja automatisoimiseksi on olemassa joukko erilaisia työkaluja. Joskus näistä työkaluista voi myös kuulla puhuttavan DevOps-työkaluina. On kuitenkin tärkeää huomioida, ettei DevOps edellytä työkalujen käyttöä, eikä työkalujen käyttö automaattisesti tarkoita, että toimintamalli olisi DevOps-ideologian mukainen. Monia DevOpsiin usein liitettyjä työkaluja on itse asiassa käytetty jo ennen kuin termiä ”DevOps” alettiin käyttämään. Millä tavoin nämä työkalut voivat sitten tukea DevOps-käytäntöjä ja -periaatteita?

Jatkuva julkaisu

Jatkuva julkaisu käsittää työkalut, joita käytetään koodin integroimiseksi, paketoimiseksi ja julkaisemiseksi. Toisin sanoen näillä työkaluilla voidaan automaattisesti suorittaa testejä, paketoida ja koota koodit toimituskelpoiseen muotoon sekä automatisoida asennukset palvelimille. Kun jatkuva julkaisu suoritetaan useita kertoja päivässä, saadaan myös palautetta kerättyä nopeammin ja siten voidaan reagoida ongelmiin ja muutoksiin aikaisemmin. Kun jatkuvasta julkaisusta saatu tieto on lisäksi kaikkien saatavilla, auttaa se parantamaan viestintää ja yhteistyötä eri osapuolten välillä.
Esimerkkityökaluja: Jenkins, Bamboo, Travis, Shippable

Virtualisointi ja kontit

Virtualisoinnilla voidaan tarkoittaa monia asioita, mutta DevOpsissa sillä tyypillisesti tarkoitetaan laitteiston virtualisointia, jolloin yhden fyysisen tietokoneen tai palvelimen päällä voidaan ajaa yhtä tai useampaa virtuaalikonetta. Vastaavasti myös useat fyysiset palvelimet voidaan esittää yhtenä virtuaalikoneena. Virtuaalikoneiden ongelma on, että ne vaativat sovelluksen ja sen riippuvuuksien lisäksi myös vieraskäyttöjärjestelmän, jolloin virtuaalikoneiden koko kasvaa usein isoksi. Tämän vuoksi on kehitetty kevyempiä virtualisointimuotoja kuten nk. kontit (engl. containers). Kontteja ajetaan tyypillisesti eristetyssä prosessissa isäntäkoneen käyttöjärjestelmässä. Näin ollen kontit sisältävät ainoastaan sovelluksen ja sen riippuvuudet, eivätkä ne tarvitse omaa vieraskäyttöjärjestelmää. Tämä tekee konteista helpommin siirrettäviä ja tehokkaampia, jolloin useita kontteja voidaan tarvittaessa ajaa yhdellä virtuaalipalvelimella. Sekä virtuaalikoneet että kontit edesauttavat ohjelmistokehittäjien ja järjestelmäasiantuntijoiden välistä yhteistyötä, kun kehitys- ja tuotantoympäristöt voidaan yhdenmukaistaa.
Esimerkkityökaluja: VirtualBox, Vagrant, Docker, Rocket

Pilvipalvelut

Pilvipalvelut perustuvat virtualisointiin, jolloin pilvipalveluntarjoajien työkaluilla monimutkaistenkin palvelinympäristöjen pystyttäminen onnistuu helposti ja nopeasti. Virtualisointi mahdollistaa myös pilvipalveluiden skaalauksen käytön mukaan. Pilvipalveluiden käyttäminen hälventää rajoja ohjelmistokehittäjien ja järjestelmäasiantuntijoiden välillä ja ketteröittää työskentelytapoja, kun palvelinympäristöön tehtävät muutokset voidaan tehdä helposti ja läpinäkyvästi. Automatisoinnin ja parempien työkalujen ansiosta ohjelmistokehittäjä voi myös ottaa aiempaa suuremman roolin infrastruktuurin hallinnassa.
Esimerkkejä pilvipalveluista: Amazon Web Services, Rackspace, Heroku

Konfiguraationhallinta ja provisiointi

Konfiguraationhallinnalla pyritään seuraamaan ja hallitsemaan muutoksia ohjelmistoihin ja laajemmin myös alla olevaan infrastruktuuriin. Provisioinnilla puolestaan tarkoitetaan tarvittavien käyttöjärjestelmien, ohjelmistojen, datan ja muiden riippuvuuksien asentamista ja konfiguroimista palvelimelle. Konfiguraationhallinta ja provisiointi liittyvät siten vahvasti toisiinsa. DevOpsissa nämä vaiheet pyritään automatisoimaan työkalujen avulla. Tällöin työkalujen avulla kuvataan tila, johon palvelin halutaan saattaa, jolloin työkalut hoitavat asennukset ja konfiguroinnit automaattisesti sekä tarkkailevat muutoksia infrastruktuurissa. Infrastruktuurin voi tällöin ilmaista ohjelmoitavana koodina, jolloin infrastruktuurin hallinnassa voidaan hyödyntää ohjelmistokehityksessä käytettyjä työkaluja ja käytäntöjä. Ohjelmistokehittäjät voivat puolestaan käyttää konfiguraationhallinta- ja provisiointityökaluja luodakseen tuotantoympäristöä vastaavan kehitysympäristön automaattisesti. Ympäristöjen yhtenäistäminen poistaa ”toimii minun koneella”-tyyppiset ongelmat ja vähentää näin ristiriitoja eri osapuolten välillä.
Esimerkkityökaluja: Ansible, Puppet, Chef

Konttien orkestrointi

Isot tietojärjestelmät hajautetaan tyypillisesti useille virtuaalipalvelimille sekä näiden päällä ajettaville konteille. Tällöin tarvitaan tehokkaat työkalut konttien orkestrointiin. Orkestrointi tarkoittaa konttien automaattista sijoittelua eri virtuaalipalvelimille sekä konttien välisen viestinnän hallintaa. Käytännössä työkaluilla voidaan määrittää millä palvelimilla kukin kontti ajetaan ja minkä muiden konttien kanssa kukin kontti kommunikoi. Osa työkaluista mahdollistaa myös konttien automaattisen kuormantasauksen ja virheidenhallinnan. Esimerkiksi vioittuneen kontin tilalle voidaan automaattisesti käynnistää vastaava toimiva kontti. Myös pilvipalveluissa on tarjolla työkaluja konttien helppoon asennukseen virtuaalipalvelimille sekä isojen konttijoukkojen hallintaan. Tällaiset orkestrointityökalut tukevat ja nopeuttavat tietojärjestelmän asennusta ja muutosten tekemistä tuotantoympäristöön, jolloin myös ohjelmistokehittäjät voivat helpommin osallistua tietojärjestelmän hallintaan.
Esimerkkityökaluja: Ansible, Docker Compose, Docker Swarm, Kubernetes

Lokitus, seuranta ja metriikoiden visuaalisaatio

Tärkeä osa DevOps-ideologiaa on palautteen kerääminen ja jakaminen jatkuvan parantamisen hengessä. Varsinkin hajautetussa järjestelmässä lokien kerääminen ja tuotantoympäristön reaaliaikainen seuranta voivat olla haasteellisia. Näiden tukemiseksi on kuitenkin olemassa työkaluja, joilla muun muassa lokien kerääminen, kokoaminen, hakuindeksointi ja visualisointi voidaan suorittaa automaattisesti ja reaaliaikaisesti. Kaikille läpinäkyvät metriikat ja kaaviot tukevat DevOps-periaatteita ja päivittäistä päätöksentekoa. Tämä antaa ohjelmistokehittäjille mahdollisuuden tutkia ongelmia reaaliajassa. Kun ohjelmistokehittäjät voivat suoraan seurata tekemiensä muutosten vaikutusta tuotantoympäristössä, kasvattaa se myös heidän sitoutumistaan ja omistautumistaan tietojärjestelmää kohtaan.
Esimerkkityökaluja: Elasticsearch, Logstash, Kibana, Sensu, New Relic, AppDynamics, Splunk
Vaikka yllä esitetyt työkalut tukevatkin DevOps-käytäntöjä ja -periaatteita on edelleen tärkeää muistaa, etteivät työkalut itsessään takaa DevOps-tavoitteiden saavuttamista. Loppujen lopuksi DevOps edellyttää ihmisten välistä yhteistyötä, avoimuutta ja viestintää.

Avatar

Jari Pääkkö

Jari on ohjelmistosuunnittelija, jolla on kokemusta sekä verkkopalveluiden että mobiilisovellusten suunnittelusta ja toteutuksesta. Hän tutustuu mielellään uusiin teknologioihin ja työkaluihin, jonka lisäksi hänellä on vahva kiinnostus ohjelmistotuotannon eri osa-alueisiin ketteristä menetelmistä ohjelmistoarkkitehtuurisuunnitteluun.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

DevOps-kulttuuria rakentamassa

Yrityskulttuurista ohjelmistokehityskulttuuriin

Yrityskulttuurista on puhuttu Goforella viimeisen vuoden aikana paljon, sillä päätimme osallistua Suomen parhaat yritykset -tutkimukseen ensimmäistä kertaa. Tutkimus huipentui loppugaalaan 5.2.2015, jossa Gofore valittiin Suomen 3. parhaaksi yritykseksi yleisessä sarjassa. Prosessin aikana Goforen yrityskulttuuria on tarkasteltu monesta suunnasta ja kulttuuriin liittyvistä asioista on keskusteltu paljon ja avoimesti. Yrityksen tai organisaation liiketoiminnan onnistumisen merkittävimpänä tekijänä on se, että työntekijät ovat innostuneita työstään ja voivat hyvin työpaikallaan. Jos nämä ehdot eivät täyty, on vaikea rakentaa menestyvää ja pitkäkestoista liiketoimintaa, jota ruokkii positiivinen yrityskulttuuri.
Ohjelmistokehitysprojektit tai tietojärjestelmähankkeet voisi ajatella erillisenä osana yrityksen liiketoimintaa, mutta totuus on, että se sama yrityskulttuuri joka ruokkii työtekijöiden hyvinvointia, toimii pohjana myös ohjelmistokehityskulttuurin syntymiselle. Voidaan miettiä, kuinka valtavasti laitoimme paukkuja oman yritysidentiteettimme etsimiseen ja työyhteisön hyvinvoinnin parantamiseen, mutta pitäisikö yhtä paljon miettiä, miten teemme ohjelmistoprojekteja, miten johdamme tietojärjestelmähankkeita ja miten onnistumme luomaan yhä kannattavampaa liiketoimintaa tai auttamaan asiakkaitamme kasvattamaan tuottavuutta tietojärjestelmien avulla? Väitän, että kyllä pitäisi.
Tietojärjestelmäkehitystä on perinteisesti lähestytty prosessien ja ohjelmistokehitysmenetelmien kautta. Ketterät ohjelmistokehitysmenetelmät, ITIL-käytännöt ja kokonaisarkkitehtuuritehtuurikehykset yrittävät ratkaista tietojärjestelmähankkeisiin liittyviä haasteita kukin omasta näkökulmastaan, mutta usein unohdetaan se tärkein asia – ihmiset. DevOps on termi, joka tarkoittaa jollekin ketterän ohjelmistokehityksen jälkeistä ohjelmistokehitysmenetelmää, toiselle se on joukko hyviä työkaluja tai käytäntöjä IT-projekteissa onnistumiseen, mutta ennen kaikkea DevOps syntyy kulttuurista, jonka keskiössä ovat ihmiset.

Kolme tietä näyttävät suunnan

DevOps-termin lanseerasi belgialainen Patrick Debois vuonna 2009. DevOpsin alkuperäinen tarkoitus oli saattaa ohjelmistokehittäjät (development) ja järjestelmäasiantuntijat (operations) tiiviimpään vuorovaikutukseen. Kirjat The DevOps Cookbook ja The Phoenix Project: The Book About IT, DevOps, and Helping Your Business Win antoivat DevOpsille filosofisemman kontekstin tiestä, joka ei johda koskaan täysin valmiiseen maailmaan. Kirjoissa viitataan kolmeen tiehen, jotka rakentavat DevOps-kulttuurin perustukset ja kuvaavat prosesseihin, menetelmiin ja käytäntöihin liittyviä arvoja ja filosofioita.

DevOps syntyy kulttuurista, jonka keskiössä ovat ihmiset.

Ensimmäinen tie, systeemiajattelu (systems thinking), korostaa koko systeemin suorituskyvyn ymmärtämistä yksittäisen liiketoiminnallisen siilon tai työtehtävän sijaan. Suorituskyky koostuu työstä, joka syntyy yleensä liiketoiminnallisista vaatimuksista ja päättyy vakaaseen, turvalliseen sekä luotettavaan julkaisuun asiakkaalle. Lean-käytännöt auttavat löytämään pullonkaulat arvovirroissa, vähentämään samanaikaisen käynnissä olevan työn määrää, pienetämään julkaistavan työn kokoa, parantamaan muutoksenhallintaa ja vähentämään hukkatyötä. Koko systeemin suorituskyky kärsii, jos tiedetyt ongelmat tai virheet siirtyvät arvovirrassa eteenpäin tai paikallinen yksittäisen työtehtävän optimointi vaikuttaa heikentävästi koko systeemin suorituskykyyn. Ensimmäisen tien saavuttamiseksi on saatava kattava ymmärrys ja arvostus systeemistä, joka tarkoittaa liiketoimintatavoitteiden, arvon tuottamisen, prosessien, teknologioiden, riskien ja ihmisten ymmärtämistä. Siis aitoa kiinnostusta ja välittämistä.
Toinen tie, vahvistuneet palautevirrat (amplified feedback loops), tarkoittavat palautevirroista syntyvien silmukoiden sulkemista ja lyhentämistä. Liiketoiminta, asiakkaat, järjestelmien valvonta ja testaus luovat syötteitä systeemiin, jotka prosessin mukaisen käsittelyn jälkeen tuottavat arvoa asiakkaalle. Jotta palautevirta muodostaisi silmukan, on asiakkaalta saatava palaute ohjattava takaisin systeemiin. Palautevirtoja voidaan vahvistaa kahdella tavalla: joko vähentämällä silmukassa olevien solmujen lukumäärää tai lyhentämällä kahden solmun välisen reitin kulkemiseen käytettyä aikaa. Palautevirtojen vahvistamisessa olennaisinta on etsiä silmukan suurimmat pullonkaulat ja poistaa ne ensimmäisenä. Toisen tien saavuttamiseksi on systeemin palautevirtojen silmukat suljettava ja määrätietoisesti pystyttävä poistamaan silmukoihin syntyviä pullonkauloja. Tämä ei ole mahdollista ilman hyvää ymmärrystä sisäisistä ja ulkoisista asiakkaista sekä työkaluja ja menetelmiä, jotka mahdollistavat palautteen keräämisen ja tehokkaan vuorovaikutuksen eri sidosryhmien välillä.
Kolmas tie, jatkuvan kokeilemisen ja oppimisen kulttuuri (culture of continual experimentation and learning), rohkaisee synnyttämään työympäristön, jossa uusien asioiden kokeileminen, hallittujen riskien ottaminen ja epäonnistuminen on sallittua ja jopa kannustettavaa. Uusien asioiden kokeileminen ja hallittujen riskien ottaminen on ainoa tapa ylläpitää jatkuvaa kehittymistä ja mahdollistaa siirtyminen innovaation raja-alueelle, mistä aiemmin vain pystyttiin uneksimaan. Epäonnistuminen on luonnollista, mutta kun se tehdään yhdessä ja ketään sormella osoittelematta siitä voidaan oppia. Ja kun onnistumisista palkitaan, takaa se positiivisen kierteen kehittymiselle ja uusille innovaatioille. Kolmannen tien sisäistäminen vaatii usein muutoksia organisaatiossa, työympäristössä ja tavoissa työskennellä. Jatkuvalle kehittämiselle täytyy löytyä aikaa päivittäisen työn ohella.

Irtiotto perinteistä

Organisaatio ei voi ottaa DevOpsia ulkopuolisen konsultin toimesta käyttöön. DevOps ei ole titteli, eikä tiimi organisaation sisällä. DevOps ei ole ohjelmistokehitysmenetelmä tai edes joukko työkaluja, jotka mahdollistavat jatkuvan ohjelmistojen julkaisun.

DevOps on kulttuuri, joka syntyy, kun kaikki kolme tietä on saavutettu ja yhteinen päämäärä näkyy kaikilla kristallinkirkkaana silmissä liiketoimintayksiköstä tai tittelistä riippumatta.

Matka kolmea tietä pitkin ei pääty koskaan ja organisaatiot kulkevat niitä omaa tahtiaan – jotkin kauempana horisontissa kuin toiset. DevOps näkyy IT-projekteissa paljon ennen kuin yhtään riviä koodia on kirjoitettu tai järjestelmän infrastruktuurin vaatimuksia on mietitty. Tärkeintä on saada liiketoiminnalliset siilot rikottua ja eri sidosryhmät tiiviiseen vuorovaikutukseen keskenään. Tämä voi käytännössä tarkoittaa organisaatiomuutoksia, esimerkiksi siten että siiloutuneet liiketoimintayksiköt rikotaan ja tuotekehityksen, käyttöpalveluiden, markkinoinnin ja analytiikan ihmiset yhdistetään yhdeksi liiketoimintayksiköksi ja laitetaan heidät ratkaisemaan yhdessä liiketoiminnan asettamia vaatimuksia. Liiketoiminnan on sitouduttava muutokseen, ja tuettava sitä.
Käyttöpalveluntoimittajan kanssa tehtävä sopimus ei voi enää olla sellainen, että ainoa vuorovaikutuskeino on päivitystehtävästä lähetettävä tieto tehtävienhallintajärjestelmään. Käyttöpalveluntoimittajalta täytyy saada sitoutuneet ihmiset mukaan tiimiin, jotka ymmärtävät yhdessä muiden kanssa asiakkaalle tuotettavat arvovirrat ja koko systeemin. Samat ihmiset pystyvät suunnittelemaan ja kehittämään automatisoidun julkaisujärjestelmän, joka mahdollistaa yhä nopeamman reagoinnin palautevirtoihin aina loppukäyttäjältä asti. Kun ongelmien syntyessä ei etsitä syitä heistä tai meistä, voidaan muodostaa kulttuuri jatkuvalle kokeilemiselle ja oppimisille. Näin rakentuu työympäristö, joka mahdollistaa uusien innovaatioiden syntymisen. Tämä ei koske vain käyttöpalveluita vaan mitä tahansa kolmansilta osapuolilta ostettavia palveluita. Palvelusopimusten on muututtava, ihmisten on sitouduttava työhönsä ja nähtävä arvo omalle työlleen. Muuten kolme tietä jäävät kauas horisonttiin.
Virtuaalinen infrastuktuuri ja Lean metodologioista lähtöisin oleva MVP (minimum viable product) -lähestymistapa mahdollistavat nopean reagoimisen liiketoimintaympäristön muutoksiin ja uusien ideoiden ja tuotteiden kokeilemisen. Uuden palvelun ympäristöjä ei voida odottaa kuukausikaupalla, vaan palvelu pitää saada välittömästi loppukäyttäjien kokeiltavaksi. Ympäristöistä laskutetaan käytön mukaan, ei 10-vuotisilla sopimuksilla. Vaatimusmäärittely ei saa kestää kuukausia. Muutamassa viikossa pitää pystyä tuottamaan prototyyppi, josta saadaan loppukäyttäjiltä palautetta ja analytiikkaa, joka voidaan ohjata takaisin syötteeksi jatkokehitykselle. Enää ei eletä suljetussa kansallisessa taloudessa, vaan kilpailu on globaalia. Jos me emme pysty tähän, muut kansainväliset organisaatiot kyllä pystyvät ja valtaavat meidän paikalliset markkinamme. Yritykset kuten Facebook, Netflix tai Spotify ovat pystyneet tähän, miksi pienet ja ketterät suomalaiset yritykset eivät pystyisi?
Elämme valtavan muutoksen aikaa. Palvelut digitalisoituvat ja yritykset etsivät kuumeisesti keinoja pysyä mukana tässä muutoksessa ja löytää keinoja rakentaa uusia innovaatioita ja liiketoimintaa. Yritysten brändin arvo ei enää määräydy fyysisten tuotteiden vaan niiden tuottamien digitaalisten palveluiden arvon mukaan. Amazon on maailman suurin virtuaalisen infrastruktuurin tarjoaja. Nike tuottaa lifestyle-palveluita ja hyvinvointiteknologiaa urheiluvarusteisiin. Tesco sulkee kivijalkamarketteja rahoittaakseen verkkokaupan kehittämistä. Nämä ovat esimerkkejä isoista organisaatioista, jotka ovat vastanneet digitalisoitumisen haasteisiin onnistuneesti. Gofore on valmis antamaan kaiken tukensa suomalaisille yrityksille, jotta meidät nähdään taas maailmalla teknologisina edelläkävijöinä ja pystymme vastaamaan globaalin digitaalisen liiketoiminnan haasteisiin.

Avatar

Tapio Rautonen

Tapio Rautonen <a href="https://twitter.com/trautonen">@trautonen</a> is software architect at Gofore and his job is to help businesses to win. He has years of experience building software for different cloud platforms with various technologies and programming languages. Tapio is regular guest lecturer at Tampere University of Technology teaching courses like Service-oriented systems and Software Architectures. He spends his limited spare time contributing to the open source software community and experimenting with new technologies and tools.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Vuonna 2007 Sosiaali- ja terveysministeriön (STM) työsuojeluhallinnossa oli tunnistettu tarve määritellä ja hankkia koko työsuojeluhallinnon käyttöön yhtenäinen valvontatietojärjestelmä. Tilannetta kartoitettiin esiselvityksessä, jonka loppuraportissa todettiin, että mm. työsuojeluhallinnon tuottamat tarkastuskertomukset olivat laadultaan hyvin kirjavia, tietoa tallennettiin päällekkäisiin järjestelmiin, työprosessit vaihtelivat alueittain ja valvonnan sisällössä oli suuria eroavaisuuksia. Tästä tarpeesta syntyi työsuojeluhallinnon valvontatietojärjestelmähanke Valtimo.
Valtimo-hanketta johdettiin STM:n työsuojeluosastolta ja tarkempi määritteleminen aloitettiin vuonna 2008. Tällöin toteutettavalle tietojärjestelmälle asetettiin viisi selkeää tavoitetta. Järjestelmän avulla haluttiin mm. tehostaa valvontaprosessia, parantaa työsuojelutarkastusten laatua ja ennen kaikkea yhtenäistää toiminta ja prosessit koko maassa. Koska kyseessä oli nelivuotinen hanke, hankkeen sisältö oli jaettu viiteen eri osakokonaisuuteen. Jokaiselle osakokonaisuudelle tehtiin omat vaatimukset, määrittelyt ja aikataulu.

Goforelle selkeä voitto

Valtimo-hankkeessa toteutetun tietojärjestelmän kilpailutus käytiin vuonna 2010 ja Gofore voitti sen ylivoimaisesti (93/100 pistettä). Eroa toiseksi tulleeseen oli yli 20 pistettä. Vaatimuksina järjestelmän toteutukselle olivat toimiva järjestelmä, joka mallinsi tarkastajan työnkulkua, SOA palveluarkkitehtuuri sekä ketterien menetelmien käyttö. Valituilla teknologioilla tuli myös olla pitkä elinkaari, eikä niihin saanut sisältyä raskaita ylläpitomaksuja. Koko toteutusprojektin kokoa mitattiin toimintopisteillä (function point), joihin myös tietojärjestelmän hinnoittelu perustui. Tietojärjestelmä Vera nimettiin suomalaisen työsuojelun pioneerin Vera Hjeltin mukaan.
Jokainen viidestä osakokonaisuudesta vedettiin läpi omana projektinaan. Asiakkaan tuottamat alkuperäiset määrittelyt käytiin toimittajan puolelta läpi ja niitä tarkennettiin yhdessä asiakkaan kanssa ennen toteutuksen aloittamista. Varsinainen Vera-tietojärjestelmän rakentaminen tehtiin scrum-menetelmää käyttäen kolmen viikon sprinteissä. Jokaisen sprintin tuotokset julkaistiin heti asiakkaan testattavaksi. Projektin päätyttyä asiakas hyväksyi toimituksen ja se päivitettiin tuotantoon. Hankkeen edetessä uuden projektin rinnalla tehtiin myös jo tuotannossa olevien ominaisuuksien ylläpitoa ja virheiden korjausta.

Vera-järjestelmän lähdekoodi visualisoituna. Oikealla käyttöliittymäkerros, keskellä välikerros ja vasemmalla palvelukerros.
Vera-järjestelmän lähdekoodi visualisoituna. Oikealla käyttöliittymäkerros, keskellä välikerros ja vasemmalla palvelukerros.

Miksi hanke onnistui?

1. Sitoutunut asiakas, tuoteomistajuus ja projektin hallinta toimivat
2. Ketterien menetelmien käyttö
3. Riittävä ymmärrys asiakkaan tarpeista ja toiveista
4. Halu auttaa asiakasta
Lista saattaa näyttää itsestään selvältä, mutta sen toteutuminen ei ole niin yksinkertaista. Jotta tietojärjestelmä voi onnistua, myös asiakkaan pitää olla sitoutunut järjestelmän tekemiseen. Sitä ei voi ulkoistaa täysin toimittajan tehtäväksi. Koko tietojärjestelmän toimituksen ajan tarvitaan asiakkaan panosta ja resursseja myös heidän puoleltaan. Tuoteomistajan ja projektinhallinnan pitää olla kiinnostuneita toimittajan projektin etenemisestä ja valmiita auttamaan avoimissa asioissa, joita väistämättä tulee esiin toteutuksen aikana. Myös toteutuksen aikainen testaaminen on äärimmäisen tärkeää.
Ketterien menetelmien käyttö on elinehto onnistuneessa tietojärjestelmäprojektissa. Järjestelmän rakennetaan pieni pala kerrallaan niin, että alusta asti on toimiva järjestelmä, jota pikku hiljaa laajennetaan. Näin tiedetään koko ajan, onko projekti menossa oikeaan suuntaan vai pitääkö tehdä muutoksia. Muutosten tekeminen ja virheiden löytäminen mahdollisimman aikaisin parantaa projektin tuottavuutta.
Esimerkkinä Valtimo-hankkeen asiakkaan sitoutumisesta on se, että jokaisen sprintin aikana järjestettiin asiakkaan ja toimittajan yhteistä käytettävyys- ja käyttäjäkokemustyötä, joissa järjestelmän uusia ominaisuuksia testattiin yhdessä. Tämä auttoi asiakasta ymmärtämään järjestelmää paremmin sekä toimittajaa saamaan palautetta uusista ominaisuuksista ja löytämään virheet aiemmin.
Yksi oleellinen osa haastavien ja monimutkaisten tietojärjestelmän rakentamista on se, että toimittaja ymmärtää asiakkaan tarpeet ja toimintamallit riittävän hyvin. Ne eivät yleensä selviä kaikki toimittajalle annetuista määrittelyistä, vaan toimittajalla pitää olla halua ja mielenkiintoa selvittää taustoja tarkemmin. Tämä on ehdoton edellytys oikeanlaisen tietojärjestelmän tekemiselle. Asiakasta voi joutua haastamaan miettimään omia prosessejaan uudelta kantilta, koska tietojärjestelmä todennäköisesti tuottaa erilaista tietoa, kuin mihin ennen on totuttu. Valtimo-hankkeessakin tuli vastaan tilanteita, joissa asiakas ei osannut riittävän tarkasti kertoa sitä, miten haluaa järjestelmän toimivan tietyssä tilanteessa. Parhaiten päästiin eteenpäin siten, että toimittaja ehdotti ratkaisua tilanteeseen. Oikeanlaista ehdotusta ei voi tehdä, jos ei ymmärrä asiakkaan tarpeita ja taustoja vaatimusten takana.

”Vera-tietojärjestelmä kestää vertailun minkä tahansa valvontatietojärjestelmän kanssa”

Valtimo on toistaiseksi Goforen historian pisin hanke ja se päättyi lokakuussa 2014. Hankkeen päätösseminaarissa helmikuussa 2015 tarkasteltiin hankkeen onnistumista hallinnollisesta ja tavallisen käyttäjän näkökulmasta. Tilaisuuden yksimielinen mielipide oli, että hanke oli onnistunut ja saavuttanut tavoitteensa. Samaan hengenvetoon todettiin myös, että vaikka Valtimo-hanke on päättynyt, Vera-järjestelmää pitää edelleen kehittää eteenpäin. Ja näin asia onkin. Vaikka Vera on siirtynyt ylläpitoon, uusia ominaisuuksia toteutetaan koko ajan ja parannetaan järjestelmän käytettävyyttä.
Päätösseminaarin esityksissä Gofore sai ansaittua huomiota:
”Vera-tietojärjestelmä kestää vertailun minkä tahansa valvontatietojärjestelmän kanssa” – STM:n osastopäällikkö Leo Suomaa
”Onnistunut toimittajan valinta (Gofore Oy)” – Ylitarkastaja Antti Ikonen, Etelä-Suomen aluehallintovirasto
”Goforelle ei yksinkertaisesti mikään näyttänyt olevan mahdotonta. Mahdottomien asioiden tekoon tosin meni hieman enemmän aikaa.” – Järjestelmäpäällikkö Seppo Hämäläinen, Etelä-Suomen aluehallintovirasto, STM
Asiakaspalaute lämmittää mieltä ja motivoi tekemään työtä hyvin myös jatkossa. Pitää kuitenkin muistaa, että onnistumista ei olisi ollut ilman erinomaista toimintaa myös asiakkaan puolelta.

Menestyksellinen yhteistyö saa jatkoa

Työ valvontatietojärjestelmän kanssa jatkuu edelleen vaikka hanke päättyikin. Paljon on vielä kehitettävää ja paranneltavaa. Lisätarpeita tulee esiin varmasti, kun Vera-järjestelmän tarjoamaa tietoa opitaan hyödyntämään kunnolla.
Blogin toinen osa tuo esiin konkreettisia tuloksia siitä, miten hanke onnistui. Pysykää siis kuulolla!

Avatar

Jaana Majakangas

Jaanalla on projektinhallinnan ja ohjelmistokehityksen ammattilainen, jolla on pitkä kokemus alalta. Hän on työskennellyt ohjelmistokehityksen, standardointihankkeiden ja teknologioiden tutkimuksen parissa myös kansainvälisissä projekteissa. Nykyisissä tehtävissään Jaana toimiin projektipäällikkönä ja ScrumMasterina sekä esimiestehtävissä.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Ei pitkäkään aika sitten minulta kysyttiin: ”Miten ihmeessä muka DevOps ja UX liittyvät toisiinsa?”. Asiaa pohtiessani ymmärsin, ettei yhteys näiden kahden välillä ole se kaikista selvin – eikä ihme. Varmasti itse kukin tätäkin lukiessa pohtii, mitä yhteistä on DevOps:lla, joka korostaa tietynlaista yrityskulttuuria ja UX:llä, joka vaatii käyttäjien aktiivista ja jatkuvaa osallistamista. Jotta yhteys ei olisi enää niin epäselvä, yhteyden voisi kiteyttää kolmeen keskeiseen teemaan.

Kaiken takana on avoimuus

Yksi keskeisistä mantroista UX-työssä on pyrkimys pois käyttäjän elämään vaikuttavista päätöksistä, jotka syntyvät suljetuissa neuvotteluhuoneissa. UX (User Experience, suom. käyttäjäkokemus) on kiteytettynä se muistijälki, joka käyttäjällä on mielessään kokemuksestaan palvelun kanssa. UX-työn, joka pyrkii tuottamaan positiivisia käyttäjäkokemuksia, keskiössä on todellisten käyttäjien osallistaminen. Tämä ei johtoryhmän kokouksessa toteudu. Parhaat käyttäjäkokemukset syntyvät käyttäjien ääntä kuuntelemalla – näin se on. Samalla kun pyritään irti suljettujen kerhojen päätöksistä, puhutaan modernissa tehokkaassa UX-työssä niiden samojen sidosryhmien osallistamisesta, jotka piileksivät neuvotteluhuoneessa.
Parhaimmat käyttäjäkokemukset saavutetaan tehokkaalla UX-työn jalkauttamisella, joka ottaa huomioon sidosryhmien ammattitaidon omasta käyttäjäkokemukseen vaikuttavasta vastuualueestaan. UX-työ onkin monesti sidosryhmien osallistamista, mutta valitettavan usein tietynlaisissa siiloutuneissa yrityskulttuureissa se ei ole kovin yksinkertaista, eikä ainakaan tehokasta. UX-ammattilaisen näkökulmasta sitä ottaakin vastaan iloiten DevOps:n mukanaan tuoman avoimuuden, joka tehostaa UX-työn keskeistä työtehtävää: kommunikaatiota sidosryhmien välillä. Mikäs sen parempi ajatus kuin tieto, että paremmalla yrityskulttuurilla voidaan saada käyttäjän ääni kuulumaan läpi organisaation. DevOps ja UX toivovat siis samaa avointa, toista arvostavaa, keskustelukulttuuria.
Se että nykyaikana yrittäisi olla ottamatta sidosryhmiä huomioon, onkin lähinnä huvittava ajatus. Nyt, jos koskaan tekijät koodareista järjestelmäasiantuntijoihin ja myyntiin ovat entistä tietoisempia, miltä hyvä käyttäjäkokemus tuntuu. Jotta tällaisessa tilanteessa UX-työ johtaa parhaimpaan lopputulokseen, tulee sen noudattaa DevOps:n viitoittamia ohjeita: yhteistyö, yhteinen tietoisuus ja yhteiset tavoitteet.

Mittaamattoman arvokas mittari

Ensimmäisiä asioita, joita minullekin Käytettävyyden perusteet -kurssilla aikoinaan sanottiin, oli ”Käytettävyys on mitattava määre”. Vaikkei asiaa usein sanota, niin sama pätee käyttäjäkokemukseen. Olipa tutkittavana melkein mikä vaan käyttäjäkokemukseen vaikuttava tekijä – tehokkuus, helppokäyttöisyys tai vaikka tarkoituksenmukaisuus – on sen toteutumista mahdollista seurata mitattavassa muodossa. UX-työ on parhaimmillaan laadullisen ja määrällisen työn tulosta, jossa määrälliset mittarit kuvaavat ”mitä” ja laadulliset tulokset kertovat ”miksi”. Käyttämällä analytiikkaa oikein voi käyttäjäkokemuksen kehitystä ja siihen vaikuttavien tekijöiden tilaa seurata tehokkaasti omissa palveluissaan. Tärkeintä on löytää sopivin yhdistelmä määrällisiä ja laadullisia menetelmiä, joilla voidaan seurata, miten saavutamme tavoitetilamme mukaisen käyttäjäkokemuksen.

Voidaankin kysyä, mitä olisi DevOps ilman UX-työn tuomaa käyttäjän ääntä palautteena?

DevOps vaatii ja hyötyy merkittävästi laadukkaista palautevirroista, jota UX-työ luontaisesti tarjoaa osana toimintatapojaan, ja on UX-työn keskiössä. Mitä UX-työ olisikaan ilman, tässäkin jutussa painotettua, käyttäjien osallistamista, joka johtaa palautevirtoihin? Käyttämällä tehokkaasti hyvin laadittuja mittareita, niin analytiikkapohjaisia määrällisiä kuin myös laadullisia, voidaan käyttäjien ääni tuoda osaksi organisaation kehitystä. Voidaankin kysyä, mitä olisi DevOps ilman UX-työn tuomaa käyttäjän ääntä palautteena?

Kevyin askelin yhdessä

Siinä missä Lean on vallannut ohjelmistokehityksen, on se myös vallannut alaa UX-työssä, termin ”Lean UX” alla. Samoin kuin DevOps kannustaa jatkuvaan kehittymiseen niin tekee myös Lean UX. Lean UX kiteyttääkin monia asioita, joita tässäkin tekstissä on sivuttu puhuttaessa DevOps:n ja UX:n yhtäläisyyksistä. Jos Lean UX:n ydinajatuksen haluaa tiivistää, voi sanoa sen lähtevän liikkeelle luottamuksesta palautteen voimaan. Ei ylisuurta määrittelyä vaan pieniä palasia lisää, joita arvioidaan tehokkaasti käyttäjien avulla. Saamme palautetta, kehitymme ja parannamme. Lean UX:n mukaisen toiminnan voi kiteyttää toistuvaan sykliin: suunnittele – toteuta – evaluoi. Jatkuvan kehittymisen ajatuksella emme koskaan ole valmiita vaan matkaamme aina kohti parempaa, joka perustuu kerättyyn palautteeseen. Palautteeseen, johon luotamme. Pienet epäonnistumiset eivät haittaa, sillä Lean UX kannustaa pieniin askeliin.
Lean UX painottaa myös eri sidosryhmien osallistamista. Jotta voimme tehdä valistuneita päätöksiä käyttäjälle tarjottavasti palvelusta, pitää meidän osallistaa sidosryhmiä. Takana ovat ne ajat, kun käyttöliittymät ja visuaaliset ilmeet suunniteltiin norsunluutornissa, ja kuin taivaan lahjana ne toimitettiin toiseen siiloon photoshopilla piirrettynä kuvana. Edessä on DevOps-aikakausi, jossa eri toimijat toimivat lean-periaatteiden mukaisesti yhdessä – tehokkaasti, kevyesti ja yhteishyödyllisesti. Painotan usein Goforen UX-suunnitelijoille, että yksi tärkeimpiä heidän tehtäviään on miettiä, edistääkö tekeillä oleva asia työn jalkautumista eteenpäin. Jokaisen ammattitaitoisen UX-suunnittelijan vastuulla onk toimia tehokkaana osana avointa toimintayhteisöä, jossa hänen tuotoksensa heijastavat käyttäjän ääntä ja ottaa huomioon vastaanottavat ja osallistuvat sidosryhmät. Tätä on myös DevOps.
Mitä siis olisi DevOps ilman UX:ää tai UX ilman DevOps:a? Vastaus lienee, että UX-työ ja DevOps eivät kunnolla toteudu ilman toista – niin kiinteästi ne ovat osa toisiaan.

Avatar

Arto Puikkonen

Arto on kokenut palveluiden muotoilija ja UX-suunnittelija. Hän on urallaan huolehtinut kymmenien web-, mobiili- ja työpöytäsovellusten muotoilusta. Arton ydinosaamista ovat käyttäjätyö sen moninaisimmissa muodoissaan sekä käyttöliittymäsuunnittelu. Goforella Arto vastaa yrityksen muotoilupalveluista

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Jokainen yritys on nykyään ohjelmistoyritys. Digitalisaation menestystarinat osoittavat, että palvelujen sähköistämisessä pitää siirtää ajatukset pois pelkän työkalun hankkimisesta. Teknistä toteutusta ei voi erottaa palvelukonseptin kehittämisestä. Palveluiden kehittäminen on jatkuvaa, ja siten myös teknistä toteutusta on pidempiaikainen kehitys eikä kertahankinta. Jatkuva kehittäminen hämärtää kehitys- ja ylläpitovaiheiden rajoja.
Tämä muutos pitää huomioida tiimiä muodostettaessa. Tehokkaan tiimin ainesosiin sisältyy markkinointia, käytettävyyttä, ohjelmistokehittämistä ja ylläpitoa. DevOps on ohjelmistokehittämisen kulttuuri, jossa painotetaan yhteistyötä yli liiketoiminnallisten lokeroiden ja nopeutetaan palautevirtoja automaation avulla. Nopeus saattaa yllättää palvelun ohjaamisesta vastaavat päättäjät, joiden tulisi huolehtia pysyvänsä kyydissä mukana.

Palautetta? Kyllä, kiitos!

Onnistunut palvelu syntyy siitä, että tehdään ajoissa ne asiat joita loppukäyttäjät haluavat (tai joita loppukäyttäjät saadaan haluamaan) ja jätetään tekemättä ne toiminnot, joita loppukäyttäjät eivät halua. Uutta palvelua kehitettäessä tarvitaan tietoa siitä mikä toimii ja myy. Tieto syntyy oppimalla ja mitä nopeammin palvelusta saadaan palautetta sitä nopeammin voidaan tehdä suuntaa korjaavia liikkeitä.
Palaute on sikäli vaarallinen sana, että suomalaiset mieltävät sen helposti negatiiviseksi. Tässä yhteydessä palautteella on kuitenkin laajempi merkitys. Palautetta on paitsi loppukäyttäjiltä saatu sanallinen palaute, myös käyttäjien käyttäytymiseen perustuva analytiikka sekä järjestelmän teknisen toiminnan monitorointi.

Palautteen kerääminen on turhaa, jos siitä ei ota oppia.

Toimivan palautevirran avulla tietää, mitä seuraavaksi kannattaa tehdä. Palvelun kehitysputki koostuu eripituisista vaiheista, joista jokainen muodostaa systeemiin takaisinkytkennän, palautevirran. Matka ideasta analytiikan keräämiseen on pitkä, koska jokainen vaihe tuo oman viiveensä kokonaisläpimenoaikaan.
devops-pipeline
Ohjelmistokehittämisen pilvipalvelut ovat vallanneet alaa voitokkaasti, erityisesti kehitysvaiheen nopeuttajana ja riskinlieventäjänä. Kokeiluihin tarvittava infrastruktuuri saadaan nopeasti käyttöön ilman erityistä sitoutumista, jonka ansiosta kokeiluja myös uskalletaan tehdä. Liiketoiminnalle se tarkoittaa nopeaa palvelukehitystä pienin riskein ja investoinnein.
Organisaatiosta ja johdon panostuksesta riippuen ohjelmistokehitys pilvipalveluineen voi olla siinä määrin edellä, että päätöksenteosta ja ohjauksesta muodostuu suhteellisesti suurin pullonkaula. Päättäjät eivät enää odotakaan kehittäjiä, vaan kehittäjät odottavat päättäjiä.

Varmista ettet seiso ohjelmistotiimisi tiellä.

Analytiikkaan ja ohjaukseen on varattava riittävästi resursseja. Tiellä seisominen hidastaa kokonaisläpimenoaikaa, joka helposti johtaa siihen, että palautevirtojen seurannasta ja käyttäjälähtöisyydestä luovutaan. Sokkona tekemisen seuraukset paljastuvat vasta pidemmän ajan kuluttua.

Varhainen Ops se palvelua pyörittää

Kun tuotantoliukuhihna rullaa sulavasti, on helpompi julkaista kerrallaan entistä pienempiä toiminnallisuusjoukkoja. Kehittämisestä tulee jatkuvaa ja se sulautuu ylläpidon kanssa yhteen. Käytännössä tämä tarkoittaa, että loppukäyttäjä käyttää palvelua heti, kun jo ensimmäiset päätoiminnallisuudet ovat toteutettu. Projektitiimistä pitäisikin tällöin löytyä ylläpito- eli Ops-osaamista alusta lähtien, eikä vasta kahden vuoden kehitystyön jälkeen.

Varmista riittävä Ops-panostus ajoissa.

Palvelinvirtualisointi ja automaatiotyökalut ovat helpottaneet jonkin verran ylläpitotyötä, ja osa perustehtävistä luonnistuu sovelluskehittäjältä muun koodaamisen ohessa ylläpidon pienellä avustuksella. Ja koska pilvipalvelut mahdollistavat infrastruktuurin muokkaamisen lennosta, voi sovellus itse ohjata omaa alustaansa esimerkiksi loppukäyttäjien mukaan.
Myös Ops-roolissa koodataan, kun ylläpidosta tuleekin toimivan automaation ohjelmointia. Dev- ja Ops-roolit sulautuvat yhteen ja ohjelmistokehitystiimeistä löytyy molempaa osaamista. Samankaltaisempien taitojen kautta kyseessä voi olla sama henkilö.

Palvelu uunista ulos

Jatkuvaan julkaisemiseen (Continuous Deployment) suhtaudutaan ohjelmistoalalla joskus fanaattisesti ja kilpaillaan sillä, kuinka monta kertaa päivässä päivityksiä viedään tuotantoon. Julkaisutahdin maksimointi ei kuitenkaan ole itseisarvo, vaan oikea tavoite on pystyä julkaisemaan aina tarvittaessa. Jatkuvan julkaisemisen tarkoitus on saada palaute varhain, vähentää turhan työn määrää ja saada palvelun ominaisuudet nopeammin markkinoille.
DevOpsin arvo on siinä, että julkaiseminen ei ole enää pelottava ja massiivinen projekti. Palvelun kehittämisestä voidaan tehdä entistä enemmän käyttäjälähtöistä. Vaikka suomalaisia kehittäjiä onkin kehuttu oma-aloitteisiksi, jatkuva kehittäminen vaatii silti jatkuvaa ohjaamista. Prosessia kannattaa viilata sieltä, missä se eniten tökkii. Kuka odottaa ketä, se selviää palautevirtojen pituuksista.

Avatar

Ville Seppänen

Ville edistää Goforella kokeilevan ohjelmistokehittämisen kulttuuria. Ohjelmistokehittämisen ohella hän konsultoi pilvipalveluiden käytössä. Palveluväylä- ja Avoindata.fi-projektien kautta Ville on auttanut Suomen julkishallintoa avaamaan tietovarantojaan.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Liikennevirasto valitsi Gofore Oy:n huolehtimaan uuden talvimerenkulun hallintajärjestelmän IBNextin käytettävyydestä.
“Järjestelmä mahdollistaa tehokkaan talvimerenkulun suunnittelun, ohjauksen, jäänmurron operatiivisen toiminnan johtamisen sekä toiminnan tuloksen seurannan Suomen, Ruotsin ja Viron kesken. Yhteistyötä on hyvin paljon eri maiden ja eri organisaatioiden välillä”, kertoo hankepäällikkö Seppo Korpela Liikennevirastosta.
Jäänmurtoa hallinnoi Suomessa Liikennevirasto sekä Viron ja Ruotsin Merenkulkulaitokset. Suomenlahdella ja Pohjanlahdella näillä mailla on käytössä yhteensä 14 jäänmurtajaa.
“Periaatteessa jokainen maa vastaa jäänmurrosta omilla aluevesillään. Laivat käyttävät jääolosuhteissakin helpointa mahdollista reittiä ja toisen maan jäänmurtaja voi avustaa toiseen maahan kulkevaa laivaa tarvittaessa myös toisen maan aluevesillä”, selventää Korpela.
”Järjestelmän puitteissa maat sopivat ja raportoivat, mikä murtaja avustaa mitäkin laivaa tai laivasaattuetta ja minne asti. Tätä tietoa toimitetaan myös kauppalaivojen ja teollisuuden käyttöön.”

Jäänmurtajalla jytisee

Järjestelmää käyttää moni taho ja käyttöliittymien on taivuttava eri ympäristöihin ja tarpeisiin. Goforen tehtävä on varmistaa käytettävyys kaikissa tilanteissa.
Jäänmurtajat esimerkiksi tärisevät paljon jäänmurron aikana, ja tämä on otettava huomioon käytettävyyssuunnittelussa. Jäänmurtajien lisäksi järjestelmän tietoja käyttävät eri maiden talvimerenkulusta vastaavat organisaatiot, alusliikenteen ohjauskeskukset, Ilmatieteen laitos ja muun muassa Suomessa luotsauksesta vastaava Finnpilot Pilotage Oy. Jokaisen tahon käyttötapa on erilainen.
“Hankkeessa toteutetaan nykyaikainen karttapohjainen käyttöliittymä ja mahdollistetaan käyttö erilaisilla päätelaitteilla myös mobiilisti. Nykyinen järjestelmä koetaan hyväksi, joskin se on teknisesti vanhentunut. Käytettävyyden täytyy olla erityisen hyvä, jotta käyttäjät hyväksyvät uuden järjestelmän uudella konseptilla.”
Gofore aloittaa käytettävyyden kehittämisen perehtymällä eri käyttötarpeisiin maalla ja merellä ja huolehtii käyttäjien näkökulmasta koko hankkeen ajan.

Digitalisaatio muuttaa merenkulkua

Liikenneviraston pitkän tähtäimen tavoite on automatisoida ja digitalisoida liikenteenohjauksen informaatiojärjestelmiä.
“Kaikki tiedonsiirtoon ja automatisointiin liittyvät hankkeet otetaan huomioon meriliikenteen palveluiden kehittämisessä. Jatkossa meriliikenteen järjestelmien kehittämisessä on otettava entistäkin kansainvälisempi aspekti.”
IBNext kuuluu osana WINMOS-hankkeeseen, joka saa tukea EU:n TEN-T-ohjelmasta. Hankinnasta vastaa Suomen Liikennevirasto yhdessä Ruotsin Merenkulkulaitoksen kanssa. Viro on mukana lisensoituna käyttäjänä. Järjestelmän toteuttaa salolainen Dimenteq Oy.
Lisätietoja:
Liikennevirasto
Helena Niemelä
Merenkulun ylitarkastaja, Liikenneviraston talvimerenkulunyksikkö
helena.niemela@liikennevirasto.fi, 029 534 3321029 534 3321
Gofore Oy
Arto Puikkonen
Johtava konsultti, UX-palvelut
arto.puikkonen@gofore.com, 050 485 8556050 485 8556

Avatar

Arto Puikkonen

Arto on kokenut palveluiden muotoilija ja UX-suunnittelija. Hän on urallaan huolehtinut kymmenien web-, mobiili- ja työpöytäsovellusten muotoilusta. Arton ydinosaamista ovat käyttäjätyö sen moninaisimmissa muodoissaan sekä käyttöliittymäsuunnittelu. Goforella Arto vastaa yrityksen muotoilupalveluista

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.