Alustojen Suomi - julkinen sektori muutoksessa

Updated: May 18, 2018

Disclaimer: piti kirjoittaa lyhyt postaus kun suklaamunien syönti pääsiäisenä alkoi tökkimään. Mämmiä en syö. Tekstistä tulikin aika pitkä ja otsikkokin muuttui kirjoittamisen aikana.


Helmikuun virkaanpaluun jälkeen olen jotenkin yrittänyt ottaa haltuun että missä menee “digitaalinen Suomi” ja miten voisin sitä edistää. Lähdetään liikkeelle asiakkaasta. Palveluita syntyy tukemaan ihmistä elämäntapahtumissa. Tämä on viesti, jota Kopponen Valtiovarainministeriön “Digiosastolta” levittää ja jalkauttaa muun muassa elämäntapahtumapilottien avulla. Tästä on ainakin yksi tubepätkä, jossa Kopponen avaa asiaa.


Omassa päässäni rakennetussa mallissa palvelut syntyvät alustojen tarjoamien keskeisten osapalveluiden päälle. Eikä vain minun päässäni. Alustat ja ekosysteemit tuntuvat kuluneilta hype sanoilta, niin paljon niitä on viljelty. Mikä ihmeen ekosysteemi on kysymys silti monien päässä. Sama kysymys on yllä linkitetyssä tubepätkässä.


Ekosysteemi karkuteillä


Vaarallisinta on lähteä nyt määrittelemään ja luomaan retoriikkaa ekosysteemista ihan stetsonista ilman mitään pohjaa tieteelliseen työhön. Näin on päässyt käymään APIen kohdalla ja nyt sekoitetaan iloisesti eri APIt toisiinsa eikä kukaan puhu samasta asiasta yhden termin kohdalla. Myöhemmin tässä tekstissä API-lajikkeista lisää muutama sana. Yksityiskohtaisempi kuvaus APIen eroista ja käytännön sovellutuksista on kirjoitettu API-talous 101 -kirjaan, joka julkaistaan syksyllä 2018.


Mutta palataan niihin ekosysteemeihin (joista myös kyseisessä kirjassa kirjoitetaan laajasti). Sama moniäänisyys (rinnakkaiset todellisuudet) ei saa toistua ekosysteemin ja alustan kohdalla - se vain luo kaaosta ja hidastaa kehitystä. Nyt ollaan jo valitettavasti sillä tiellä. Liiketoimintaekosysteemien kontekstissa Ron Adner on tarjonnut käyttökelpoisen tuoreen määritelmän ekosysteemista:

Ekosysteemi muodostuu monikerroksisesta joukosta kumppaneita, joita kaikkia ja kaikkien vuorovaikutusta tarvitaan materialisoimaan keskeinen ekosysteemin lupaus

Olisiko Suomen kontekstissa “ennakoiva ja ihmiskeskeinen” jotenkin tuohon ekosysteemin lupaukseen liittyvä asia. Materialiasointi voitaneen tulkita tässä tarkoittavan niitä elämäntapahtumissa auttavia palveluita.

Alusta puolestaan tarjoaa infrastruktuurin ja säännöt markkinapaikalle, joka tuo yhteen tuottajat (toimittajat) ja käyttäjät (asiakkaat).

Ekosysteemin toimijoilla on neljä periaatteellista roolia: alustan omistaja, palveluntarjoaja, toimittaja ja asiakas. Roolit voivat muuttua nopeasti myös samalla alustalla tai olla yhtäaikaisesti olemassa.


Edellä mainituista osapalveluista identiteetinhallinta ja rajapinnat ovat lähellä omaa arkeani. Identiteetinhallinnan osalta olen 2015 laittanut liikkeelle MPASSid kertakirjautumispalvelun kehittämisen ja nyt sitä otetaan kansallisesti käyttöön. MPASSid välittää jokaisesta kirjautuneesta käyttäjästä standardoidun tietomallin mukaisen joukon tietoja palveluntarjoajalle. Nämä tiedot puolestaan tulevat viranomaisten oppilashallinto-järjestelmistä (joka kunnassa lähes omansa) eli niihin voitaneen luottaa. Julkiset rajapinnat puolestaan mahdollistavat datan liikkumisen ja uudellenkäytön osana palvelukehitystä.

Opetussektorin alustassa, “Elinikäisen oppimisen alusta” kuten olen sen nimennyt päässäni, identiteetinhallinta/tunnistus on yksi palvelu sisältäen MPASSid:n ja HAKA palvelun. Niiden yhdistämisellä katetaan oppijoiden tunnistus vauvasta vaariin.


Nykyaikainen palvelukehitys on API-pohjaista


