Sök

Nyckeln till att lyckas med API-integration – tänk i lager!

En populär integrationsstrategi som det pratats mycket om de senaste åren är ”API-ledd konnektivitet” (”API-led connectivity” på engelska för dig som vill googla och få lite fler träffar). Det är en strategi och ett synsätt på integration som kan sägas vara en vidareutveckling av den gamla SOA-modellen (Service-Oriented Architecture).

API-ledd konnektivitet är ett resultat av att API:er blivit alltmer betydelsefulla, och inte längre bara är en angelägenhet för ett litet antal ingenjörer som jobbar med att koppla ihop interna system. API:er, och särskilt då Webb-API:er, är helt avgörande verktyg för att företag ska kunna vara snabbfotade och hålla sig relevanta i den hårdnande globala konkurrensen.

Tekniker som IoT, SaaS, big data, sociala och mobila plattformar kombinerat med API:er öppnar upp möjligheter för företag att snabbt kunna leverera nya IT-tjänster, låsa upp nya intäktsströmmar, förstå sina kunder bättre och förnya sig snabbare än någonsin tidigare. Men för att göra det måste de integrera dessa nya tekniker med API:er.

För många företag idag är API:er en del av erbjudandet – en produkt som alla andra. Eller rättare sagt: en av de viktigaste produkterna. De som inte kan erbjuda ett bibliotek av välfungerande API:er för olika ändamål / konsumenter hamnar lätt i bakvattnet.

 

Den skiktade grundmodellen

Att jobba med API-ledd konnektivitet innebär att man, som namnet antyder, använder API:er som bas både för intern och extern integration. För att kunna göra detta effektivt, och undvika att man fastnar i den vanliga ”integrationsspaghettin” behövs en välfungerande guide / modell för hur API:erna ska vara organiserade.

Den modell som många företag väljer är en s k skiktad (layered) modell, grovt uppdelad i skikten System, Process och Upplevelse (”Experience”).

 

Grundprincipen för den skiktade modellen är att varje skikt bara exponerar information som är relevant för ”konsumenter” i det närmast överliggande skiktet. Låter det abstrakt? Vi ska försöka förklara genom att titta närmare på de olika skikten och även ge ett någorlunda konkret exempel.

Systemlagret

API:erna i systemlagret är ansvariga för att ”låsa upp” data från företagets viktigaste system (t ex affärssystemet), och göra denna tillgänglig för konsumenter i Processlagret. Syftet är att skydda användaren från komplexiteten i de underliggande systemen och eliminera behovet att göra besvärliga ändringar i dessa. När API:erna i systemlagret väl byggts kan de återanvändas i många olika projekt, med olika syften. Det blir också enklare att byta ut källsystem när man bara (iaf teoretiskt) behöver modifiera eller byta ut api:er i systemlagret.

Processlagret

API:er i processlagret ansvarar för att kapsla in data i tydligt definierade affärsprocesser genom att anropa ett flertal system-API:er. Detta inkluderar att berika, dela upp, filtrera och dirigera data.

Upplevelselagret

API:er i det översta lagret, upplevelselagret, har till uppgift att leverera en upplevelse för en slutkonsument, t ex en mobilapp. All grunddata som krävs för att leverera upplevelsen är exponerad genom System API:er, och Process API:erna har i sin tur exponerat affärsprocesslogiken.

Exempel på tillämpning av skiktade API:er

För att illustrera hur den skiktade API-modellen kan fungera i praktiken, tänk dig följande scenario:

 

Ett företag har webbshop och en mobilapp där kunder kan lägga beställningar. Orderdata hanteras i e-handelsplattformen, lagerdata i affärsssystemet och kunddata i CRM-systemet. För att kunna hantera ett kundköp på webbshopen på ett optimalt sätt behöver dessa system vara sammankopplade. I ett verkligt scenario hade man sannolikt även velat anropa API:er för tredjepartspartners inom logistik, men låt oss utelämna det här för att hålla det enkelt.

Om nya behov uppstår är det lätt att bygga ut lösningen eftersom man bara behöver göra ändringar i Upplevelselagret. Alla de återanvändbara komponenterna (API:erna) finns redan i vår lagerstruktur.

 

 

Om utvecklarna istället hade jobbat med vanliga punkt-till-punktkopplingar (via API:er), utan tydlig lageruppdelning, hade man förmodligen haft en lösning som funkat bra över en begränsad tid. Men när nya behov uppstår, t ex att säljavdelningen efterfrågar en egen app för att kunna ha koll på kunder och orderhistorik, blir det problematiskt eftersom man inte kan återanvända något av det man skapat tidigare. Om konsulter varit inblandade i att skapa lösningen blir problemet än värre, eftersom de ofta är fokuserade på en specifik, begränsad leverans och sällan har tydliga incitament för att jobba långsiktigt.

Vill du veta mer?

Om du vill veta mer om hur du kan jobba effektivt med skiktade API:er, kolla på den här videon med vår integrationsspecialist Olof.

Om du känner att du behöver bättre koll på grunderna när det gäller API:er, läs den här introduktionen till API:er och hur de fungerar.

Vill du veta mer? Låt oss kontakta dig: