Miten lähteä avaamaan rajapintoja?

API-rajapinnoilla voidaan rakentaa vaikka kokonaan uusia liiketoimintamalleja, ja monesti ne tuovat silkkaa säästöä. Miten rajapintojen avaamiseen kannattaa lähteä?

Rajapinta on englanniksi interface ja API tarkoittaa suomeksi käännettynä ohjelmiston kehitysrajapintaa. Käytän tässä blogipostauksissa API-rajapinta-ilmaisua, vaikka se onkin vähän tautologinen.

Klassinen ja mahdollisesti yksinkertaisin esimerkki rajapinnasta on verkkosivut. Jos organisaatiollasi on siis verkkosivut, tarjoat kömpelönä APIna html-koodia. Fiksumpi rajapinta voisi olla rakennettu hyödyntämään esimerkiksi verkkosivun tuotantojärjestelmää REST-rajapintojen pyörittämiseen.

HTML-koodi ja REST-rajapinnat ovat ohjelmisto-, käyttöjärjestelmä- ja lisenssivapaata. Voit tarjota HTML:ää linux-palvelimella ja sitä on yhtä helppo lukea iPhonella kuin Windows-tietokoneellakin. Hyvä rajapinta ei edellytä samojen laitteiden tai ohjelmistojen ostamista, joita sen toisella osapuolella on.

 

Muista tietoturva

Kaikki eivät ole aina kuitenkaan suoraan avoimien rajapintojen ystäviä. Tietoturvapuolella monella on kiusaus joko refleksinomaisesti todeta, että tosi hienoa kun kokeillaan uusia juttuja, mutta suin päin ei sellaisia pitäisi kokeilla. Tai jopa sanoa, että ei kannata kokeilla – koska emme kaikkein vaikeimpia rajapintoja osaa kuitenkaan tehdä, on ajanhukkaa puhua niistä.

Tietoturva on otettava tosissaan, mutta päätä ei kannata laittaa kuitenkaan pensaaseen. Rajapintojen turvallisesti tekeminen on mahdollista ja jopa välttämätöntä, jotta niitä osaa käyttää, kun moinen osoittautuu kaupallisesti välttämättömäksi.

Rajapinnoissa voi soveltaa sotasairaaloiden mallia ajankäytön priorisoinnille; jos ei ole pitkää kokemusta rajapinnoista, luottamuksellisille henkilötiedoille kannattaa varmasti aluksi sanoa ei. Ei aloiteta liian vaikeasta, potilas kuolee joka tapauksessa.

 

Opettele toiminnallisilla rajapinnoilla

Niin sanotuissa datarajapinnoissa on ideana, että niissä vain jaetaan tietoa, mutta niillä ei voi muuttaa tietoa. Lisäksi suoraviivaisimmissa ei varmasti ole edes henkilötietoja, jolloin niihin ei liity samoja riskejä.

Suoraviivaisen datarajapinnan tekeminen, jossa ei ole henkilötietoja, on helppoa. Neuvomme on, että kehitystiimille voi antaa varsin itsenäisen vastuun toteutuksesta, kunhan se tehdään laillisesti ja eikä se vaikuta organisaation toimintaan tai muuta tietoa missään.

Kiinnostavimpia sekä oppimisen että vaikuttavuuden kannalta ovat toiminnalliset rajapinnat, joihin ei kuitenkaan vielä liity henkilötietoja. Näihin kannattaa laittaa paukkuja, sillä ne ovat kohtuullisen haastavia, joten niiden rakentaminen antaa oppia oikeassa kontekstissa. Kun keskittyy luottamuksellisuuteen ja eheyteen, ja hoitaa ne mahdollisimman hyvin, voi edetä pikkuhiljaa myös henkilötietojen käsittelyä sisältäviin rajapintoihin.

 

Kun toimeen sitten ryhtyy, mitä pitäisi ottaa huomioon?

Kannattaa aloittaa siis avaamalla se kaikkein helpoin juttu, datarajapinnat. Tiimi voi tehdä sen itsenäisesti, ja siihen ei tarvitse laittaa aivan hirveästi paukkuja. Kannattaa kuitenkin varmistaa, ettei kukaan ole avaamassa rajapintoja yksin.

