Vad alla it-chefer måste veta om API:er

API:er, eller application programming interfaces – programmeringsgränssnitt – börjar bli betydelsefulla verktyg för it-chefer som vill tillföra värde till verksamheten. I synnerhet om de satsar på omfattande digitalisering eller på att skaffa nya källor till inkomst.

Med API:er kan man översätta text, etikettera bilder, skicka textmeddelanden, kolla misstänkta bedrägerier, hämta öppna bankdata och hantera allt fler typer av affärstransaktioner. När API:er blir av kritisk betydelse för it och programutveckling i organisationen behöver it-chefen tänka på administration, regelefterlevnad och access: vem får tillgång till vilka företagsdata genom vilket API under vilket styrningssystem?

Man måste också tänka på vad det är som organisationen i praktiken utkontrakterar – eller gör beroende av sig – med API:er. Om en utvecklare väljer ett API av rent tekniska skäl kan därmed fatta ett inköpsbeslut på företagsnivå eller välja en strategisk inriktning som ligger långt över hans eller hennes beslutsfattarnivå.

Det behövs en policy som håller ordning på användningen av API:er utan att därför bromsa rörligheten. Det förutsätter en klar bild av vilka interna och externa API:er som används i organisationen, vad de används för, vad de kostar och hur tillförlitliga de är. På den strategiska nivån måste en cio vara klar över vad API:erna tillför verksamheten.

Integrering och sammansättning

– Många av våra kunder skulle vilja gå till en framtid där de faktiskt har en API-ekonomi och en API-katalog och där de exponerar data för alla ”skorstenar” i företaget, säger Charles Lamanna, ansvarig för low code-applikationsplattformen på Microsoft.

– Användning av en API-gateway eller andra hanteringslösningar tillsammans med en low code-plattform frigör massor av möjligheter, för då kan utvecklarna bygga mikrotjänster och publicera dem så att andra utvecklare kan använda dem, säger Charles Lamanna.

Men att ha en ”API-ekonomi” innefattar mycket mer än low code och no code. Som Abhinav Asthana, vd för Postman, ett företag som utvecklar API-plattformar, påpekar bör en organisation börja tänka på API:er så snart den börjar speca och designa mjukvara – inte vänta tills projektet är avslutat:

– Då kan det sluta med att man fattar suboptimala beslut, vilket leder till ännu fler risker inom regelefterlevnad och styrning. Det händer helt enkelt inte nu för tiden att du bygger en applikation som inte kommer att prata med omvärlden, så ta med det i beräkningen från början.

API:er används inte bara för konsumtion av externa tjänster. Organisationer skapar ofta egna API:er för att ge möjlighet till självbetjäning av gemensamma data inom verksamheten eller för att underlätta utbyte av information med andra företag. Inskolning av en ny leverantör eller kundens val av betalningsmetod blir mer effektivt om information om betalningar och leveransstatus är lätt tillgängliga, men sådant är ofta inlåst i flera affärssystem. Att skapa API:er och publicera dem i en katalog kan spara företaget många supportärenden.

– Tänk på vilka data eller kompetenser som är unika för din organisation, som du hoppas kunna sälja till andra, eller som helt enkelt inte finns någon annanstans, föreslår Miles Ward, teknisk direktör för Google-konsulterna Sada:

– API:er är ett sätt att koppla upp sig till information, och information är bara värdefull när den flödar. Om du har data som inte är tillgängliga genom ett centralt, programmerbart, utvidgningsbart gränssnitt, som inte flödar dit där det kan göra nytta, så är det dags att prioritera den satsningen.

En del applikationer kan byggas nästan helt och hållet av enbart api-anrop. Gartner kallar det för ”kombinerbar handel”, och det är ett bra exempel på den trenden, berättar Kelly Goetsch, produktansvarig på Commercetools.

Kombinerbar teknik är en förändring jämfört med det vanliga sättet att utveckla inom företag:

– Man behöver inte ett team med 200 utvecklare som utvecklar mängder med Javakod. Du vill ha skickliga rörmokare som kan få de här olika applikationerna att fungera ihop, i typfallet med en händelseförmedlande (eventing) arkitektur och API-anrop. Ju fler människor du kastar in i något sådant, desto långsammare och svårare blir det, säger Kelly Goetsch.

Vad en it-chef behöver, enligt Kelly Goetsch, är dels en katalog med de API:er som är godkända och i bruk, dels en övergripande styrningsstrategi som kan tillämpas på den API-gateway som utvecklare använder för access inom ett gemensamt säkerhetsramverk:

– Bestäm vilka api:er du vill bygga själv och vilka du vill hämta från utomstående företag. Gatewayen är ditt sätt att reglera åtkomsten till dessa api:er för dina utvecklare.

API-gateways har tidigare ofta varit hårdvara, men det förändras. Det finns välkända verktyg för API-hantering och det är en standardtjänst i alla vanliga molntjänster med inställningar för tjänstekombinering, taktbegränsning och åtkomstreglering med filtrering av ändpunkter och instanser – ofta ner till enstaka interaktioner med ett API – som kan ge besked om användning, felprocent och andra mätbara mått. Det finns också fristående tjänster som APImetrics som kan mäta prestanda och tillgänglighet hos offentliga API:er.

API:er i det fria

Första steget i fastställandet i en formell API-strategi är att undersöka vilka api:er som redan är tillgängliga och i bruk. Efter det bör man förvissa sig om att de är dokumenterade och upptäckbara.

– Det kan bli mycket repetition i en organisations olika fickor, noterar Abhinav Asthana. Han föreslår att it-chefer inleder diskussioner med utvecklarna för att höja medvetenheten om API-hantering.

Dessutom är det lätt att glömma API:er som redan är i bruk. När en stor hälsovårdsorganisation byggde upp en API-katalog började det med en lista på 450 API:er. Men i slutänden blev det nära fyra tusen. Verktyg som tittar på proxies och loggfiler och annat underlag kan upptäcka api:er som redan finns i företaget och sedan generera OpenAPI-beskrivningar.

När man väl har en katalog så ska man inte använda den enbart för att hålla reda på publicering och användning av API:er, utan också för att lägga upp en mer strategisk policy för livscykelhantering. Den bör omfatta hantering av värdeminskning – en utomstående API-leverantör kan göra omfattande förändringar eller lägga ner helt och hållet.

En del it-chefer har börjat anställa API-arkitekter och bygga upp expertiscenter för API:er för att hålla API-policyn aktuell. Det är särskilt viktigt att ha koll på hur api-användningen sprider sig i organisationen, att säkerställa att system som driver interna api:er har tillräckliga resurser (särskilt med tanke på att robotiserad processautomatisering kan skapa ett api från ett Excel-ark) och att säkra dem, så att de inte exponerar data för alla och envar, vilket har hänt med tjänster från Bumble och Equifax.

– De sårbarheterna visar hur mycket moderna appar är beroende av API:er och hur komplicerat det kan vara för en organisation att se till att alla dessa api:er är privata och låsta, säger Winston Bond, teknisk direktör för Emea på Digital.ai:

– En app som bygger på en skock molnbaserade mikrotjänster, som Mumble, exponerar en massa förbindelser som vanligtvis är skyddade av en brandvägg.

Kostnad, tilltro och regelefterlevnad

Det finns ytterligare ett skäl att ha koll på API-användningen: kostnadsstyrning. API:er ses ofta som vilken molntjänst som helst, men de är ofta mindre synliga, och användningen kan vara oförutsägbar, vilket kan leda till att kostnaderna skenar.

– Eftersom prissättningsmodellerna är komplexa, de utgår från användningen, och it-cheferna kan inte styra hur företaget konsumerar applikationen – allt du kan göra är en prognos, säger Eric Christopher, vd för Zylo.

