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

Millä perusteella teknologia tulisi valita?

Gartnerin malleissa ja menetelmäkäsikirjoissa kaikki menee ihanasti, kun taas käytännön elämässä kehitystiimit ja IT-yksiköt joutuvat tekemään teknologiavalintoja usein puutteellisilla tiedoilla. Erityyppiset hankinnat tulevat eteen niin harvoin, että edellisen kierroksen jälkeen markkina ja sen pelurit ovat ehtineet muuttua täysin. Ostaja on helposti toimittajien mainospuheiden varassa. Vai onko? Ei välttämättä, kun pitää muutaman perusasian valintoja tehdessään mielessä.

 

1 Panosta liiketoimintakriittisyyden mukaan

Ihan ensin hankintaa miettiessä on syytä tunnistaa, minkä verran järjestelmään on perusteltua panostaa. Jos kyseessä on aivan liiketoiminnan keskiössä oleva järjestelmä, jolla etsitään kilpailuetua ja kirkkaampaa tulevaisuutta, sen kehittämiseen voidaan panostaa aivan eri tavalla kuin jos kysymys on toiminnan rutiineista.

Jos tarve kuuluu jälkimmäiseen kategoriaan, hankintaa suunniteltaessa kannattaa saman tien kääntää päälle vaihde, jolla ratkaisut tarpeisiin mietitään vaikka millä ilveellä olemassa olevien valmisratkaisujen ympärille ja kustomointia tehdään minimaalinen määrä.

Seuraavat alaluvut koskevat erityisesti ensimmäisen kategorian teknologioiden valitsemista, niihin kun on todella aihetta keskittyä.

 

2 Varmista käyttäjätarve

Seuraavaksi on ymmärrettävä käyttäjän tarve. Mikä on käyttäjän perusongelma, joka teknologian on syytä ratkaista? Millainen palvelu sen voisi ratkaista, ja miten pystymme varmistamaan että potentiaalisen toimittajan tai meidän itse kehittämämme teknologia oikeasti tekee näin?

Jos mahdollista, ennen investointia on hyvä käyttää viikko-pari sen varmistamiseen, että käyttäjätarve on oikeasti kuultu käyttäjiltä itseltään eikä mielikuviteltu kulmahuoneessa. Ja samalla on hyvä yksinkertaisimmalla mahdollisella prototyypillä myös varmistaa, että löyhästi kaavailemamme ratkaisu oikeasti täyttää tuon käyttäjätarpeen – ennen kuin olemme upottaneet siihen merkittäviä määriä aikaa ja rahaa.

 

3 Analysoi liiketoiminnan tarve

Lähdettäessä toimittamaan käyttäjille sitä mille löytyi toivottavasti huutava tarve, on seuraavaksi selvitettävä liiketoiminnan teknologialle asettamat reunaehdot. Miten asiakkaan toivoma asia aiotaan toimittaa? Onko valintoja, joita on syytä tehdä vaikkapa hinnoittelun tai järjestelmän toimintasyklien suhteen?

 

4 Tutki uudet fiksut työtavat

Käyttäjän ja liiketoiminnan tarpeen lisäksi teknologiaan useimmiten liittyy organisaation työn arkea: teknologialla tehtävää asiakaspalvelutyötä, ylläpitoa tai taustaprosessia. Teknologiaa valitessasi haluat luultavasti varmistaa, että organisaatiosi on hahmottanut työtavan jolla sitä tullaan käyttämään.

Yleensä tässä kohtaa ei haluta menettää sitä mahdollisuutta, että uuden teknologiavalinnan siivin voidaan uudistaa myös työtapa. Kun käytetään hetken aikaa työtavan analysointiin, huomataan, mikä osa tekemisestä oikeastaan tuottaa arvoa asiakkaalle. Arvovirtakartta on tähän hyvä väline. Analyysin jälkeen teknologiavalinnalla voidaan linjata, että työssä saadaan oikeasti keskityttyä asiakkaan saamaan arvoon ja pakolliset rutiinit pystytään hoitamaan mahdollisimman tehokkaasti.

 

5 Kartoita tietojärjestelmäympäristö

Harvoin teknologiaa päästään valitsemaan puhtaalle pöydälle. Yleensä ympärillä on elinkaaren eri vaiheissa olevia tietojärjestelmiä joihin uuden teknologian pitää liittyä, ja palapeli rajoittaa valintoja. Näiden mallintamisen tapaa tärkeämpää on, että ne ja niiden integrointitarpeet tunnistetaan ennen teknologian valintaa. Esimerkiksi: millaisia rajapintatarpeita teknologian pitäisi täyttää?

 

6 Huomaa muut rajoitukset

Edellä mainittujen lisäksi on olemassa yleensä vielä muitakin ulottuvuuksia, jotka rajoittavat teknologiavalintaa. Joskus teknologian käyttöönotolla on aikataulu, joka rajoittaa ratkaisuvaihtoehtoja – kehitykseen panostamiseen ei yksinkertaisesti ole aikaa, vaan pitää rakentaa olemassa olevien ratkaisujen päälle. Joskus toimintaan liittyy lainsäädäntöä, joka asettaa teknologialle rajoituksia, esimerkiksi tietojen sijainnin tai muiden tietoturvatekijöiden muodossa.

 

7 Mieti elinkaaritarpeet

Useimmiten tässä pohdinnan tässä kohtaa vaatimusten yhdistelmä ajaa jo kohti melko harvalukuista joukkoa teknologia- ja toteutustapavaihtoehtoja. Yksi pohdinta on kuitenkin vielä jäljellä: teknologian elinkaari. Useimmiten halutaan välttää joutumista tuoreen teknologian ensimmäisten kokeilijoiden joukkoon.

Kun teknologia on ollut jo jonkin aikaa olemassa, tarjolla on ilmaista etua muiden tekemistä virheistä ja kehittämistä perusasioista eli hienosti sanoen ekosysteemin kypsymisestä. Toisaalta jos kysymys on kriittisestä teknologiasta ja haetaan kilpailuetua, joskus kannattaa myös maksaa oppirahat ja olla eturintamassa.

Joka tapauksessa on hankittava markkinaymmärrystä ja joskus myös meediopalveluita hahmottaakseen myös elinkaaren loppupää: Miten pitkälle tulevaisuuteen teknologialle voi olettaa jatkuvuutta vs. käyttötarpeen mitta? Miltä ekosysteemin kehitys näyttää, vaikuttaako siltä että teknologialle on tarvittaessa löydettävissä ylläpitäjiä myös tulevaisuudessa? Olemmeko investoimassa kisojen voittajahevoseen vai näyttäkö uhkaavasti siltä että kyseessä on häviäjätallin kaakki?

 

Työkaluja:

Tarpeen pikadokumentointiin voit käyttää ohjelmiston visiolakanaa, ks. https://www.codento.fi/lataa-lean-visiolakana-ohjelmistoprojektiisi/

Lisää prosessien analysoinnista ks. https://www.codento.fi/2017/08/hyvaa-halvalla-nopeasti/

 

Lataa opas: Uuden verkkopalvelun teknologiavalinnat

Kuukausi Codentolla vei osaamisen vastalaidalle

Runsas kuukausi Codenton Cettu-laumassa on vienyt selkeästi mukavuusalueen ulkopuolelle, ja avannut uusia näköaloja omaan osaamiseen. Sosiokratia on kokeellista, mutta toimii tehokkaasti.

Eräänä päivänä keväällä headhunter lähestyi LinkedInissä, ja ehdotusta pohtiessa tuli fiilis, että saattaisin viihtyä jopa kokopäivätöissä, vaikka opinnot olivatkin vielä kesken. Somessa tuli samoihin aikoihin vastaan Codenton työpaikkailmoitus ja totesin, että tehtävän kuvaus osui aika hyvin omaan osaamiseen ja firmakin vaikuttaa kiinnostavalta, joten laitoin hakemuksen Codentolle.

Ennen kuin toisaalla oltiin päästy edes ensimmäiseen haastatteluun asti, minulla oli jo kädessä Codenton työtarjous. Firmasta jäi heti alkumetreiltä mukavan maanläheinen fiilis, jatkuva oppiminen ja pyrkimys fiksusti toimivaan organisaatioon tuntuivat heti omilta jutuilta. Haastattelussa jo oli sellainen olo, että tulen sopeutumaan hyvin, ja niin on tapahtunutkin.

Monessa mielessä Codentolla on ollut sellaista, mitä kuvittelinkin, ja monessa mielessä taas ei. Siinä mielessä odotukset ovat täyttyneet, että lähdin Codentolle hakemaan nimenomaan uusia ja erilaisia juttuja ja projekteja, ja niitä on tullut. Ja monet asiat, joista oli jotain kuvitelmia, ovat alkaneet tarkentumaan ja mustat läiskät täydentymaan.

 

Codentolla saa sanoa

Codentolla käytössä olevasta päätöksentekomallista, Sosiokratiasta, alan ymmärtämään ainakin sen, että en siitä kauheasti vielä ymmärrä. Näin siitä huolimatta, että olen jo fasilitoinut ensimmäisen viikkokokouksen. Mallin monimiutkaisuudesta huolimatta kuukauden aikana on kuitenkin syntynyt hyvä luottamus sen toimivuuteen. Sosiokratia on sen verran kokonainen järjestelmä, että todennäköisesti ongelmatilanteiden ilmaantuessa niitä on jo mietitty.

Ja hyvin, eikä niin, että on hieman sutaistu sinne päin, ja sitten oletetaan että asiat ovat yhtä ruusuilla tanssimista ja kaikki menee hyvin. Selkeästi mallia on toteutettu käytännössäkin ja ilmeisimmät sudenkuopat on jo löydetty ja voitettu.

Ehkä hienoin asia Codentolla onkin puhumisen kulttuuri. Esimerkiksi piirien kokoontumisissa tai viikkopalavereissa ihmiset ihan oikeasti toteavat, että hei, olen eri mieltä tästä, ei tämän näin pitäisi mennä. Vaikenemista, nyökyttelyä tai selän takana mutisemista ei ole, vaan kaikki uskaltavat ilmaista mielipiteensä ja myöskin käyttävät sitä uskallustaan. Codento on avoin organisaatio, muutenkin kuin paperilla.

 

Fronttiin pää edellä

Runsaan kuukauden aikana olen pääasiassa ollut projektissa, jossa asiakkaalla on kasa palvelimia, jotka tuottavat sisäistä palvelua, ja teemme visualisointia siitä, miten niitä on käytetty, mitä on mahdollista vielä tehdä, ja missä on ongelmakohtia. Sikäli ihan jännää, että frontti oli minulle täysin vierasta, ja nyt olen käytännössä koodannut pelkkää fronttia.

Domain-osaamisella on aika iso merkitys kuitenkin projektissa. Taustani on järjestelmäasiantuntija, joten saattaisin olla ihminen, joka käyttää kyseistä työkalua. Kun tietää, millaiset asiat olisi järkevä näyttää mitenkin, on siitä paljon apua ja tulee myös parempia ideoita, miten asiat kannattaisi tehdä.

Projekti on aika lailla toimistolta käsin tehtävä, ja asiakas luottaa, että teemme hyviä asioita. Kerran viikossa käymme asiakkaalla demoamassa, mitä olemme saaneet aikaiseksi. Tämä on ollut hyvä, koska näin on päässyt tutustumaan omaan toimistoon näin alkuunsa.

 

Missä mun esimies?

Eniten hämmennystä Codentolla on aiheuttanut keskijohdon puuttuminen kokonaan. Kukaan ei ole samassa mielessä vastuussa omasta tontistaan kuten perinteisessä esimiesmallissa. Tästä huolimatta asiat hoituvat ja päätöksiä syntyy – tavallaan kaikki tuntuvat kantavan vastuuta Codentolla.

Sosiokratia tuo itseohjautuvuutta, ja se näyttäisi toimivan tehokkaasti käytännössä siitä huolimatta, että ihmisiä on tullut lisää ihan viime viikkoinakin ja organisaatio kasvaa. Kun perinteisessä organisaatiosa monet asiat voivat jäädä ilman vastuuhenkilöä, Codentolla joku ottaa aina kopin.

Tulevaisuutta odotan suurella innolla ja uteliaisuudella; jos seuraava projekti onkin ihan eri mallinen ja asiakas haluaakin, että työ tehdään paikan päällä, on jännää nähdä, miten se toimii. Lähitulevaisuudessa on myös tiedossa konferenssimatka Open Source Summittiin Edinburghiin, mitä odotan todella paljon.

 

Katso Codenton avoimet työpaikat

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