Toiminnalliset ohjelmointirajapinnat laajentavat datakeskeistä maailmankuvaa

Updated: May 18, 2018


Avoimen datan liikehdintä on ohjannut ajatteluamme datan suuntaan. Tämän seurauksena maailmankuvamme kutistuu ja näkökenttä kaventuu. Julkiselle sektorille sopii hyvin data-rajapintojen tuottaminen - data annetaan kaikille (yksityisyydensuojaa kunnioittaen). Yritysten puolella toiminnalliset ohjelmistorajapinnat ovat suosiossa, koska suoraa pääsyä yksityiskohtaiseen dataan ei haluta antaa (liiketoiminnalliset syyt). Toiminnalliset API:t tarjoavat prosessoitua tietoa. Osittain omasta taustasta johtuen valitsin sovelluskehittäjän näkökulman, josta tarkastella datan hyödyntämistä



Avoimella datalla tarkoitetaan julkishallinnolle, organisaatioille, yrityksille tai yksityishenkilöille kertynyttä tietoa, joka on avattu organisaation ulkopuolisillekin vapaasti ja maksutta hyödynnettäväksi. Suomi keikkuu erilaisten mittaristojen kärkipäässä, Suomessa on muutamia tuotteistettuja avoimen datan portaaleja (kuten kansallinen avoindata.fi) ja asialle vihkiytynyt runsaslukuinen kansalaisaktivistiyhteisö.

Tällä vuosituhannella kaikki merkittävä kehitys tuntuu liittyvän dataan. Raaka, suodattamaton ja lajittelematon tieto, jota maapallon lukemattomat digitaaliset palvelut ja niiden käyttäjät tuottavat, on vuoron perään kiehtova ja pelottava asia. ( Ekonomi lehti)

Tässä kohdin Suomi on seurannut isompaa globaalia trendiä ja päässyt avoimen datan aallonharjalle julkisen sektorin vetämänä. Avaamisbuumin jälkeen syntyi tarve saada data myös käyttöön. Siinä on onnistuttu vaihtelevasti - enemmän odotettiin. Ekonomilehden juttu pisti minut ajattelemaan asiaa hieman enemmän. Datakeskeinen ajattelu tuntuu kaventavan näkökenttää, vähän kuin datahehkuttajilla olisi hevosen silmälaput puolittain aukinaisina päässä. Kaventunut näkökenttä on omiaan sulkemaan silmät vaihtoehdoilta ja mahdollisuuksilta.


Omassa työssäni APItalistina teen työtä ohjelmointirajapintoihin perustuvan API-talouden ja alustatalouden parissa auttaen yrityksiä alkuun ja vauhtiin API:en kanssa. Työssäni kohtaan paljon datan hyödyntäjiä eli kehittäjiä. Lisäksi autan kaupunkeja älykaupunkihankkeissa, jotka ovat Suomessa pari vuotta muuta Eurooppaa jäljessä. Sama koskee alustataloutta ja API-taloutta, mutta nämä ovat toisten kirjoituksien aiheita.


Osana satoja kehittäjäkohtaamisia olen keskustellut datan hyödyntämisestä ja niiden keskustelujen perusteella data-API keskeinen näkökulmani on laajentunut huomattavasti. Data ja dataa tarjoavat API:t ovat vain osa isoa palapeliä. Osittain näistä syistä valitsin sovelluskehittäjän näkökulman, josta tarkastella datan hyödyntämistä. Juttu tosin rönsyilee myös vähän asian ympärillä oleviin seikkoihin.


Tiedostopohjainen jakelu tarjoaa matalan kynnyksen dataan


Datan hyödyntäjien tarpeet ovat erilaisia ja niin ovat myös lähtökohdat datan hyödyntämiselle. Avoin data tiedostoina on tarjonnut muun muassa toimittajille dataa helposti kotikutoisilla menetelmillä hyödynnettävässä muodossa. CSV tiedosto löytyy avoimen datan portaalista ja se voidaan lukea muun muassa MS Exceliin tai Libre Officeen. Excel on laajasti käytössä ja sen peruskäyttö on tuttua monille. Datan hyödyntäjä ei tarvitse uusia työkaluja tai opetella juurikaan uusia taitoja "louhiakseen" datasta graafeja ja poikkeavuuksia, joista sitten kirjoitella lehtiin ja blogeihin.


Datan tarjoaminen ohjelmointirajapinnan (API) kautta


Suurimman avausbuumin jälkeen alkoi nousemaan keskusteluun ohjelmointirajapinnat. Iso rooli tässä oli muun muassa 2014 perustetulla API:Suomi -yhteisöllä, josta myöhemmin spinnasi (2015) APIOps® -yhteisö, joka keskittyy API:en arvoketjun standardeihin pohjautuvaan automatisointiin.

Löydettiin uusi tapa jakaa avointa tietoa - eläköön data-API

Löydettiin uusi tapa jakaa avointa tietoa - eläköön data-API. Kynnys käyttää API:a datan lähteenä on kuitenkin suurempi kuin tiedostojen. Hyödyntäjällä pitää olla vähintäänkin alkeellinen osaaminen ohjelmoinnista ja datan visualisoinnista. Kohdeyleisö kaventuu murto-osaan siitä mikä saavutetaan tiedostoilla.


Dynaamisempi datan hyödyntäminen API:en avulla


API:t ovat kuitenkin (parhaimmillaan) dynaamisempi tapa hyötykäyttää dataa. API:n avulla voidaan ladata vain se osa datamassasta, joka on olennaista sovelluksen toiminnalle. Jos kehittäjä tarvitsee vain tietyn organisaation yhteystiedot, miksi hänen pitäisi ladata 2 gigatavun CSV tiedosto? Lisäksi data haetaan sillä hetkellä kun se sovelluksessa tarvitaan. Tavoitteena on että dataa ei tarvitse sulloa omaan tietovarantoon. Todellisuudessa näin ei ole kuitenkaan käynyt. Sen sijaan sovelluskehittäjät hakevat ohjelmointirajapinnasta datan ja säilövät sen oman sovelluksen sisään ennen hyötykäyttöä. Miksi? Syitä on monia, mutta tässä muutama keskusteluissa esiinnoussut:

  1. heikko luottamus data-API:n toimintaan,

  2. tehokkuus sukkaa,

  3. pysyvyys (onko olemassa ensi viikolla, koska ei SLA:ta?),

  4. huono kehittäjäkokemus (API on kömpelö ja vaikea tai hidas ottaa käyttöön)

API:n luotettavuus on iso asia sovelluskehittäjän näkökulmasta. Jos API ei ole tehokas, se hidastaa loppukuluttajalle tuotettavaa palvelua. Jos API ei toimi, se saattaa estää palvelun toiminnan. Kummassakin tapauksessa sovelluksen kehittäjä saa niskaansa syyttelyn ja someraivon, ei API:n tarjoaja.

Sovelluksen kehittäjä saa niskaansa syyttelyn ja someraivon, ei API:n tarjoaja

Toisinaan markkinatarvetta ei ole kartoitettu ja tuotetaan API, vaikka suurempi tarve on tiedostojakelulle. Näin on käynyt muun muassa PRH:n yritystietoja tarjoavan API:n kohdalla. API on ja sitä voi käyttää vapaasti (tietyin rajoituksin). Tarve on kuitenkin ollut tiedostolle, jossa tieto on kerättynä yhteen. Seurauksena oli se, että kansalaisaktivistit tekivät skriptin, joka haki rajapinnasta tiedot ja koosti tiedoston yritysten käyttöön. Ilman aktivisteja ei olisi nyt täytetty markkinoilla syntynyttä tarvetta.


Lisäarvo loppukuluttajalle moninkertaistuu usean datalähteen avulla


Yhden datalähteen päälle rakennettu palvelu tuottaa jo lisäarvoa loppukuluttajalle. Tästä esimerkkinä erilaiset bussien reaaliaikaista sijaintia ilmaisevat sovellukset kuten esimerkiksi nyssetutka.fi, joka pesee mennen tullen käytettävyydessä julkisen sektorin tuottamat vastaavat palvelut.



Todellisuudessa vasta usean datalähteen käyttö ja tietojen yhdistäminen tuottaa merkittävästi lisäarvoa. Tästä lienee tuorein ja tunnetuin esimerkki vainu.io -palvelu.

Vainu on yli 1000 organisaation hyödyntämä ratkaisu prospektointiin ja liidien generointiin. Keräämme avointa ja julkista dataa miljoonista lähteistä yli 70 miljoonan yrityksen tietokantaamme, minkä ansiosta löydämme ne yritykset, joilla on todellinen tarve palvelullesi.

Dataputkien tuottajan rooli sopii julkiselle sektorille


Datan tarjoaminen ohjelmistorajapintojen kautta on omiaan julkiselle sektorille. Heillä ei ole business syitä estää pääsyä dataan ja palveluiden tuottaminen on maksettu verovaroin. Julkisen sektorin kiimaa rakentaa REST/JSON ohjelmointirajapintoja on (onneksi?) hillinnyt tilanne, jossa kansallinen palveluväylä perustuu SOAP teknologiaan ja muualla default on tehdä REST/JSON tyylisesti. Julkisen sektorin organisaatioiden välillä tulee käyttää SOAP teknologiaa, mutta ympärillä oleva yhteiskunta elää REST aikaa.


