Julkisella sektorilla edessä legacyn APItus tai tipahdus paaria luokkaan

Julkisella sektorilla on edessä aika massiivinen legacy järjestelmien APItus. Tekemättä jättäminen tarkoittaa digitalisaation paaria luokkaan tipahtamista.


Jäin tätä asiaa miettimään kun kuuntelin muun muassa Jouko Salosen esitystä Valtioexpossa. Kansallisen neuroverkon AuroraAI osalta yksi ajatus on että hyödynnetään olemassa olevia palveluita. Esimerkiksi Pirkanmaalla on noin 850 palvelua - satoja ihmisille suunnattuja käyttöliittymiä, jotka pahimmillaan ovat kiinteä osa taustajärjestelmää. Sellaisenaan niitä ei hyödynnä chatbotit tai tekoäly juuri mitenkään, koska ne käyttöliittymät on tehty ihmisille.

Miksei sitten vaan tehdä niitä järjestelmiä uusiksi? Kerralla ei kaikkea voi tehdä uusiksi kokonaan. Syitä tähän on muun muassa: olemassa olevat sopimukset ovat pitkiä, palvelutaso pitää säilyttää ihmisasiakkaiden suuntaan, erilaiset point to point integraatiot, jotka pitävät konetta jotenkin käynnissä.


Perinteinen integraatioiden tekeminen järjestelmien välillä ei myöskään ole taloudellisesti, teknisesti tai tulevaisuuden kannalta kestävä ratkaisu. Integraatioilla on paikkansa, mutta se ei ole kokonaisratkaisu.


Edessä on valikoidusti kyseisten palveluiden APItus - sisäisten ja julkisten APIen tuottaminen. Koostin APItuksen suuntaviivoja, jotka on koostettu pikaisen pohtimisen perusteella. Suuntaviivoja ei pidä pitää minään tyhjentävänä listana saati API mandaattina. Pelkästään olemassa olevan uudistus API:en suhteen ei riitä. Mikäli uusien järjestelmien kehitykseen ei samalla puututa eli ohjata APIen käyttöön, syntyy koko ajan uutta legacya. Siksi samalla pitää ohjeistaa kehityshankkeita APIen suhteen.


Suuntaviivoja

  • API:t tehdään tarpeeseen eli vain liiketoimintalähtöisesti (asiakas/sovellustarve lähtöisesti). Tarpeet tulee uusien ihmiskeskeisten sovellusten kehittämisen kautta.

  • Kaikkia jo kaupunkin mittakaavassa satoja järjestelmiä ei voi vain kipata järveen ja tehdä uusiksi rysäyksellä. Siksi pitää tehdä “legacy APItus”

  • Jokainen tietovaranto ei välttämättä sisällä omia julkisia rajapintoja, vaan asiakastarpeiden mukaan tarjotaan dataa usean tietovarannon sisältä.

  • Sisäiset rajapinnat pakollisiksi jokaisessa tietovarannossa. Hyödynnetään tarvittaessa integraatioalustoja.

  • Sisäiset rajapinnat toteutetaan oletuksella että ne julkaistaan muiden käyttöön.

  • Kaikkea ei voi eikä kannata APIttaa kerralla.

  • Jokaiseen jatkossa hyödynnettävään palveluun sisäiset APIt.

  • Käytetään integraatioalustaa tarvittaessa yhdistämään datavirrat sisäisiin rajapintoihin ja tuotetaan niiden päälle julkiset rajapinnat.

  • Jos sisäisen rajapinnan voi julkaista julkiseksi rajapinnaksi, se tehdään sen sijaan että tuotetaan uusi rajapinta.

  • Uusien kehitettävien järjestelmien tulee hyödyntää sisäisesti rajapintoja. Lähtökohtaisesti järjestelmän dataa ja toimintoja hyödynnetään kolmansien osapuolten taholta julkisten rajapintojen (avoin API ja kumppani-API) kautta. Huom! Avoin API ei ole sama kuin avoimen datan rajapinta.

Kun APItus on lähtenyt liikkeelle ja julkisten rajapintojen kautta tarjotaan data ja toiminnot eri osapuolten käyttöön, voidaan aloittaa legacyn uudistus ja massiivisten möhkäleiden pilkkominen pala kerrallaan. Samalla siirrytään kohti mikropalveluarkktehtuuria.


Sisäistä APIen moninaisuus ja oikeat termit


Koska APItuksessa on olennaista ymmärtää eri API-lajikkeet, laitan tähän alle API tikkataulun, joka auttaa hahmottamaan APIen moninaisuutta. Mikäli emme pysty puhumaan asioista samoilla termeillä ymmärtäen asiat yhtenäisesti, tuloksena on lisää epäselvää viestintää ja sekaannusta (nykytilanne).





Kohti alustoja ja alustataloutta


Kaupunkien kohdalla tämä tarkoittaa mahdollisuutta yhdistää APItus muutokseen, jossa kaupungista tulee alusta. Sama mahdollisuus on olemassa valtion tasolla esim sektoreittain. Education and as a Service mahdollistava alusta, jossa on keskeiset yhteiskäyttöiset palvelut mukaan lukien jatkuvan oppimisen tunnistuspalvelu (MPASSid), toiminto- ja datarajapinnat (joiden takana vaihteleva määrä tietovarantoja) sekä niiden hallinta.


API-hallinta olisi hyvä olla kansallisella tasolla, mutta ainakaan vielä Suomi.fi -palveluväylä ei sitä pysty tarjoamaan REST, GraphQL tai reaaliaika-APIen osalta. Mikäli Suomi.fi -palveluväylä nopeasti tuottaa kansallisen ratkaisu em tarpeisiin, tilanne on toinen. Muussa tapauksessa sektorirajoja noudattavat alustat tulevat sisältämään oman API-hallinnan ja suomi.fi - palveluväylä tulee olemaan julkisen sektorin sisäisen dataliikenteen väylä. Kaupunkien kohdalla API-hallinta lienee järkevin tehdä kaupungin alustaan. Haaveilut 6 suurimman kaupungin yhteisestä API-hallinnasta tuntuu aika heppoisilta ottaen huomioon että asiasta on puhuttu jo noin 4 vuotta eikä konkretiaa ole näkynyt. Mutta toki sekin on mahdollisuus ja pidetään katsanto avoimena vaihtoehdoille.





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