sunnuntai 26. elokuuta 2018

API - liiketoiminnan vallankumous - ehkä?

 
API eli "Application Programming Interface" määritellään kirjassa seuraavasti: "Ohjelmistorajapinta, jonka avulla eri sovellukset voivat jakaa tietoa, toiminnallisuutta ja muita resursseja toisten kanssa. API voi olla REST API eli sitä voidaan käyttää internetissä ohjelmointikielestä riippumatta tai se voi olla tietyn ohjelmointikielen ja tai -kirjaston rajapinta." Ennen API-maailmaa tiedon jako eri osapuolten kesken perustui kahdenkeskisiin integraatioratkaisuihin. API on sen sijaan ymmärrettävä "töpseliksi", joka mahdollistaa tiedon virtaamisen monenkeskisesti. 

API-talous 101 on kirja, jossa yhdistyy liiketoimintasuunnittelu, tuote-ja palvelusuunnittelu sekä tietojärjestelmien suunnittelusta, testauksesta ja toteutuksesta tunnetut tavoitteet, menetelmät sekä tietohallintoratkaisut. (1) Kirja on moniaineksinen yhdistelmä toimintatapoja API-maailmaan. Kirjan tavoitteena on muuttaa perinteistä liiketoiminta-ajattelua hyödyntämällä API-tuotteita / palveluita organisaation sisällä sekä organisaatioiden välillä. Tavanomaisen kilpailuyhteiskunnan rinnalle API-talous tuo ekosysteemiajattelun, jossa APIt tuotteina ja palveluina tuovat eri osapuolille lisäarvoa nimenomaan keskinäisestä vuorovaikutuksesta, yhteistyöstä. APIn ympärille voidaan itse asiassa luoda kokonainen yllä olevan kuvan mukainen kylä: "API-talouteen tarvitaan koko "kylä" (kaikki toiminnot ostamaan, myymään ja kehittämään liiketoimintaa tukevia, tarkoituksenmukaisia ja turvallisia rajapintoja)." Luulisin, että kirja onkin tarkoitettu kaikille API-osapuolille. Kirja on siksi käsitettävä yleisteokseksi, jossa liiketoimintavastuulliset saavat uuden näkökulman koko liiketoimintaan. IT-puolen vastuutahot puolestaan joutuvat tarkastelemaan APIen kehittämistä tuote/palvelunäkökulmasta. (2)

Alusta. Ekosysteemi voidaan ymmärtää innovaatiiviseksi, teolliseksi systeemiksi, mutta myös markkinoinnin järjestelmäksi, jonka tarkoituksena on tuottaa lisäarvoa asiakkaalle. Jotta API-maailma saadaan asiakkaiden käyttöön, tarvitaan alusta. "Alusta on käyttäjien ja tuottajien vuorovaikutuksen mahdollistava ja alustan ulkopuolisia resursseja hyödyntävä ja niistä liiketoimintaa tekevä ratkaisu, usein digitaalinen."  Oheisen kuvan mukaan alustalla on omistaja, alustalle tarjottavien tuotteiden tuottajat, rajapintojen tarjoajat sekä tietysti asiakkaat.

APIn elinkaari muodostuu kirjan mukaan seuraavista vaiheista: 
  1. tarpeen määritys: miten API luo arvoa? ketkä ovat asiakkaita? miten APIa tullaan käyttämään ja miten API palvelee asiakkaita?
  2. kehittäminen ja testaus: pyritään käyttämään ns. MVP-menetelmää (Minimum Viable Product). Se on pienin mahdollinen kokonaisuus, jonka avulla voidaan mahdollisimman vähällä vaivalla todentaa asiakkaan tarpeiden tyydyttäminen. Menetelmä painottaa oppimisen nopeutta kehitysprosessissa. Kehittämistyössä käytetään hyväksi ketteriä menetelmiä. (SOA-manifesti). Kirjan kirjoittajien mielestä erityisen hyvin soveltuu ns. DevOps-menetelmä tähän (käsite perustuu sanoihin Developers - kehittäjät; Operations - tuotanto).
  3. tuotanto
  4. käytöstä poistaminen.
APIt voidaan kirjan tekijöiden mukaan jakaa kolmeen kategoriaan:
  • sisäiset APIt; nämä voivat korvata osaa vanhoista tietojärjestelmistä tai tulla niiden rinnalle; sisäiset APIt haastavat koko sisäisen organisaation kaikki tason uudenlaiseen toimintaan ja voivat myös joutua ristiriitaan perinteisten tietojärjestelmäratkaisujen kanssa
  • kumppani-APIt voivat olla jomman kumman kumppanin vastuulla tai yhteisellä vastuulla tuotettuja
  • julkiset APIt ovat periaatteessa ilmaisia ja vapaasti kaikkien käytettävissä olevia tuotteita / palveluita; Avoin Data .fi-palvelu ylläpitää näitä avoimia rajapintoja.
Jotta koko API-kehittämisprosessi olisi tehokasta ja laadukasta sekä asiakaslähtöistä, tarvitaan "API-tyyliopas", joka sisältää seuraavat asiat: operaatioiden ja parametrien nimeämiskäytännöt, versiointi, virheenkäsittely, tietoturvakäytännöt (tunnistus, pääsynhallinta), tietomallit (käytetyt standardit), käytettävät metodit (CRUD) ja niiden mahdolliset vastaukset eri tilanteissa. Lisäksi tarvitaan sekä tietoturva- että käytettävyysauditointiprosessi. Ja lopuksi tarvitaan vielä mittarit, millä koko prosessia ja lopputulosta voidaan arvioida sekä jatkuvasti parantaa. Kaikki tämä edellyttää API-hallintajärjestelmää.

