2000-luvulle asti kaikki integraatiot olivat käytännössä eräajoja eri sovellusten kantojen välillä, vaikkakin järjestelmien välisiä kovia riippuvuuksia saatiin pehmitettyä keskitetyllä ESB-alustalla. Integraatioista seurasi kuitenkin valtava määrä liitoksia järjestelmien välille, sillä jokaiselle tarpeelle tuli tehdä oma liittymäkohtansa. Kuvassa 1 on esitetty silloista näkymää. Tällöin master dataa sisältävän järjestelmän uusiminen oli kustannuksiltaan hintavaa, sillä integraatioita oli niin runsas määrä – jokaiselle järjestelmälle omansa.
Siirryttäessä 2010-luvulle alkoi kuitenkin ymmärrys API:en mahdollisuuksista lisääntyä: API:lla oli mahdollista tuoda tehtävät kauemmas master datasta. API:a on myös mahdollista käyttää useaan eri käyttötarkoitukseen: tehtäviin ja viitteellisiin tietoihin. Samalla integraatioiden määrää saatiin karsittua. Haasteelliseksi tilanteen muodosti kuitenkin se, että asiakkaille palveluita tarjotakseen oli käyttölupienhallinta puutteellinen tai jopa olematon sisäisissä API-toteutuksissa. Kuviossa 2 on näkymä vuoteen 2010.
Nykyisin, vuonna 2017, API:t on viety pilveen – tai ainakin siihen on haluttu tarjota mahdollisuus. Ohjelmistoja hankitaan tänä päivänä yhä useammin pilvipalveluista ja pääsääntöisesti aina ne myös toimivat mobiilisti, mikä aiheuttaa uudenlaisia vaatimuksia myös järjestelmien väliselle yhteentoimivuudelle ja tiedonsiirrolle. Ohjelmistojen välille ei myöskään haluta enää tiukkoja sidoksia, joista pääsee irrottautumaan API-strategiaan keskittymällä.
Kun perinteisesti IT on ollut jumissa vanhojen taustajärjestelmien ja sovellusten kanssa, joihin ei ole uskallettu tehdä muutoksia, API Management on mahdollistanut rajapintojen avulla esimerkiksi vaiheittaisen käyttöönoton, ketterän testaamisen ja selkeän palveluiden dokumentoinnin. API:lla on myös mahdollista palvella sekä sisäisiä toimia että asiakkaiden tehtäviä. Lisää API:n hyödyistä voit lukea esimerkiksi aiemmasta blogiartikkelistamme.