Ennen liimattiin koodia yhteen ja avoin lähdekoodi hyötyi tästä ja avoimen lähdekoodin yhteisö hyötyi tästä. Nyt tuotantoparadigma on muuttunut ja APIt ovat väline yhdistää toimintoja kokonaisuudeksi. No niin, eli appiksia ja palveluita syntyy ja ne perustuvat usein avointen APIen (ilmaisia tai maksullisia) hyödyntämiseen. Samalla syntyy API-talous, joka voidaan määritellä seuraavasti:

API-taloudessa organisaatio hyödyntää omia ja toisten organisaatioiden resursseja sisäisten ja avointen rajapintojen avulla tuottaakseen sovelluksia ja palveluita nopeasti ja siten lisäarvoa asiakkailleen. API-taloudelle luonteenomaista on kilpailu kehittäjäyhteisöjen suosiosta ja palveluiden tarjoaminen ensisijaisesti sovelluskehittäjille (engl. Business-to-Developers, B2D). ( API-talous 101)

Avoimella rajapinnalla (engl. Open API, external API) tarkoitetaan julkisia (engl. public) ja kumppani (engl. partner)-rajapintoja erotuksena organisaation sisäisistä (private tai internal API). Avoimet rajapinnat voivat olla maksullisia tai maksuttomia ja sisältää käyttäjätunnistuksen. Rajapinnan tarjoama data voi olla avointa dataa (open data) lisensoituna creative commons-tyypppisillä lisensseillä. Noustaan rajapinnoista uudelleen katsomaan ekosysteemiä vähän ylemmältä tasolta.


Alustojen Suomi - APItus edessä


Paljon on Suomessa käytetty verovaroja sähköistämiseen ja jossain määrin joskus digitalisaatioon. Olemassa olevia palveluita voidaan varmasti jossain määrin hyödyntää, mutta ei sellaisenaan.

Edessä on monen palvelun “APItus” eli niihin pitää rakentaa nykyaikaiset julkiset APIt.

APItus olisi pitänyt aloittaa samassa vaiheessa kun aloitettiin palveluväylän käyttöönotto. API -ohjausta olisi pitänyt tehdä virastoissa eikä antaa sooloilla mitä sattuu. Tässä tietysti on saumansa integraatio-uskovaisilla, joiden puskemia alustoja saatetaan tarvita legacy järjestelmien APItuksessa.


Suomeen ei tule syntymään yhtä suurta alustaa (ei ainakaan lähitulevaisuudessa), jonka päällä kaikki virastot sujuvasti kehittävät yhdessä palveluita ja jonka keskeisiä muiden hyödyntämiä palveluita kehittävät oman aikataulunsa mukaisesti. Suomi.fi -palveluväylä ja sen ympärillä olevat palvelut eivät tule muodostamaan sitä vaikka kuinka jotkut saattaa niin haaveilla. Ainakaan en usko siihen nykyisellä kehityksellä, jota olen saanut palveluväylän alusta asti seurata kohtalaisen läheltä. Toki palveluväylällä roolinsa tulee olemaan, mutta jotenkin siitä on nyt jäänyt kuva joka voidaan tiivistää lauseeseen: sulkeutunut julkisen sektorin temmellyskenttä, jossa avoimuus ja eri sektorien tarpeet eivät kohtaa. Tästä tulikin jo kirjoitettua jokin aika sitten oma juttunsa. Toivottavasti historia osoittaa minun olleen väärässä.


Sen sijaan Suomeen tulee syntymään useita alustoja ja oma veikkaukseni on että ne tulevat aluksi noudattamaan hyvin pitkälti vanhoja toimialarajoja: OKM:llä, STM:llä, VRK:lla ja muilla (ei kaikilla) on omat alustansa. Sekin olisi edistystä verrattuna nykyiseen tilanteeseen, jossa jokaisella virastolla on oma kokoelmansa palveluita, joilla harvoin on mitään yhteyttä keskenään. Paitsi tietysti niin että asiakas hyppii palvelusta toiseen hoitaen yhden asian siellä ja toisen täällä. Rakenteilla oleva yhteinen tietopolitiikka voisi olla väline pitää syntyvät alustat jotenkin edes hiukan samassa suunnassa ja mahdolllistaa edes minimaalinen yhteentoimivuus esimerkiksi datamallien tasolla.


Kun tämän kokonaisuuden piirsin kuvaksi (jota päivittelen tilanteiden muuttuessa, sain kyhättyä nauruversion siitä miten ekosysteemiä (tai joukkoa ekosysteemejä) voidaan katsoa tasoina.





Kuva on yksinkertaistettu eikä esimerkiksi ota mitenkään huomioon muiden sektorien olemassa oloa juuri mitenkään muuten kuin markkinapaikka ja palvelukerroksessa.


Orkestrointi


Hyvä kysymys on että missä on orkestrointi? Ja mitä se on? Onko se osa alustoja vai palvelukerrosta? Vai oma kerroksensa? Koko sana orkestrointi viittaa enemmän verkostopohjaisen toiminnan koordinointiin ja se kuvasti aikaa ennen alustojen valtakautta. Isot yritykset ovat tehneet orkestrointia jo pitkään hallitessaan alihankintaketjua. Jossain määrin epäselvää itselle on että mikä on orkestroinnin ja alustan rajaresurssien suhde toiinsa.

Jos nyt ihan hypoteettisesti määritellään orkestroinnin tarkoittavan ainakin sitä toiminnan kerrosta jossa jollain logiikalla (pääosin asiakaslähtöisyys) päätetään ja tehdään eri alustojen tarjoamien osapalveluiden yhdistäminen APIen avulla uusiksi palveluiksi, jotka sitten tukevat ihmistä elämäntapahtumissa.


No, perinteisten virastojen kannalta ajatellen se ei voisi olla alustoissa, ei ainakaan ilman että siiloajattelusta päästään ajatustasolla irti. Muuten käy niin että syystä tai toisesta ei käytetä toisten alustojen palveluita, vaan vain omia “koska näin on ennenkin tehty” tai muusta todella älyttömästä syystä. Ja jos jotain ei omalta alustalta löydy, se kehitetään - taas kerran uudelleen. Yksityisellä sektorilla tätä ongelmaa ei juurikaan ole. Jos joku toiminto on olemassa 3. osapuolella ja toteutus sekä käyttö järkevää, sitä käytetään sen sijaan että tehdään uudestaan.

Sen sijaan, että ihminen “juoksee” websivulta tai luukulta toiselle, sovellukset “juoksevat” rajapintoja hyödyntäen.

Jos orkestrointi on osa vapaata markkinaa, voisi ainakin periaatteessa syntyä eri sektorien välisten osaratkaisujen yhdistämistä palveluiksi tukemaan elämäntapahtumia. Eli kansallisella tasolla orkestrointi ei ole alustassa vaan niiden päällä. Mutta edelleen kysymys on että missä ja kuka tekee? 


Markkinapaikka


Entä sitten kun palveluita alkaa syntymään? Hyvä juttu. Mutta mistä ne oikein löytyvät? Applella ja Googlella on storet. Pitääkö Suomella olla oma? Ei äkkiseltään kuulosta ihan järkevältä. Saattaa olla että joku tarve olisi ns julkkarin storelle, joka ei välttämättä tarkoita ihan samaa kuin mobiilialustojen kauppapaikat. Voisiko suomi.fi olla sellainen paikka, josta palvelut löytyvät? Jos ovat niin ne palvelut pitää pystyä hakemaan myös nykykaisia rajapintoja pitkin (REST). Appisten kohdalla tulisi hyödyntää olemassa olevia kanavia eli niiden globaalien jättien kauppapaikkoja.


Oletuksena tietysti jokaisessa osapalvelussa, joita eri organisaatiot kehittävät on myös ne APIt, joiden kautta niitä voidaan hyödyntää. Lisäksi kyseiset joskus hyvinkin atomistiset mikropalveluarkkitehtuurin periaatteita noudattavat palvelut hyödyntävät datavarantoja ja toisia palveluita APIen avulla. Hmm...rajapintoja siellä täällä - sisäisiä ja julkisia. 


Rajapintojen hallinta ja markkinointi


No mutta entäs sitten niiden APIen hallinta? Siinä ei ole Suomessa päästy oikein millään mallilla eteenpäin sitten 2013 jolloin aloin vöyhkäämään rajapinnoista isommin. Sen sijaan hukattiin vuosia ja junnataan sekä keksitään pyörää uudestaan tai pidetään kiinni olemassa olevasta. Palveluväylän kontekstissa nyt suunnitellaan REST API tukea.


Yksi vaihtoehto on osaksi liityntäpalvelinta. Juttelin tästä Petteri Kivimäen kanssa pari viikkoa sitten. Sen jälkeen jäin miettimään tätä ratkaisua. Ei kuulosta hyvältä idealta. Miksei? No oletetaan että haluan ottaa REST rajapinnan käyttööni. Mitä minun pitää tehdä? Asentaa liityntäpalvelin! Markkinoiden odotukset APIen suhteen on minuuttien käyttöönotto päätöksestä - ei lisäkomponenttien lisääminen arkkitehtuuriin. Jos liityntäpalvelin vaatimus voitaisiin jollain ilveellä saada SDK pakettiin, niin sitten se voisi vielä menetellä. Silloinkin pitäisi tehdä tuotteistus eli viedä SDK pakettienhallintajärjestelmä tasolle (pip, npm) eikä olettaa että zippi paketteja otetaan käyttöön - ei oteta. Tai no, ehkä julkinen sektori hyväksyy, koska heillä nyt muutenkin pitää käytännössä olla liityntäpalvelin. Kovin vetovoimaiselta asetelma ei välttämättä näyttäydy muiden sektorien suuntaan. Ehkä muut sektorit myöntyvät tässä liityntäpalvelin asiassa kunhan tuetaan nykyaikaisia rajapintoja.


Samalla pitäisi miettiä, että miten niitä rajapintoja markkinoidaan? Edelleen ne rajapinnat ovat tapa hyödyntää jo olemassa olevia palveluita ja siksi ne pitää löytyä. Tyypillisin ratkaisu on API-katalogi. Sellaista on tehty nyt suomi.fi -palveluväylän osana, mutta sepä ei sisälläkään REST rajapintoja saati reaaliaikarajapintoja (joita muun muassa HSL jo käyttää). Ekosysteemin toiminnan kannalta rajapintojen löytyminen ja nopea käyttöönotto silloin kun niitä tarvitaan (eli usein) on kriittistä. Aikanaan ehdotin suomi.fi portaaliin olemassa olevien näkymien lisäksi “Kehittäjille” näkymää, mutta se ei ottanut tulta alleen. Siinä olisi ollut paikka tehdä “Suomi SDK” eli digitaalisen Suomen kehittäjäkeskus saman sateenvarjon alle. Kehittäjiä ei siinä vaiheessa nähty kohderyhmänä, joihin kannattaa panostaa. Ei kyllä nähdä vieläkään kovin laajasti, mutta pikku hiljaa tietoisuus alkaa lisääntymään.


Tästä kansallisen tason hitaudesta johtuen uskon että API-talouden osalta alustat tulevat tekemään omat API-hallintansa. Tätä on jo näkyvissä. Palveluväylään suunniteltu REST tuki osana liityntäpalvelinta tulee ehkä tapahtumaan liian myöhään. Osa virastoista menee jo ja hallitsee REST-APIt siten kuin parhaaksi näkee, eli villisti tai ei ollenkaan. Opetussektorilla ei ole yhteistä API-hallintaa, mutta puhetta asiasta on alkanut nousemaan esiin entistä enemmän. Sen lisäksi pitää määritellä mitä muita palveluita kuuluisi “elinikäisen oppimisen alustaan”, joka olisi toimialan virastojen yhteinen. Osastot ja virastot jatkavat työtään datakerroksessa, mutta yhdistävät voimansa ainakin alustakerroksessa.


Tietovarantoja tehdään hyvää vauhtia


Tietovarantoja on alkanut syntyä eli datakerros rakentuu kovaa vauhtia. Opetussektorilla KOSKI tietovaranto on keskeinen ja rinnalla kehitetään muun muassa Varda (varhaiskasvatuksen) tietovarantoa, joka lopulta voi olla osa KOSKI kokonaisuutta. Näiden lisäksi muitakin on syntymässä. Niissä kaikissa on/tulee olla REST rajapinnat, jotka on kuvattu koneluettavasti ja joissa kehittäjäkokemus on otettu keskeisenä tekijänä huomioon. Osa tietovarantojen kohdalla kehitetyistä rajapinnoista saattaa olla vain sisäiseen käyttöön, mutta osa niistä saatetaan avata julkisiksi myöhemmin joko sellaisenaan tai pienen muutoksen jälkeen. Niin tai näin, on niiden hallinta (kehittämis ja käyttö) mietittävä ja järjestettävä fiksusti.


Kantaako kevään 2019 yli?


Lopuksi vielä jatkuvuudesta. Väliotsikon kysymys oli ensimmäinen joka minulle tuli mieleen elämäntapahtumapiloteista kuultuani. Virkamiehenä haluan rakentaa jotain pitkäjänteistä enkä 4 vuoden välein aloittaa aina alusta. Vaikka elämäntapahtumiin perustuvasta filosofiasta tulisikin vain yhden hallituksen ihme, ei alusta tai ekosysteemi ajattelu mene hukkaan, koska ne eivät ole naimisissa kyseisen filosofian kanssa. Myöskään API-pohjainen palveluidenkehitys ei ole elämäntapahtumasidonnainen. Ihmiskeskeisyys tai kuten yksityisellä sektorilla tyypillisesti sanotaan, asiakaslähtöinen kehittäminen tuottaa aina paremman lopputuloksen.


Orkestroinnin eli palvelutuotannon logiikan, API-hallinnan tai markkinapaikan suhteen en ole nähnyt kuvissa ratkaisua vielä. Siinäpä ne kolme isoa aluetta, jotka ainakin pitää saada selväksi ennen kuin ihmiskeskeinen ja ennakoiva “Suomi” niminen digitaalinen ekosysteemi pääsee käyntiin.

15 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ää!