API:n laatu on korkeampi, jos organisaatio itse käyttää sitä ("Eat your own dog food"). Silloin motivaatio pitää laatu kohdallaan on suurempi. Miten tämä tulee toteutumaan julkisella sektorilla, jos kansallisella tasolla pitää olla SOAP, mutta muut haluavat REST? X-Road kokonaisuus toki sisältää mahdollisuuden käyttää REST Gatewayta, joka on tehty Viro-Suomi yhteistyössä. Syystä tai toisesta sitä ei kuitenkaan ole tietääkseni laajemmin testattu saati otettu käyttöön.


Toisessa ääripäässä on HSL, joka käyttää GraphQL teknologiaa tuotantopalvelussa. Voisi sanoa, että julkisella sektorilla on usean kerroksen väkeä. Alakerta elää vuosituhannen vaihdetta ja Penthouse kerros soveltaa viimeisintä teknologiaa. Välissä olevat sitten jotain siltä väliltä - ja saattaa osa olla vielä kellarissakin.

Julkisen sektorin organisaatioiden välillä tulee käyttää SOAP teknologiaa, mutta ympärillä oleva yhteiskunta elää REST aikaa.

Yritysten kohdalla tilanne on toinen. Heillä ei monestikaan ole mitään intressiä avata "rööriä" suoraan yksityiskohtaiseen dataan. Tästä päästäänkin otsikossa mainittuihin toiminnallisiin ohjelmointirajapintoihin.


Datan hyötykäyttö on vain osa sovelluksen kehittämistä


Osana sovelluksen kehitystä luetaan dataa joko tiedostoista tai ohjelmointirajapinnoista. Näin homma menee karkealla tasolla. Kuitenkin tuo on vain pieni osa sovelluksen kehittämistä. Loppuasiakkaalle menevä palvelu sisältää erilaisia toimintoja kuten tunnistus ja monta muuta asiaa.


Ennen API:en voittokulkua jokainen kehittäjä toteutti kaikki toiminnot datan käsittelystä käyttäjän tunnistamiseen itse joko copy-pasteamalla koodin tai tuottamalla koodin itse kokonaan. Avoin lähdekoodi poisti osan tarpeesta tehdä kaikki aina tyhjästä. Nyt ollaan jo hetken otettu seuraavaa askelta - toiminnallisuus palveluna API:n kautta tarjottuna. Tässä kohdin pitää muistaa sitten sekin riski että API saattaa yhtenä päivänä kadota tai ehdot muuttuvat epäedullisiksi. Oikeastaan tämä pitää ottaa olettamukseksi. Näin ollen kyse on riskienhallinnasta - teenkö businesskriittisen toiminnon 3. osapuolen API:lla vai en? Avoimella lähdekoodilla kesti pari vuosikymmentä päästäkseen mainstreamiin, toivottavasti sama ei ole edessä toiminto-API:en kanssa.


Toiminnallisen rajapinnan esimerkit ovat todellisuutta jo nyt. Otetaan pari esimerkkiä. Karttapalvelua erilaisilla lisukkeilla kuten liikennetiedot, kohteet, säätiedot yms tarjoaa monikin palveluntuottaja muutaman mainitakseni Amazon, Google ja Here. Käyttäjän tunnistamisessa julkinen sektori on toteuttanut vahvan tunnistuksen palvelun (käyttö ei kaikille mahdollista) ja opetus- ja kulttuuriministeriö puolestaan on tehnyt avoimen lähdekoodin MPASS.id tunnistuspalvelun esiopetus-peruskoulu-lukio akselille vapaasti hyödynnettäväksi riippumatta sektorista. Google Maps Geolocation API palauttaa laitteen sijaintitiedon. Vastaavia palveluita on muillakin.


Se mitä ei vielä ole suuremmin tehty Suomessa on laajemman datan hyödyntäminen toiminnallisen API:n takana. Tästäkin toki löytyy esimerkkejä ja yksi helposti ymmärrettävä tuotteistettu toiminnallinen API on F-Securen F-Secure Security Cloud API for URLs. Kyseinen API tarjoaa ohjelmallisesti helpon ja nopean keinon tarkistaa web-osoitteiden (URL) riskit sisällön tai turvallisuuden suhteen.

With the F-Secure Security Cloud API for URLs, you can determine the safety and content categories of URLs, which helps you to prevent end-users from accessing URLs that lead to harmful sites (for example, malware, phishing, or exploits) or sites that are defined as inappropriate (for example, gambling, hate, or adult).

Ei tarvitse olla kovinkaan älykäs ymmärtääkseen, että API:n takana on ohjelmisto, joka käyttää hyväkseen suurta datamassaa, jonka F-Secure omistaa ja johon he eivät halua päästää ketään suoraan käsiksi. Pidemmän päälle kyse on siitä, kuka tekee toiminnalliset rajapinnat ja tapahtuuko algoritmipohjainen datan louhinta palomuurin sisä vai ulkopuolella. Aika näyttää.

Dataa itsessään ei kaupallisteta, vaan sen päälle tehdyt toiminnalliset rajapinnat.

Lähtökohtaisesti yritys ei päästä muita "datapadan" ääreen suoraan. Toki tätäkin tapahtuu ja silloin puhutaan kumppanirajapinnoista, joissa yritys A avaa data-rajapinnan yritykselle B omaan järjestelmäänsä sitouttaakseen toinen yrityksen itseensä tai avatakseen uusia markkinoita. Tämäkin tosin vaatii sopimuksia ja on hiukan jäykkää eikä sovellu kaikkiin tapauksiin. Suoran pääsyn avaamisen sijaan F-Secure on rakentanut datan päälle toiminnallisen tuotteistetun API:n. API:n avulla sovelluksentekijä voi muutamalla koodirivillä parantaa loppukuluttajan turvallisuutta ja käyttökokemusta.

Data API:n avaamisen sijasta F-Secure on rakentanut datan päälle toiminnallisen tuotteistetun API:n.

Tässä onkin jutun juoni. Ei koodata itse, vaan ostetaan palveluna osa sovelluksen logiikkaa ja toiminnallisuutta. Tämä puolestaan helpottaa sovelluksen kehittämistä, todennäköisesti nostaa sovelluksen laatua ja mikä tärkeintä mahdollistaa nopeamman markkinoille pääsyn uuden tuotteen kanssa. Jotkut API -tarjoajat ovat päättäneet helpottaa API:n käyttöönottoa tarjoamalla SDK:t eri ohjelmointikielillä.


Data-API on siitäkin veikeä, että monesti sen kohdalla voi puhua datalukosta. Joku sen datan päällä organisaationa kuitenkin istuu monesti ja he kontrolloivat miten ja mitä tarjotaan ulos. Näin ollen on erittäin haastavaa kilpailla tarjoamalla toinen data-API, vaikka sen kehittäjäkokemus olisi viimeisen päälle hyvä. Toiminnallisten ohjelmointirajapintojen kohdalla tilanne on toinen ja kilpailu on helpompaa.


Avaintekijä on ymmärtää, että tehokkaassa sovelluskehityksessä data-API:t eivät riitä, tarvitaan toiminnallisia ohjelmointirajapintoja. Joskus hyvä kehittäjäkokemus mahdollistuu tiedostopohjaisella jakelulla API:n sijasta. Lisäksi on olennaista API:en kohdalla ymmärtää kehittäjäkokemuksen avainrooli siinä otetaanko API käyttöön vai ei. Kilpailu kovenee erityisesti toiminnallisten API:en kohdalla ja matalamman kynnyksen API valitaan vaikka sen hinta saattaisi olla korkeampi. Nopeus on valttia.

Kilpailu kovenee erityisesti toiminnallisten API:en kohdalla ja matalamman kynnyksen API valitaan vaikka sen hinta saattaisi olla korkeampi.

Tarjoa kokeilumahdollisuus - 3x enemmän myyntiä

Kilpailusta puhuttaessa on syytä mainita ilmaiskerroksen vaikutus myyntiin. API:t, joilla on tarjolla ns free tier, saavat maksavia asiakkaita 3x todennäköisemmin. Tämä johtuu siitä, että kehittäjät haluavat kokeilla ohjelmointirajapintaa ensin ja tehdä päätöksen sen jälkeen eikä ostaa sikaa säkissä.

Developers are 3x more likely to subscribe to a paid API with a free tier ( nordicapis.com)


Mydata eli omadata uutena tulokkaana


Mydata eli omadata tulee sekoittamaan yllä mainittua pyhää kolminaisuutta: tiedostopohjainen jakelu, avoimet ohjelmointirajapinnat ja toiminnalliset API:t. En ole omadatan asiantuntija, joten kovin syvällisiä spekulaatioita en lähde tekemään. Osa omadatasta tulee varmastikin olemaan tiedostojenjakeluun perustuvaa eikä aina vain API. Omadata saattanee olla kaupanteonväline tulevaisuudessa.


Muutama kysymys tulee heti mieleen? Halutaanko aina päästää 3.osapuoli omadataan suoraan vai onko tarvetta rakentaa toiminnallisia ohjelmointirajapintoja väliin suodottamaan dataa? Mikä on suunniteltujen dataoperaattorien rooli tässä?

0 views

©2018 by apitalisti
 

Yhteystiedot

Brändit

Apitalist is registered trademark of APInf Ltd

APIOps is registered trademark of Osaango Ltd and APInf Ltd

Tilaa kirja

API -talous 101 -kirja Alma Talent kaupassa!

Podcast

"Opi tuntemaan API -asiakkaasi" podcast -sarja

Lue lisää!