On hirveän vaikea tehdä turvallista työtä tehokkaasti. Projektissa on oltava mukana ainakin kaksi ihmistä, joista toisen tehtävä on tehdä ja toteuttaa, ja toisen työnä on tarkastaa, että laatu säilyy korkeana ja asiat tapahtuvat tietoturvallisesti ja säännösten mukaisesti. Asetelma on kuin keskushyökkääjällä ja maalivahdilla.

Datarajapintoja avatessa kannattaa varmistaa, että aikaa on vähän enemmän kuin jos sama data olisi tuotu organisaation verkkosivulle. Kun rajapintoja ollaan avaamassa ensimmäistä kertaa, opetellaan uutta. Kun rutiinit ovat ajan myötä kasassa, rajapintojen avaamisen pitäisi olla helpompaa kuin verkkosivujen avaaminen, sillä API-rajapintoihin ei liity esimerkiksi visuaalisen käyttöliittymän suunnittelua.

 

Ennen kuin etenet, suunnittele

API-rajapinnoissa hyvin suunniteltu on puoliksi tehty. Tekemisellä aloittaminen on hyvää hakkerieetosta, mutta mallilla tulee helposti avanneeksi enemmän kuin oli tarkoitus tai vääriä asioita. Sähläämällä taas voi käydä niin, että avaa dataa, joka ei kiinnosta ketään tai joka on muodossa, jossa kukaan ei voi sitä hyödyntää.

Dataan pitää myös tutustua. On täysin normaalia, että tiedossa, jossa ei pitänyt olla henkilötietoja, onkin seliteteksteihin laitettu sosiaaliturvatunnuksia, vaikka ohjeistus toisin sanoo. Varmista siis mitä rajapinnan kautta kulkeva data oikeasti sisältää.

Tietosuojalainsäädäntö on syytä tuntea huolella, varsinkin siinä vaiheessa kun rajapintaan liittyy henkilötietoja. Lakia tulee tuntea paitsi sen takia, ettei tule rikkoneeksi sitä, mutta myös siksi, että on ihan yhtä tärkeää osata perustella muille, miksi ei riko säännöksiä. Rajapintojen avaaminen voi herättää pelkoa esimerkiksi tietosuojarikkeistä, jolloin on hyvä tietää, mitä on tekemässä ja olla selkeät sävelet, jottei tärkeä työ mene hukkaan väärien pelkojen vuoksi.

 

Tunne lisenssit ja teetä uhka-analyysi

Pelkkä datan tunteminenkaan ei riitä, pitää olla myös selkeä ymmärrys siitä, mistä dataa luetaan, ja mistä siihen kirjaudutaan. Tieto pitää tuntea yhtä hyvin fyysisellä tasolla, tietojärjestelmätasolla sekä loogisella tasolla. Jos esimerkiksi osoite on väärin, on oltava kyky ymmärtää, mistä väärinkirjaus johtuu, ja kenen vastuulla on korjata se. Huonolaatuisen datan jakaminen ei kannata.

Uhka-analyysin teettäminen on myös kannattavaa kun suunnittelee rajapinnan avaamista. Se tarkoittaa sitä, että joku tietoa ja järjestelmiä ymmärtävä listaa kaikki mahdolliset kohdat, mikä rajapinnan avaamisen johdosta voi mennä pieleen. Voiko rajapintaa käyttää esimerkiksi luottamuksellisen tiedon joutumiseen vääriin käsiin?

Lisenssit kannattaa myös tuntea. Sellaiset sopimukset eivät ole harvinaisia, joissa rajapintojen käyttö on järjettömän kallista. Olisi piinallista herätä Oraclen myyntimiehen soittoon, jonka mukaan lisenssikustannukset ovat nousseet 15 000 kertaisiksi.

Katso webinaari: API-liiketoimintamallit

Sarvikuonojohtaja saa transformaatiossa köniinsä

