Kurkistus API Economy 101 kirjaan

15. heinäkuuta 2019

Kurkistus API Economy 101 -kirjaan

Jos kirja olisi API ja kustantaja olisi alusta...

Kirjoja on painettu kirjapainoissa vuodesta 1455. Siitä lähtien kustantamo-liiketoimintaa on harjoitettu “putkimallilla”: kirjailijat kirjoittavat, kustantajat julkaisevat ja jakelevat, kirjapainot painavat ja kirjakaupat myyvät.

Digitalisaatio, alustatalous ja ohjelmointirajapinnat ovat muuttaneet kirjoihin liittyviä liiketoimintamalleja ja arvovirtoja. Muutos alkoi e-kirjoista ja niiden lukulaitteista. Esimerkiksi kirja-alustat, kuten lulu.com tai BoD.fi, rakentuvat sekä omista että muiden yritysten rajapinnoista.

“Alustakirjailija” julkaisee teoksensa täysin ilmaiseksi omakustanteena. Alustan kautta kirja levitetään koti- ja ulkomaisten verkko- ja kivijalkakauppojen kirjallisuusluetteloihin e-kirjana tai printtinä. Kirjoja tulostetaan automaattisesti ja vain tilauksesta. Ainoastaan myydyistä kirjoista peritään myyntiprovisio.

Alusta tarjoaa lisäarvoa: Kirjailijoille jää suurempi osuus liikevaihdosta ja he saavat itse päättää sisällön ja hinnoittelun. Lukijat nauttivat laajemmasta tarjonnasta ja edullisemmista hinnoista. Kumppanit voivat julkaista kirjasarjoja täysin automatisoidusti.

Liiketoimintamallin muutos on merkittävä ja rajapintojen mahdollistama. Kirja-alusta tyypillisesti muiden rajapintoja mm. ISBN-numeron ja EAN-koodin luomiseen, digitaaliseen painoon [ii] ja kirjojen julkaisuun verkkokauppa-alustoille. Pisimmälle vietynä koko kirja voidaan tarjota rajapinnan kautta, ennustaa Pressbooks-alustan perustaja Hugh McGuire. [iii]

“Ei me näillä rajapinta-asioilla liiketoimintaa vaivata”

Yritysten API-palaverit ovat tietohallinnon yksityisiä keskusteluja IT-arkkitehtuurista ja niihin pyydetään paikalle vain teknisesti lahjakkaita konsultteja. API-konsultin kyljessä tulisi olla varoitustarra “Saattaa muuttaa liiketoimintamalliasi”. API on organisaatiosi oma digitaalinen, myytävä palvelutuote, toisaalta se on myös hyödyke, jonka voit ostaa. Se voi myös olla tapa säästää rahaa ja aikaa tai parantaa tietoteknisen ympäristön kuntoa tai yksinkertaisesti olla pakollinen osa digitaalisen asiakaskokemuksen rakentamista. Nämä kaikki liittyvät yrityksen liiketoimintamalliin. Se määrittää miten arvoa luodaan, kuinka sitä jaetaan, ja millaisella yhdistelmällä toimintoja, resursseja ja osaamisia arvo syntyy. On vielä paljon yrityksiä, joissa asia kuitataan lyhyesti: “Ei me näillä rajapinta-asioilla liiketoimintaa vaivata”.

Tietohallinnon ulkopuolisille API on aluksi vaikea tekninen asia ja menee yllättävän helposti sekaisin “appin” eli sovelluksen kanssa.[iv] Teknologia ei ole sama asia kuin liiketoimintamalli, mutta teknologia vaikuttaa olennaisesti liiketoimintamallin toteutuskelpoisuuteen. Vältetään siis teknistä retoriikkaa ja suunnistetaan liiketoimintapotentiaalin mukaan.

Luvun alussa esitetyn kustannusalan lisäksi tutustutaan jokaista kuluttajaa lähellä olevaa vähittäiskaupan alaan ja sen suhtautumiseen rajapintoihin ja alustatalouteen: Perehdytään Keskon esimerkkiin, sivutaan hieman SOKia ja päädytään Alibaban rajapintoja tarjoavaan alustaan - niin voimakkaaseen vetovoimaan, että jopa Kesko on päättänyt liittyä siihen.

Pohdimme Nordean ja Liikenneministeriön avulla pankki- ja liikennealoja. Erityisesti syvennytään vaikutuksiin, jotka yhteiskunnan käynnistämillä ekosysteemeillä ja rajapintoja edellyttävällä lainsäädännöllä on yritysten liiketoimintamalleihin ja toimintaedellytyksiin. Tuottaako pakolla käynnistetty vuorovaikutus uusia alustainnovaatioita ja asiakaslähtöisyyttä?

Nykyään moni yritys alkaa muistuttaa yhä enemmän teknologiayritystä. Marjukka työskenteli Keskolla API-kehittämispäällikkönä ja vitsaili kollegan kanssa loppuvuodesta 2016, milloin Keskon johto ymmärtää johtavansa teknologiayritystä vähittäis- ja tukkukaupan sijaan. Parin kuukauden päästä saimme vastauksen Twitteristä: pääjohtaja Helanderilta oli Pariisin Retail-messuilla kysytty, tietääkö hän vetävänsä yhtä Euroopan suurimmista teknologiayrityksistä?

Vuoden 2016 lopulla API-kehitys oli juuri lähtenyt vauhtiin ja osaltaan sen tukemana digitaalisia palveluita syntyi enemmän kuin kukaan ehti laskea. [v] Ruokapuolen palveluissa oli jo otettu API-arkkitehtuuria käyttöön ja K-Raudan uudet asiakaslähtöiset liiketoimintamallit saatiin muutamissa kuukausissa verkkokauppaan kehitystä ja erityisesti testausta nopeuttaneen API-kehityksen siivittämänä. Rakentajan ja remontoijan asiakaskokemus parantui huomattavasti, kun uutta kiuasta ei tarvinnut enää etsiä koluamalla K-Rautoja yksi kerrallaan, vaan palvelu ja sen taustalla olevat APIt hakivat lähimmät kaupat, joista haluttua kiuasta oli saatavana ja laskivatpa vielä hinnan kotiinkuljetuksellekin. Samaisia rajapintoja voitiin käyttää myös eri kanavissa, mm. kivijalkaliikkeiden mainos- ja hintanäytöissä sekä erilaisissa sovelluksissa, myös kumppaneiden kehittämissä. [vi]

API- vai alustataloutta?

API voi olla osa yrityksen liiketoimintamallia monella tapaa. Se voi olla yksi osa yrityksen tarjontaa, tai yritys voi tarjota pelkkiä rajapintoja. API voi olla tapa kommunikoida asiakkaiden ja kumppaneiden kanssa tai tapa parantaa tiedon laatua ja vähentää kustannuksia yrityksen eri palveluissa ja järjestelmissä. Parhaimmillaan API voi olla keskeinen vetovoimatekijä, joka tuo toimijoita ekosysteemiin ja sen käytössä olevalle alustalle. Useimmissa vähittäis- ja tukkukauppatoimialojen tapauksissa tuotteiden valmistajat ja muut potentiaaliset kumppanit, erityisesti suuret asiakkaat ovat kiinnostuneimpia ostohistoriasta ja sen analysoinnista.

Entä sitten tilausrajapinnat? Kenelle kannattaa antaa tilausmahdollisuus rajapintojen kautta? Onko kanava ja brändi niin arvokas, ettei sitä kannata luottaa muille? Keskolla ja muilla suomalaisilla vähittäiskaupan toimijoilla vastaus on ollut tähän syksyyn mennessä pitkälti epävarma “ehkä”, jos asiaa on edes mietitty.

Esimerkiksi S-ryhmä ilmoitti syksyllä 2017 rakentavansa API-kerroksen. Syiksi ilmoitettiin sekä tekninen velka että digitaalisten palveluiden rakentaminen, ei niinkään rajapintojen tarjoaminen suoraan esimerkiksi kumppaneille tai asiakkaille. S-ryhmä on kuitenkin ulkoistanut osan alusta- ja rajapintakehityksestään 2010 sopimallaan yhteistyöllä Digital Foodie Oy:n kanssa. Alusta osoittautui riittävän voittoisaksi tuotesuosittelukyvykkyyksiensä osalta, joten vuonna 2016 kyseisen alusta myytiin amerikkalaisille. Digital Foodie tarjoaa rajapintoja, mutta kertoo niistä vain kumppaneilleen, internetistä tietoa on turha etsiä.

Markkinat hämmästyivät hetkeksi syyskuussa 2017 Keskon ryhdyttyä kanavakumppaniksi kiinalaiselle Alibaballe. [x] Tässä harjoituksessa lienee hyödynnetty Alibaban alusta -liiketoimintamallia ja sen suhteellisen hyvin tuotteistettuja, julkisesti dokumentoituja (vrt. Digital Foodie) rajapintoja, joilla tuotteiden tarjoajat voivat asettaa tuotteitaan myyntiin Alibaban verkkokauppa-alustalle. [xi] Alibaba onkin samankaltaista liiketoimintamallia harjoittavan Amazonin ohella kohonnut yhdeksi suurimmista verkkokaupoista.

Samaan aikaan kun Suomessa on ihmetelty suomalaisten kauppojen ja etenkin verkkokauppojen haasteita, [xii] ovat monet ulkomaiset toimijat pystyneet luomaan kattavan ja nopealla tahdilla kasvavan ja muuttuvan verkkokaupan usein juuri rajapintojen ja muun kauppiaiden ja tavarantoimittajien käyttökokemukseen liittyvän kehityksen avulla, toki asiakkaiden ostokokemuksen räätälöintiä ja tilausprosessin yksinkertaistamista unohtamatta.

Kilpailutilanteessa ei aina ole selvää mihin suuntaan liiketoimintamallia pitäisi muuttaa tai miksi. Usein yrityksillä ei ole täyttä mahdollisuutta vaikuttaa omiin malleihinsa. Liiketoimintaan kohdistuu rajoituksia tai vaatimuksia, jotka vähentävät yritysten valinnanvapautta. ​ Jatkuva kaikkien osapuolten välinen kilpailu ainoastaan hinnalla on lyhytnäköistä ja ajaa yritykset mahdottomiin tilanteisiin. Entä jos nurkan takaa tuleekin täysin eri alan toimija alustoineen aivan eri arvolupauksella ja häiriköi markkinoita? Tai jos lainsäädäntö muuttuu niin, että erottavasta tekijästä tuleekin kaikille pakollinen vaatimus. Näin kävi mm. pankkialalla PSD2 -direktiivin myötä kun pankit pakotettiin avaamaan rajapintansa muille toimijoille. Tai liikennealalle, kun liikenne- ja viestintäministeriö edellyttää avaamaan lippurajapinnat.

Liikennevirasto esittelee lippu-rajapintoihin liittyvän hankkeen tavoitteita näin: “Digitalisaation myötä liikkuminenkin muuttuu palveluksi (MaaS, Mobility as a Service). Liikkuminen palveluna on laaja kokonaisuus, johon Lippu-hankkeessa käsiteltävät matkaketjut liittyvät pienenä, mutta olennaisena osana. Asiakkaan kannalta matkaketjumalli helpottaa matkojen suunnittelua ja säästää aikaa. Tulevaisuudessa yhä useampia palveluita, myös muita kuin liikkumispalveluita, kootaan asiakkaille tarjottaviksi palvelupaketeiksi. Kokonaisten palvelupakettien tarjoaminen asiakkaille lisää palveluiden houkuttavuutta ja tuo sitä kautta lisää asiakkaita kaikille paketeissa mukana oleville palveluntarjoajille.” [xiii]

Alkavatko kaikki todellakin myymään toistensa lippuja, vai tuleeko alalle lähinnä välittäjiä, jotka välittävät eri toimijoiden lippuja. Entä mitä tapahtuu asiakaskokemukselle ja hinnoille? Helsingin seudulla on aloittanut toimintansa Whim, joka yhdistää eri liikennemuotoja julkisista takseihin, kiinteällä kuukausihinnalla. Liikennealan toimijat joutuvat siis sekä kilpailemaan omaa brändiään ja asiakaskokemustaan tukevilla sovelluksillaan ja käsittelemään nämä välittäjäpalvelut sekä kumppaneina että kilpailijoina.

Rajapintojen kautta jopa suorat kilpailijat voivat ainakin teoriassa tarjota asiakkailleen yhtenäisempää asiakaskokemusta myymällä toistensa lippuja, mutta ryhtyvätkö ne todella tekemään niin? Esimerkiksi taksialalla loistavan alun saanut Valopilkku-sovellus on nyt kärsimässä kilpailusta, kun taksialan vapautuminen on pakottanut myös taksit miettimään missä verkostoissa ne toimivat ja esimerkiksi Helsingin taksi on kehittänyt oman sovelluksensa ja luopunut Valopilkun käytöstä. Selvennettäköön, että siellä missä on mobiilisovelluksia, on myös yleensä aina API ja sitä voidaan myös yleensä (hyvin suunniteltuina) hyödyntää useampaan käyttötarkoitukseen.

Yhteistä sekä pankkialan että liikkumisen rajapintoja koskeville “pakkoavauksille” on se, että julkinen sektori määrää avaamaan rajapinnat, muttei rajoita toteutusta. Liikenneviraston hankkeessa suosituksia on huomattavasti enemmän kuin pankkialalla. Onko tämä kehittäjien heitteillejättö sittenkään hyvä asia?

Suurin osa pohjoismaissa toimivien pankkien rajapinnoista ei ole erityisen käyttäjäystävällisesti suunniteltuja, eli kehittäjäkokemus on huono ja vähentää siten APIn käyttöä ja yrityksen vetovoimaa kumppaniverkostossa. Toteutuuko PSD2 -direktiivin henki, elleivät muut yritykset halua tai käytännössä pysty toteuttamaan omia sovelluksiaan heikosti suunniteltuja tai dokumentoituja rajapintoja vasten?

Mikä oikeastaan on julkisesti määrättyjen rajapinta-avausten merkitys yrityksille ja niiden liiketoimintamalleille? Esimerkiksi Nordea -pankki on julkisesti ilmaissut näkevänsä rajapintojen avauksen itselleen liiketoimintamahdollisuutena, haluavansa tehdä sen mahdollisimman hyvin ja lähtenyt hakemaan kehittäjäyhteisöjä: “PSD2 ajaa pankkeja avaamaan rajapintojaan ja dataa kolmansille osapuolille,” Jarkko Turunen, Nordean avoimen pankkitoiminnan vetäjä kertoi Computer Weeklylle. “Näemme tämän kuitenkin Nordeassa laajempana mahdollisuutena ja aiomme avata jatkossa yhä enemmän palveluita. Nordea toivoo, että avoimen pankkitoiminnan sivusto antaa sille mahdollisuuden hyötyä PSD2-direktiivistä ja tulla pankki-APIen oletusyhteisö Pohjoismaissa.”

Kaikissa lainsäädäntömuutoksissa ja muissa toimintaympäristöä laajasti koettelevissa muutoksissa piilee yleensä mahdollisuus kääntää muutos oman yritysten kannalta kilpailueduksi, tosin se saattaa vaatia aikaisin liikkeellä oloa, minimivaatimusten ylittämistä sekä rohkeutta.

Myös kansainvälisesti pankkisektorilla eri toimijat ovat valmistautuneet rajapintojen avauksiin. Open Banking eli avoin pankkitoiminta onkin koko kansainvälisen pankkialan huulilla. Ei ole selviö, että asiakaskunta haluaa vaikkapa Facebookin pääsevän käsiksi pankkitilinsä saldoon, mutta se voi olla vain alkusoittoa. Lainsäädäntö voi myös estää rajapintojen avaamista tai niiden käyttöä eri toimijoiden välillä. Avoin dialogi julkisen ja yksityisen sektorin välillä on välttämättömyys liiketoimintamahdollisuuksien turvaamiseksi.

Tuoreimpia esimerkkejä kirjan kirjoitushetkellä oli Kanadan pankkien vaatimus ettei PSD2 -hypessä aiheutettaisi turhia tietoturvariskejä ja toisaalta, että lainsäädännön vuoksi pankit eivät voi toimia fintech-yritysten kanssa yhteistyössä vaikka rajapintoja olisikin tarjolla. [xv] Pankit ovat huolissaan kilpailun vääristymisestä koska fintech-startupit voivat kääntyä tuotekehitysideoineen pääomasijoitusyritysten puoleen.

Yhteenveto

  • Rajapinnat ovat teknologia, joka vaikuttaa liiketoimintamalleihin
  • Rajapintoja hallinnoimaan tarvitaan koko yritys
  • API mahdollistaa vuorovaikutuksen alustatalouden toimijoiden kanssa
  • Rajapintojen “pakkoavaus” saattaa kohdata liiketoimintamallisi milloin tahansa, näe se mahdollisuutena
  • Jos kilpailijasi tarjoavat (tai ovat pakotettu tarjoamaan) rajapintoja, on voittava kehittäjäkokemus rajapintojen käyttöönotossa merkittävä kilpailutekijä

Mitä API-talous 101 -kirja sisältää?

Osa I: Liikkeelle liiketoiminnasta

1 VAROITUS: API-talous saattaa muuttaa liiketoimintamalliasi

  • Jos kirja olisi API ja kustantaja olisi alusta
  • ”Ei me näillä rajapinta-asioilla liiketoimintaa vaivata”
  • API- vai alustataloutta?
  • Yhteenveto

2 Arvon APIkin ansaitsee - lisäarvoa APIsta

  • Lisäarvo on kokemus
  • Lisäarvon palaset
  • API välineenä lisäarvoon
  • Yhteenveto

3 APIt ekosysteemissä

  • Ekosysteemit ovat digitaalisen liiketoiminnan uusi kivijalka
  • Rajapinnat globaaleina portteina
  • Yhteenveto

4 Alustan vetovoiman lait

  • Arvo syntyy vuorovaikutuksesta
  • Miksi liiketoimintamallit muuttuvat?
  • API-talous alustatalouden airueena
  • Yhteenveto

5 API – Tuote, palvelu tai jotain ihan muuta?

  • ”Sisältää myös APIn”
  • Resurssikeskeinen API-maailmankuva
  • Yhteenveto

6 Liiketoimintamallit APIsta alustaan

  • Muut liiketoimintamallin kriittiset osa-alueet
  • Paras liiketoimintamalli minulle?
  • Kuka on asiakkaasi, mikä on tarjoomasi ja miten sen tuotat?
  • Yhteenveto

OSA II: RAjapintaa rajoitetusti saatavilla

7 Nautitaan sisäisesti - Internal ja Private APIt

  • Tietomallien tuskaa
  • Missä sisäinen API sijaitsee, ja kuka sitä käyttää?
  • Onko sisäisellä APIlla tulevaisuutta?
  • Yhteenveto

8 Kumppaninuuden tähden - Partner API

  • Astu API-talouteen kumppanuuksien kautta
  • Kenen kanssa kumppaniksi?
  • APIt helpottavat kumppaniverkoston laajentamista
  • Muut tekevät myynnin sinun puolestasi
  • Palveluliiketoimintaa projektien sijasta
  • Kumppani-APIt avaavat pääsyn uusille markkinoille
  • Joku toinen on jo ratkaissut ongelman
  • Lisää laitemyyntiä ja parempi asiakaskokemus
  • Entäs sitten kun API on tehty?
  • Mitä kumppani-APIn jälkeen?
  • Yhteenveto

9 Myös ulkoiseen käyttöön - Public API

  • Julkisen APIn liiketoimintamahdollisuudet
  • Avoin julkinen hallinto
  • Avoimen datan API
  • Avoimen datan APIn liiketoimintamahdollisuudet
  • Yhteenveto

10 Hyödyntäjäyhteisö asiakkaana

  • Sytytä intohimo ja luovuus
  • Innovaattoreista perässähiihtäjiin
  • Ymmärrä kehittäjän elämää ja arkea
  • Kuin sipulin kerrokset APIn ympärillä
  • Kehittäjät ovat laiskoja ja aika on kallista
  • Laajentuva kehittäjäyhteisö
  • Yhteenveto

OSA III : Aloita kevyesti kokeilemalla

11 APIt muuttavat organisaatiotasi

  • APIt muuttavat muutakin kuin tietohallintoa
  • Johdata organisaatiosi muutokseen
  • Aito esimerkki suuren yrityksen muutoksesta
  • Ei APIa ilman ketteriä menetelmiä
  • Yhteenveto

12 Kohtaamisia Canvaksen äärellä

  • Arvolupauksesta liiketoimintamalliin
  • Kokeiltu käytännössä
  • Yhteenveto

13 Aloita kevyesti kokeilemalla

  • Hahmota iso kuva
  • Pienin lisäarvoa tuottava tuote
  • Vakiinnuta julkisivu
  • Rajapintakokeilujen jälkeen alkaa infrastruktuurin kokeilu
  • Suunnittele elinkaari ennen julkaisua
  • Yhteenveto

14 Tyyli ennen kaikkea - API design guide

  • Standardit rajapinnat
  • API-tyylioppaan merkitys APIen kehityksessä
  • Evaluoikaa ja validoikaa APIn muotoilu
  • Muotoile, testaa, arvioi – toista alusta
  • Käytä standardeja
  • Kiihkeimmän kehityksen jälkeinen arki
  • Yhteenveto

15 Auditoi APIsi

  • Tietoturvaa vai määräysten mukaisuutta?
  • Käytettävyystestaus kuuluu myös APIlle
  • Ostatko vai peritkö APIn?
  • Yhteenveto

16 Kehittäjäkokemus on uusi musta

  • Rajapinnat joihin rakastutaan
  • Asiakaspolku yhteisenä narratiivina
  • Kehittäjäkokemus ei ole vain tekniikkaa
  • Hyvä kehittäjäkokemus on osiensa summa
  • Arvon luonti
  • Matala kynnys
  • Ajantasainen ja kattava dokumentaatio
  • Kun en löydä mitä tarvitsen ...
  • Jatkuva kehittäminen
  • Yhteenveto

17 Julkaise nopeasti, tue, mittaa ja opi

  • Julkaise ensimmäinen versio APIsta nopeasti
  • Rakenna kokonaiskuva mittariston avulla
  • APIt ja DevOps täydentävät toisiaan
  • Yhteenveto

OSA IV: Hallitse rajapintasi

18 Paljasta rajapintaa

  • Voiko APIa olla ilman API-hallintaa?
  • Hajautettua API-hallintaa suuryrityksessä
  • Yhteenveto

19 Hajauta ja hallinnoi

  • Tarvitseeko API aina mikropalveluita?
  • Vanhakin jo nuortuu
  • Yhteenveto

20 Identiteettikriisi

  • Oikealla pääsynhallinnalla on väliä
  • Onko identiteettisi sähköpostin varassa?
  • Yhteenveto


Loppusanat

Sanasto

Viittaukset

Hanki kirja itsellesi

Viittaukset:

[i] Tämän jälkeen rajapintaa käytetään sovellusohjelmointirajapinnan synonyyminä ( API )

[ii] https://bbvaopen4u.com/en/actualidad/apis-books-amazon-google-books-isbn-and-their-open-apis

[iii] http://toc.oreilly.com/2013/02/a-publishers-job-is-to-provide-a-good- api -kirjoja varten.html

[iv] Sovellukset (eli mobiili- tai verkkosovellukset) käyttävät API:ja tietojen jakamiseen taustajärjestelmän ja tietotallennustilan kanssa tai esimerkiksi laskelmien tai tekstianalyysien suorittamiseen pyydetyllä tavalla.

[v] https://www.kesko.fi/media/uutiset-ja-tiedotteet/uutiset/2016/kehittajat-innostuivat-keskon-haasteesta-digitaalisessa-innovointi- tapahtumassa7

[vi] https://www.tivi.fi/Kaikki_uutiset/kesko-saa-apista-apua-ilman-rajapintoja-sovelluksen-kehitys-olisi-ollut-todella-haasta- vaa-6678685

[vii] https://www.tivi.fi/Kaikki_uutiset/s-ryhma-rakentaa- api -alkaen-6689051

[viii] https://www.s-kanava.fi/web/s-ryhma/uutinen/helpompia-ja-hauskempia-ruokaostoksia-s-ryhma-ja-digital-foodie-solmivat-yhteistyosopimuksen/132628_66560

[ix] http://www.digitalgoodie.com/enterworks-holding-company-invests-in-and-joins-with-leading-on-demand-grocery-platform-digital-foodie/

[x] https://www.kesko.fi/en/media/news-and-releases/press-releases/2017/k-group-enters-into-cooperation-with-alibaba-to-open-a-food-online-store-in-china/

[xi] Lisätietoja alustapohjaisesta liiketoiminnasta ja rajapinnoista luvussa 4.

[xii] http://www.kaleva.fi/uutiset/talous/asiantuntija-verkkokauppa-kurittaa-perinteisia-kauppoja-varsinkin-jos-brandi-on-epaselva/748403/

[xiii] https://www.viestintavirasto.fi/viestintavirasto/blogit/2017/matkaketjujenhankintahelpoksi.html

[xiv] Lisätietoja kehittäjäkokemuksesta luvuissa 10 ja 16.

[xv] https://www.finextra.com/newsarticle/31141/canadian-lenders-issue-open-banking-warning

Takaisin blogiin

viimeisimmät blogimme

Uutisia, asiakastarinoita, parhaita käytäntöjä ja paljon muuta - katso, mitä me ja asiakkaamme ja kumppanimme olemme tehneet viime aikoina

Miksi APIt kannattaa tuotteistaa?
Mitä hyötyä APIen tuotteistamisesta on? Lue lisää täältä!
16. kesäkuuta 2021
Millainen on hyvä API-tuotepäällikkö?
Kaksi API-gurua, Marjukka Niinioja ja Claire Barrett keskustelevat API-tuotepäällikön roolista ja odotuksista ja jakavat itetämystään menestyksekkäästä API-tuotehallinnasta.
14. kesäkuuta 2021
Osaango & KAVI – innovatiivisia, älykkäitä hankintoja
Kansallinen audiovisuaalinen instituutti KAVI tallentaa vuosittain valtavat määrät dataa, ja vastaa muun muassa kotimaisten elokuvien sekä televisio- ja radio-ohjelmien säilyttämisestä. Kriittisen tärkeässä osassa KAVIn toiminnassa on tekoäly. Osaangon Marjukka Niinioja ja Tessa Viitanen sparrasivat KAVIa heidän mittavassa toiminnan ja tekniikan muutos-casessa tekoälyyn pohjautuvien ratkaisujen, innovatiivisten hankintamenettelyjen, ohjelmistokehitysprosesssien ja arkkitehtuurin osalta.
27. toukokuuta 2021