Kulttuuri- ja liiketoimintamuutos. Kysymys on mielestäni melkoisesta yrityskulttuurin sekä IT-järjestelmien kehittämiskulttuurien uudistamisesta. Kirjoittajat vyöryttävät esille paljon kehittämiskohteita ja uudenlaisia näkökulmia jo koeteltuihin työskentelytapoihin. Kun mennään vielä yksittäisen yrityksen ulkopuolelle, tarvitaan ekosysteemin luomisessa eri osapuolten keskinäistä luottamusta ja uuden yrityskulttuurin omaksumista. On kyllä haaste. Tietojärjestelmien kehittämisessä ei riitä pelkästään ketterien menetelmien omaksuminen. Tarvitaan myös API-ajattelun tuomista perinteisten integraatioratkaisujen rinnalle tai sijalle. Näin kun pohdiskelen asiaa, olisi varmaan ollut hienoa saada kirjoittajilta jonkinsorttinen SWOT-analyysi ja riskianalyysi niin yritystasoisena toimintana kuin ekosysteemin toimintana.

Viitteet

(1) Jarkko Moilanen, Marjukka Niinioja, Marko Seppänen, Mika Honkanen: API-talous 101. Alma Talent oy 2018

(2) API-talous - käsitteenä on kirjassa sen loppusivuilla esitetty seuraavasti: "API-talous tarkoittaa, että yritys hyödyntää toisilla organisaatioilla olevia resursseja (esim. data tai toiminta) tehokkaasti ja
 nopeasti tuottaakseen lisäarvoa omille asiakkailleen. Hyödyntämisessä rakennuspalikoita ovat omat ja toisten tarjoamat julkiset rajapinnat (maksulliset tai ilmaiset) sekä kehittäjäyhteisöt, joita hyödyntämällä yritys pystyy vastaamaan nopeammin muuttuviin ja ennakoimattomiin asiakastarpeisiin. API-taloudelle luonteenomaista on kilpailu sovelluskehittäjien suosiosta ja ensisijaisina asiakkaina pidetään sovelluskehittäjiä. Toisin sanoen tarjotaan palveluita yrityksiltä kehittäjille."
 
Poimin Googlaamalla kaksi muuta lähdettä, joissa on esitetty sekä API-talouden että APIn käsitteet. Käsillä olevaan kirjaan verrattuna Digian ja Alfamen dokumentteja on pidettävä enemmänkin kyseisten yhtiöiden mainosmateriaalina, kun taas arvostelemani kirja on riippumaton yksittäisistä yrityksistä. Poimin nämä kaksi firmadokumenttia vertaillakseni, miten ovat määritelleet APIn verrattuna kirjan määritelmiin.
  •  Näin surfaat API-talouden aallonharjalla. Pelasta liiketoimintasi disruption hyökyaallolta API-rajapintojen avulla. Digia 2018.
"Mikä on API-rajapinta?
API:t eli ohjelmointirajapinnat toimivat ikään kuin polkuina, joita pitkin tarvittava tieto kulkee hallitusti järjestelmästä, laitteesta tai verkkopalvelusta toiseen. API-rajapinnat eroavat perinteisistä järjestelmäintegraatioista siten, ettei jokaista järjestelmää varten tarvitse enää luoda erillisiä polkuja, vaan riittää, että on olemassa yksi API-rajapinta, jota pitkin tieto kulkee kaikkien tarvittavien osapuolten ja järjestelmien välillä.
Mitä on API-talous?
API-talouden hyöty perustuu siihen, että yritykset jakavat tietoa kumppaniverkostoilleen hallitusti
rajapintojen kautta. Uutta arvoa muodostuu, kun liiketoimintaa kehitetään verkostomaisessa yhteistyössä eri toimijoiden kesken rajapintojen tarjoaman tiedon ympärille. API-talouden uudet liiketoimintamallit eroavat siis merkittävästi perinteisistä sekä ekosysteemiulottuvuuden että teknologian keskeisen roolin takia. Käytännössä API-rajapinnat ovat usein liiketoiminnan digitalisoimisen perusedellytys." https://resources.digia.com/hubfs/Oppaat/N%C3%A4in-surffaat-api-talouden-aallonharjalla-opas.pdf?t=1535133309668&utm_campaign=Integraatio&utm_source=hs_automation&utm_medium=email&utm_content=63422619&_hsenc=p2ANqtz-9piKv3GD4ZPJyHOPw0nX_NN6uVjE36g0UZtX0pzttNr3vs6gcAMqlngJzElJtUH_jh3snB2hgBPpg3eLbrtJb7BWGcqw&_hsmi=63422619
  
  • Avain ketterän liiketoimintastrategian toteuttamiseenAPI-ohjelmointirajapintaopas IT-päättäjille. Alfame 2018
"API eli Application Programming Interface on
ohjelmointirajapinta, joka kuvaa vuorovaikutuksen tarjottujen palveluiden kanssa. Se rajaa riippuvuudet varsinaisen toteutuksen ja asiakkaan välillä minimiin eli on eräänlainen menettely löyhään sidontaan. API:a käyttämällä saadaan siis liiketoimintaan teknologia- ja toimittajariippumattomuutta, mikä taas lisää jatkokehitysmahdollisuuksia ja taloudellisia etuja. Ilman rajapintamäärityksiä sovelluksista tulee monoliittisia, jossa kaikki tarjotut toiminnoton sidottu kiinteästi yhteen. Silloinyksikin muutos voi heijastua koko toteutukseen ja aiheuttaa ennalta tuntemattomia ongelmia. Sen vuoksi sovelluksille määritetään komponenttiarkkitehtuureja ja lisätään rajapintoja komponenttien vuorovaikutuskohtiin, jotta osia olisi mahdollista kehittää tai korvata riskittömämmin."

Ei kommentteja:

Lähetä kommentti