Johtamista mitataan vaikeissa tilanteissa – muun muassa niissä, jossa organisaation tiukat luvut tuntuvat vaativan arvojen, roolin tai luonteenvastaisia toimia.

Mitä siis tehdä siinä tilanteessa, jossa itselle on otettu, tai alaiselle on annettu tehtävä, joka on vahvasti ristiriitainen, ja jossa onnistumisessa kovat tavoitteet taistelevat tekijän pehmeiden tavoitteiden kanssa?

Tällaisissa tilanteissa moni johtaja toimii vaistojen varassa ja toiminta usein noudattaa kiusallisen ennustettavia malleja ristiriidan yksityiskohdista riippumatta.

Johtaja voi olla:

Sarvikuonojohtaja vähät välittää organisaatioon muodostuvista vaikeista työyhdistelmistä, jossa onnistuminen edellyttää toisen näkökulman kokonaan jättämistä huomiotta, koska kompromisseille ei ole jäänyt tilaa. Kutsun tätä sarvikuonojohtamiseksi. Tyypillinen sarvikuonojohtajan sanonta on “ei kiinnosta, tärkeintä on, että pidät kiinni niistä tunnuslukulupauksista, jotka sovimme viime kehityskeskustelussa.”

Empaattinen johtaja tukee vaikeissa tilanteissa alaisen jaksamista, mutta sarvikuonojohtajan tavoin pitää tiukasti kiinni niistä lupauksista, jotka alaiselta on saatu puristettua. “Kyllä sä tämän jaksat. Ymmärrän, että voi olla vaikeaa, mutta kohta tää pahin vaihe on ohi.”

Kompromissijohtaja ämpyilee ja etsii vaikean tilanteen kohdalla kompromisseja, jotka vesittävät tavoitteen ja tuovat kaikille periksiannon fiiliksen. Mitään ei ole pakko tehdä kunnolla, kun aina voi pyytää luvan jättää puolitiehen.

Sumanpurkajajohtaja eli pehmeiden ja kovien arvojen välisiä ristiriitoja purkava johtaja voi parhaimmillaan yhdellä lauseella auttaa ymmärtämään ristiriidan näennäisyyden tai toisaalta tehdä rakenteellisiakin muutoksia, jotta ristiriita ei jää yhden kannettavaksi vaan se saatetaan jopa saada puretuksi.

 

Sumanpurkaja paketoi homman kasaan

Moni yritys ja tiimi käy läpi transformaatiota, harkitsee sellaista, tai pelkää moista, esimerkiksi vaikkapa ketteryyteen, asiakaslähtöisyyteen, leaniin tai itseohjautuvuuteen siirtymistä.

Transformaatiossa onnistuminen ja onnistumisen kustannukset riippuvat johtajan tavasta hallita pehmeiden ja kovien arvojen ristiriitaa. Transformaatiossa johtajan ja alaisen minäkuvan ja uuden roolin tai tiimidynamiikan hetkelliset ristiriidat voivat olla äärimmäisellä, avioeroon rinnastettavalla stressitasolla.

Transformaatiossa kompromissijohtaja epäonnistuu, sarvikuonojohtaja aiheuttaa irtisanomisten aallon ja empaattinen johtaja sairaslomien aallon. Vain sumanpurkajajohtaja voi saada homman pakettiin ilman merkittäviä taloudellisia vaurioita.

Erityisesti itseohjautuvat organisaatiot vaativat valtavan määrän ristiriitojen purkua onnistuakseen. Epäilen, että vain ristiriitoja purkamaan oppinut johtaja voi pitemmän päälle nauttia toiminnasta itseohjautuvassa organisaatiossa.

 

Mistä aloittaa?

Havainnoi omaa toimintaasi vaikeissa tilanteissa – vesitätkö muutoksen, painatko väkisin läpi tunteista välittäen tai välittämättä vai löydätkö usein viisastenkiven eli tavoitteista kiinni pitävän, mutta vaikeat emotionaaliset tai sosiaaliset tilanteet ennakkoon tai lennossa poistavan johtajan?

