API-användning är ett affärsbeslut

Applikationsutvecklare har alltid varit intresserade av att dela upp ansvar, paketera och sprida ut sina uppgifter. För att rusa framåt i utvecklingen använder de sig gärna av någon annans lösningar. Vad har användning av API med det här att göra och varför lönar det sig att satsa på det?

Modern systemutveckling innebär till stor del sammanställning av färdiga bitar och informationskällor. Paketering av uppgifter och ansvar, s.k. komponentisering, medför begreppet programmeringsgränssnitt (API).

Att använda API innebär att man erbjuder funktioner och data som en tjänst som systemen använder. API döljer själva implementeringen och visar endast en förenklad kommunikationsmodell för användaren.

Grovt förenklat finns det två modeller bakom API: en proaktiv och en reaktiv. Med hjälp av ett gränssnitt som erbjuds proaktivt försöker man förutsäga målgruppens behov, och man fiskar efter nya användare för sina egna lösningar eller data. Man skapar alltså aktivt ny efterfrågan. I den reaktiva modellen däremot kommer initiativet och behovet utifrån. En del parter har redan upptäckt värdet av en funktion eller någon information i sin egen affärsverksamhet och vill utnyttja det.

I båda fallen är det i sista hand fråga om ett affärsbeslut som sammanfattas i frågan: ”Är nyttan av att erbjuda kompetens eller data till andra som en tjänst större än den mängd ansvar, underhållskostnader och arbete det medför?”.

Enskilda utvecklare gör API-beslut dagligen på kodnivå för att underlätta det egna eller kompisens arbete. Ägarna av ett system eller en produkt begrundar det här i något större helheter och tar kanske med förtjänstlogik. Beslutet att satsa på ett öppet gränssnitt kan vara strategiskt, fattat av ledningen i en enskild organisation eller av sammanslutnignar av organisationer. Det kan också vara politiskt, en mekanism för reglering av samhället.

Fördelar med API

Så varför lönar det sig att använda API? Nedan några konkreta fördelar med korta motiveringar.

1. Implementera integrationerna som självbetjäning

Syftet är, att om webbutiken till exempel vill att kunden ska kunna se en beställnings leveransstatus, så ska utvecklarna av webbutiken bara behöva söka fram rätt API ur användarportalen och implementera det i sin egen lösning. Övriga parter behövs inte för implementeringen. Det här uppnår man genom att skapa en bra informationsarkitektur och genom att kräva produktifierade gränssnitt av systemen.

2. Placera applikationsutvecklarna i centrum

Vi måste kräva att gränssnitten i systemen är lättförståeliga, väl definierade och lätta att implementera. API-producenten måste stöda andra utvecklare med en bra dokumentation, fungerande kodexempel, en stödgrupp och bör till och med fungera som applikationsutvecklingsstöd. Att felsituationer och återhämtningen från dem ska vara väl planerade och möjliga att automatisera är en självklarhet.

När ett team som byggts upp på rätt sätt har befogenheter som omfattar både tjänstens innehåll och saker relaterade till implementeringen av den, växer motivationen att göra kvalificerade lösningar. Gränssnitten produktifieras, vilket gör att graden av självbetjäning i användningen av dem stiger.

3. Förenkla och undvik överraskningar

Den tekniska mångfalden växer och växer, så det är allt viktigare att API-användningen skapar möjligast enkla lösningar som stöder affärsverksamheten. Framför allt för hanteringen av så kallade Web API:er får utvecklarna numera en identifieringsnyckel som gör att man kan följa användningen och sätta upp olika begränsningar, och att man i en förändringssituation kan kommunicera med utvecklarna på förhand och undvika överraskningar.

4. Effektivisera innovationscykeln

Med gränssnittsbeskrivningen främst kan man snabbt mäta intresset för någon idé, till och med innan investeringsbeslutet för den egentliga tjänsten ens har gjorts. När systemens funktionaliteter och data öppnas kontrollerat inför en större grupp ökar mängden idéer. Det kan komma fram oförutsett populära och fräscha kombinationer och synpunkter i gruppen.

5. Öka skyddet för operativa system

Speciellt när det gäller gränssnitt för dataförfrågning är det onödigt att förbruka den ofta dyrt licensierade beräkningskapaciteten i företagets operativa system. En statusförändring i en transaktion eller entitet kan man också publicera ut. Informationstjänster baserade på molntjänster eller öppen källkod kan ta emot förändringen och erbjuda förfrågningsgränssnitt, som skalar upp självständigt och billigt enligt mängden förfrågningar.

--

Konkreta fördelar bör man givetvis alltid tänka på inom kontexten för sitt eget företag och skapa en API-strategi som stöd för arbetet. Det väsentliga är att förstå att arkitekturen, utvecklingstakten, kvaliteten och organisationen reflekterar varandra.

Genom att satsa på mikrotjänstarkitektur, autonoma operativa team och utvecklarvänliga gränssnitt kan du effektivisera utvecklingen av tjänster och deras skalbarhet. Det kommer mera viktigt tänkande från en produktinriktad affärsverksamhet i implementeringarna.