Som it-chef måste man veta hur mycket ett API kommer att kosta i förlorade affärer och andra störningar om den är nere, eller inte fungerar i normal takt, och vem som bär ansvaret om det uppstår problem. Tjänstenivåavtal (SLA:er) är standard, men de måste vara tillräckligt detaljerade för att omfatta de api:er som du använder. Tjänstenivåmål, erfarenhet och resultatbaserade avtal kan vara mer lämpliga, för det är utfallet snarare än anslutningen som är viktig.

Syntetisk transaktionsövervakning kan visa problem med drift och prestanda, men alltför få API-leverantörer erbjuder testkonton för produktion eller verifierar sin egen dokumentation. Det säger David O’Neil, vd för APImetrics:

– Hur kan du faktiskt förvissa dig om att något av detta faktiskt fungerar om du inte kan testa det i produktion. Hela din produktionsmiljö kan gå ner, men du får inte veta något på fem timmar.

OpenID Foundation utvecklar något som kallas för ”förtroenderamverk” baserat på drifttid och hastighet inom olika områden för api:er i molninfrastruktur, ekonomiska tjänster och öppen bankverksamhet, men för tillfället ”finns det inget där ute för offentlig skattning och rankning som är kuraterat, som alla i branschen kan vara överens om”, säger David O’Neil.

Frågorna om upptäckbarhet, kvalitet och regelefterlevnad har blivit allt viktigare för api:er i reglerade branscher som bank, hälsovård och offentliga tjänster.

David O’Neil räknar med att det komma att uppstå konsensus om hur man ska mäta och övervaka reglerade api:er, från att mäta latens till att utvärdera dokumentation och validera api-uppläggets kvalitet och regelefterlevnad:

– Vi behöver ha något slags poängsättningssystem och en policygrupp som fastställer detta för hela branschen. En del saker som händer med api:er kommer att bli globala, transnationella saker som behöver baseras på en överenskommen uppsättning standarder.

En prioritet för framtiden

Livscykelhantering för API:er är fortfarande på barnstadiet i många organisationer. Det säger Dion Hinchcliffe, vice vd och chefsanalytiker på Constellation Research:

– Molnrörelsen håller definitivt på att göra mikrotjänster och containrar till första klassens medborgare i it, Nu börjar alla de här frågorna ställas på allvar och på högsta nivå.

Det är ingen överraskning att reglerade branscher som finans och hälsovård har kommit längst, säger Dion Hinchcliffe. Ett amerikanskt nätverk för hälsovård får redan en fjärdedel av sina intäkter genom API:er, och räknar med att det ska gå upp till hälften inom några år. Med en sådan potential för intäkter har ”API-utformning, urval, hantering och styrning plötsligt blivit angelägenhet på ledningsgruppsnivå”, säger Dion Hinchcliffe.

It-chefer som låter avdelningarna i verksamheten sköta sin egen mjukvara och teknik kommer att ha den sämsta insynen i api-användning, säger Eric Christopher på Zylo:

– Där man hör vd:n säga att ”ditt jobb är att känna till allt som händer i verksamheten och att gå in och fö avdelningarna att fungera bättre med hjälp av it”, där är det som man kan börja se förståelse för API:er och insyn.

Som it-chef vill jag veta: Det här är alla mina externa beroenden, detta är alla mina interna beroenden, och det är så här som de hänger ihop, säger Abhinav Asthana på Postman:

– Har man det får man bra dragkraft. Då vet jag hur jag ska sätta samman mina utvecklingsteam, jag vet vilka byggbitar som finns och jag kan göra upp en färdplan för allt detta mer effektivt.

Motsatsen stämmer också, varnar Abhinav Asthana:

– Jag vill tro att om du fortfarandet inte har förstått att alla dessa saker är på gång, och att lösningen ligger i en API-strategi, då kan du hamna i massor av problem. Du kan se det som en fråga om utvecklarproduktivitet, som en fråga om regelverk eller en fråga om persondataskydd. Allt detta finner sin lösning i en API-strategi.