Muista, että pitemmän päälle et voi saada hyviä tuloksia, jos tiimissä on ahdistusta, pelkoa tai häpeää. Johtajan on mentävä kohti vaikeita tunteita ja auttaa niiden purkaminen systeemiä tai ajattelutapaa muuttamalla.

 
New call-to-action

Onko blockchain yrityksellesi pelkkä troijan hevonen?

Harvat uudet teknologiat ovat yhtä kiinnostavia ja samalla yhtä vaikeita hyödyntää olemassaoleviin liiketoimintamalleihin kuin lohkoketju, eli blockchain. Lohkoketjun kansikuvajutut bitcoin-kurssikäyrän kera ovat helposti kirjoitettavia, teknologiaan on sijoitettu valtava määrä rahaa ja näyttää siltä, kuin lohkoketjulla olisi todella helppo tienata miljoonia tai miljardeja. Lohkoketju on vieläpä todella hienoa teknologiaa!

Väitän silti voimakkaasti, että useimmille yrityksille lohkoketju on tässä vaiheessa pelkkä kangastus tai troijan hevonen, vaikeasti kaupallistettava superkiinnostava teknologia, joka häiritsee aivan yhtä kiinnostavien mutta nopeasti kaupallistettavien teknologioiden kehitystä.

Blockchain-hypestä tulee Itselle mieleen Ford-autovalmistajan Nucleon -konsepti, kuvankaunis amerikanrauta, jonka moottorina piti olla ydinreaktori. Kun ydinreaktorit olivat kuuminta hottia, niitä ajateltiin asennettavan autoihin, lentokoneisiin, juniin ja jokaiselle asuinalueelle. Todellisuus olikin sitten jotain muuta.

Vähän sama tilanne on lohkoketjun kanssa. Valtavan hienoa teknologiaa, jolla voidaan tehdä uusia palveluita, joita ennen ei olisi voinut kuvitellakaan. Valitettavasti suurin osa nykyisen liiketoimintamallin ja lohkoketjun yhdistelmistä on yhtä banaaleja kuin Fordin ydinreaktorilla käyvä henkilöauto – teoriassa mahdollisia, mutta härveleitä, joiden haitat eivät koskaan vastaa niistä saatua hyötyä.

Mistä sitten kannattaisi aloittaa? Itse ehdotan, että nyt on oikea aika jakaa uusien teknologioiden kehitys kolmelle eri tiimille tai striimille, jos tilanne on samanlainen kuin monilla asiakkaillamme.

  • Tiimi I

Useimmat organisaatiot ovat yllättävän käsityövaltaisia, kun niihin kunnolla tutustuu. Arkisia työvaiheita varten tulostetaan A4:ia, tieto siirretään järjestelmästä toiseen käsin tai eri järjestelmissä olevaa tietoa ei saada yhdistettyä fiksumpaa toimintaa varten.

Yritys, jonka tiedot ovat tällä tavalla hujan hajan ei voi onnistua uudistumisessa, mutta onneksi nykyään yhteisen näkymän luominen on halvempaa ja nopeampaa kuin koskaan aiemmin, eikä tätä varten ole pakko ostaa SAP:pia tai mitään muutakaan monoliittista sovellusta.

  • Tiimi II

Toisena striiminä etsisin kaikki ne kohdat, joissa arkisia päätöksiä tehdään täysin prosessin mukaisesti. Jokainen käsityönä tehty, tarkkaa byrokraattista prosessia noudattava päätös kannattaa automatisoida. Tiedon käsittelyn nopeuttaminen tuo yllättäviä hyötyjä, useimmiten sekä asiakkaalle että myynnille ja markkinoinnille.

  • Tiimi III

On vaikea saada rahoitusta tiimeille I ja II ilman vanhoista malleista poikkeavia liiketoimintasuunnitelmia. Asiat ovat rempallaan, koska loppujen lopuksi vanhassa maailmassa on ollut halvempaa teettää enemmän käsityötä kuin automatisoida prosessit loppuun saakka. Tämä on muuttunut viime vuosina. Automatisointi on jatkossa onnistumisen edellytys, eikä siitä voi tinkiä. Uudet tekoälyyn perustuvat liiketoimintamallit vaativat perustuksekseen hyvää tietoa ja organisaation, joka ei tuhlaa aikaa ja rahaa turhaan käsipelillä tunkkaamiseen.

Tekoäly, tai oikeastaan sen koneoppimiseksi kutsutut toteutustavat, ovat jo arkipäiväisiä. Kaikkien suurten internetyritysten, Googlesta Spotifyhyn, onnistumisen salaisuus on fiksussa koneoppimisen käytössä. Useimmilla toimialoilla tekoälyä fiksusti hyväksikäyttävä yritys tulee seuraavina vuosina pieksemään ne, joiden tekoälytiimi ei ole päässyt vauhtiin.

Kolmostiimi toimii myös loistavana kirittäjänä kahdelle muulle tiimille. Tieto, jonka yhdistäminen on vaikeaa tai johon liittyvät päätökset tehdään vielä käsipelillä, tulee yhdistetyksi ja automatisoiduksi, kun kolmostiimi lupaa sellaista, jota kilpailijalla ei ole – automaattisen asuntolainapäätöksen, juuri sinulle halvalla räätälöidyn puvun valmistuksen tai juuri sinun makuusi viritetyn illallisreseptin.

Me Codentossa autamme teknologiavalinnoissa ja olemme ammattilaisia Tiimien I, II ja III työssä. Etsimme jatkuvasti uusia arkkitehtejä teknologiatiimiimme ja teemme niin suuria kuin pieniä teknologiavalinta toimeksiantoja yksityisellä ja julkisella puolella.

 

Banneri Uuden verkkopalvelun teknologiavalinnat 2018

Miten itseohjautuvuus viedään yrityksessä totuttua pitemmälle?

 

”Useimmille firmoille on valtavasti hyötyä siitä, että työntekijät pääsevät suoraan vaikuttamaan. Se taas vaatii, että yrityksen johto uskaltaa antaa työntekijöilleen tilaa menestyä.”

Lausuin noin Tivi-lehden haastattelussa ja uskon siihen vahvasti. Johtajuus ei silti häviä mihinkään vaikka sen antaa levitä organisaatiossa entistä tasaisemmin ja lähemmäksi asiakasta.  

Codento on mukavasti kasvanut konsultointialan yritys, jonka hallitus joutui reilun 20 hengen yrityksen koossa miettimään, miten yritys tästä kasvatetaan yli 100 hengen kokoon kentässä, jossa sekä tekijöistä että asiakkaista kilpaillaan verisesti, mutta hymyssä suin.

Totuttu tapa olisi ollut väliportaan johdon luominen, mutta me päätimme siirtyä alkavasta hierarkkisesta mallista täysin toiseen suuntaan, itseohjautuvuuteen.

Vanhat tavat istuvat sitkeässä, mutta S3 hurmasi lopulta

Alku oli vaikeaa, hierarkiset toimintatavat ovat meillä kaikilla reflekseissä eikä uudelle mallille syntynyt tilaa kun päätökset tapahtuivat kuten ennenkin.

Etsimme vaihtoehtoja ja malleja ja toivoimme löytävämme “avoimen lähdekoodin” mallin, joka näyttäisi meille sopivalta, ja ehkä jopa laajempaa suosiota saavalta. Pienen etsinnän jälkeen löysimme S3 (tai virallisesti Sosiokratia 3.0) -mallin, joka tuo uudet työkalut yhteisölliseen päätöksentekoon.

Parin S3-koulutuskerran jälkeen jätimme vanhan taakse, lopetimme johtoryhmän ja siirsimme vastuut S3-tyyppisesti piireille, eli yhden teeman ympärillä tapaaville päätöksentekoelimille.

Päätös oli pelottava…monet meistä tietotyöläisistä ovat tottuneet tehottomuuteen ja päättämättömyyteen porukassa. Juuri tämän ratkaisemiseen S3 keskittyy, eli sen ytimessä ovat palaverikonventiot, jotka tuovat kaikille tilaa ja pitävät kovaäänisimmät paremmin kurissa.

Codentolaisia S3-valmennussessiossa.

Plussia ja miinuksia

Nopeampaa, parempaa päätöksentekoa. Yksi S3:n periaatteista, “Riittävän hyvä juuri nyt, kelpaa kokeiltavaksi” (englanniksi “Good enough for now, safe enough to try”), kajahti yhdessä jos toisessakin palaverissa ja alkukankeuden jälkeen päätöksiä on syntynyt nopeammin, tehokkaammin ja tarkemmin asiakkaiden tarpeet huomioon ottaen kuin koskaan aiemmin.

Kasvua ja rekrytoinnin onnistumisia. Yritys kasvoi viime vuonna 14 uudella osaajalla, nopeammin kuin koskaan Codenton historiassa. Muutoksen hinta oli kuitenkin kova; useampi kokenut konsultti ei ollut valmis tähän muutokseen ja valitsi lähteä talosta.  

Parempaa asiakaspalvelua ja -tuntemusta. Mitä enemmän olemme siirtäneet strategisten kokeilujen päätöksentekoa niille, jotka elävät etulinjassa asiakkaiden kanssa, sitä paremmin kokeilumme ovat menneet ja sitä paremmin projektimme luistavat. Tyytyväinen asiakas on paras mittari.

Kuvassa Codenton devaajat Miili, Jukka ja Turo. Turo Mikkonen (oik.) on myös uusi hallituksemme puheenjohtaja.

Ensimmäinen S3-hallitus

Hallitus tekee monenmoista yrityksessä; seuraa, valvoo, hoitaa lakisääteiset tehtävät ja hyväksyy strategian ja tärkeät muutokset toimintatavoissa. Hallitus on osakkeenomistajien ääni yritykseen.

Ensimmäisen täyden S3-vuoden jälkeen huomasimme, että itseohjautuvuuden ja hyvän ulkopuolisista koostuvan hallituksen välillä on jännite. S3-malli korostaa jännitteiden huomaamista, nimeämistä ja ratkomista.

Ratkoimme tätä jännitettä kirjaamalla hallituksen moninaiset roolit ja mietimme tarkkaan, miten ne voisivat parhaiten toteutua itseohjautuvassa yrityksessä. Onko hallitus edes tarpeen? Voiko ilman sellaista elää?

Hallitus onkin lakisääteisesti pakollinen, ja sen on oltava aktiivinen, mutta se voi olla aivan eri tavalla miehitetty kuin tavallisesti. Suuri osa entisestä hallitusroolista on nyt jakautunut erilaisille piireille, joista parhaat hoitavat jo vastuunsa selvästi paremmin kuin hallitus parhaina päivinäkään.

Mitä sitten oikeastaan päätimme tehdä?

  1. Olemme jakaneet kaiken jaettavissa olevan tiedon kaikille työntekijöille jo vuosien ajan.
  2. Hallitusvastuun voi jakaa helpommin kun kaikki tietävät jo kaiken, minkä haluavat tietää.
  3. Valitsimme työntekijöistä 1+1 hengen hallituksen.
  4. Hallituksen tärkeät seurantavastuut toteutuvat paremmin kuin koskaan ennen: konsulttiyrityksen sisältä näkee paremmin, miten yrityksessä menee ja missä riskit ovat.
  5. Virallisia hallituksen kokouksia tulee silloin, kun tarvitaan virallinen hallituksen päätös. Molemmat hallitusvastuussa olevat tekevät tuolloin yhteistyötä ja heille on saatavilla paras rahalla ostettava lainopillinen apu, tarvittaessa.
  6. Useimmat hallituspäätökset on vastuutettu Codenton viikkokokoukselle. Teemme yhdessä parempia päätöksiä kuin vain osa meistä – ja tämä koskee myös tärkeitä strategisia päätöksiä.
  7. Ulkopuolista näkemystä tuomaan kutsumme alojensa parhaita asiantuntijoita. He tuovat päätöksentekoon ulkopuolista näkemystä ja luovat tilaa pitkäjännitteiselle keskustelulle ja päätöksenteolle.  Olemme projektiorganisaatio ja uskomme projektien voimaan niin omassa työssämme kuin asiantuntijoiden neuvoissa.
  8. Kaikkein kimuranteimpia tilanteita varten olemme varautuneet pitämään ylimääräisiä yhtiökokouksia. Osakkeenomistajien ääni on hyvä käydä hakemassa suoraan silloin, kun oikea reitti ei ole selvä.

Olen aivan fiiliksissä. Päällimmäisinä innostus, kiitollisuus ja kasvava opinhalu. Opimme yhdessä joka päivä lisää.

Petri
Twitter @aukia

DevOps on kuin robotisaatio

DevOps on mukavan lähestyttävä trendi. Sitä voi tavoitella pienissä pätkissä ja jo ensi askeleista voi olla suuri hyöty, kunhan ne on oikein valittu.

Hyvien tai erittäin hyvien ohjelmistojen kehittäminen oli ennen kuin Rolls Roycen käsin rakentamista. Hidasta, kallista ja jokainen työvaihe vaati erikoisammattilaisen, jotta kokonaisuus ei kärsisi. Jokaisen vaiheen käsityö on asiakkaasta tuntunut tärkeältä, sillä onhan valitulla mallilla ennenkin saatu hyviä rollsseja.

Kokeilua ja yhteistyötä

DevOps on kokeilevan kehityksen toimintamalli, jossa sovelluksia kehitetään pikaisesti iteroiden ja matalalla kynnyksellä. Aiemmin kehittäjät (Development) ja tuotanto (Operations) ahersivat omissa siiloissaan ja yhteistyö ei ollut aina kovin tiivistä. Kehittäjät kehittivät ja tuotanto vastasi järjestelmien pyörityksestä. Siilojen väliin katosi paljon tärkeää tietoa.

Enää edes maailman superrikkailla ei ole varaa tehottomiin työtapoihin. Tehtailla noudatetaan kiltisti tehokkaita Lean-menetelmiä ja ne työvaiheet, jotka voidaan, automatisoidaan robotein ja alihankinnan kautta. Turhat siilot on purettu. Kun kokonaisuus on hyvin hallittu, teknologia ei heikennä laatua vaan itse asiassa parantaa sitä.

“DevOps tarvitsee olutta”, innosti seminaaripuheessaan virolainen DevOps-evankelista Kaimar Karu, tarkoittaen sitä, että kehittäjien ja tuotannon tulee viettää aikaa yhdessä ja tutustua toisiinsa.

DevOpsilla parempaa softaa nopeammin

DevOps on toimiva kattonimi sille, että ohjelmiston kehittämistä, testausta, käyttöönottoa ja ylläpitoa lähestytään prosesseina, jotka kannattaa mahdollisuuksien mukaan saada kerrasta toiseen tehtyä juuri samalla tavalla. Investoimalla alussa työaikaa, ja ehkä vähän työkaluihinkin, saadaan työvaiheet, joiden teko oli ennen työlästä, toimimaan täysin tai osin automaattisesti.

Kun DevOpsissa onnistutaan, yritys menestyy ja paradoksaalisesti Rolls Roycen tai Valmetin autotehtaan tavoin, palkkaa lisää väkeä tekemään yhä enemmän tulosta. Suurin hyöty on usein siinä, että hyvin robotisoitu, eli devopsattu, ohjelmistokehitys tuottaa parempaa softaa nopeampaan tahtiin. Tällaista on mukava kaupata asiakkaille.

Moni uusi johtamismalli on haastava ottaa käyttöön, sillä monista malleista saadaan hyötyjä vasta vuosien kuluttua. DevOps on käyttäjäystävällisempää ja ketterämpää. Useimmissa organisaatioissa ensivaiheet, kuten ohjelmiston automaattinen kääntäminen lähdekoodista ajokelpoiseksi (continuous integration eli CI) tai ohjelmiston automaattinen asentaminen käännöksen jälkeen testilaitteistoon, kuten servereille, on varsin suoraviivaista.

Oletko ottanut jo ensimmäisen askeleen devopsiin yrityksessäsi? Mitä ajattelit tehdä tämän eteen seuraavassa strategisessa suunnittelupalaverissa?

-Petri
Twitter @aukia