API som produkt – hvad betyder det egentlig? I denne artikel giver vi svar på det (og en lang række andre) spørgsmål omkring API’er. Men først – en kort intro om API’er:
Hvad er et API?
Et API – et Application Programming Interface – er en samling funktioner som et IT-system kan udstille og som gør andre IT systemer i stand til at interagere med førstnævnte system.
Et eksempel er Google Maps’ API. I stedet for at bygge et helt navigationssystem selv, kan du betale for at bruge Google Maps API’et og de features, der er programmeret ind i Google Maps, via deres API. Dermed kan du indbygge en korttjeneste i din egen applikation.
Stripe er en anden kæmpestor virksomhed, der i høj grad er baseret på et API. De udstiller et API, som andre applikationer kan bruge til at inkorporere betalingsmuligheder i deres applikationer. Ved at bruge Stripe’s API, kan en kunde betale for din vare direkte i din applikation, og du kan lade Stripe’s API varetage behandlingen af betalingen.
På den måde er Stripe’s API en service, som gør, at du kan udlicitere betalingsfunktionaliteten i den egen applikation til Stripe.
Mange virksomheder har et API som en del af deres produktportefølje. De tager en funktion, der ville være besværlig og/eller dyr at bygge fra grunden (eller som kræver særlig viden, tilladelser eller licenser) og udstiller den som en nemt aftagelig service via et API. Det har både Uber, Airbnb og mange andre gjort.
Hvad betyder “API som produkt”?
Historisk set har et API været en feature i et produkt. Det kunne f.eks. være, at man lancerede et online bookingsystem. Dette system kunne benyttes via en flot brugergrænseflade i en browser, og man kunne fremsøge ledige tider, vælge forskellige ydelser, booke tider, tilmelde ventelister etc.
Hvis systemet blev populært, ville man på et tidspunkt få behov for at lade eksterne partneres systemer interagere med bookingsystemet, f.eks. for at udtrække rapporter, lave automatiske bookinger eller lignende. Man ville så bygge et API til bookingsystemet.
På denne måde har et API typisk været en feature, som kom til relativt sent i et systems udvikling, og det har i en vis forstand været en andenrangs feature, i den forstand at det er opstået som en eftertanke.
Fra kælder til bestyrelsesgang:
Selvom et API historisk er noget, vi taler om på et teknisk niveau, har de bevæget sig ind i virksomhedernes kerneydelser: i stedet for at et API er en feature i et produkt, så er APIet selve produktet. Hos Stripe betyder det, at det API, som håndterer alle betalinger for webshops, er deres produkt.
Adgang til deres API er den kerneydelse, du køber hos Stripe, og deres website virker kun understøttende for API’et – websitet er blevet en feature for API’et. Stripe er en virksomhedet hvor API som produkt-tankegangen er styrende.
På samme måde kunne leverandøren af et bookingsystem beslutte, at kerneydelsen var et API, som tillod kunder at indbygge et bookingkoncept i deres egne applikationer. Kunder kunne så bygge egne websites eller apps med bookingfaciliteter i. Håndteringen af bookinger ville API’et stå for.
Som en konsekvens af dette skifte er flere og flere virksomheder begyndt at se deres API som et forretningsaktiv og at behandle deres API som et produkt.
For at gøre det nemmere at forstå, hvorfor denne måde at tænke på er værdifuld, og for at illustrere hvad man kan få ud af et sådant paradigmeskifte, har vi samlet en række af fordelene.
Hvilke (forretningsmæssige) fordele er der ved det åbne API?
Fra et teknisk synspunkt er der masser af gode grunde til at åbne dit API op, men siden du er her, kender du nok allerede til dem. I stedet kommer der her et par forretningsbaserede fordele, der kan hjælpe dig med at overbevise resten af din organisation.
- Med et API kan du bygge et partnernetværk
Et stærkt netværk af samarbejdspartnere kan give dig en skaleringsmulighed, du ellers ikke har kapacitet til. Dine partnere vil kunne integrere dit produkt i deres egne produkter, værktøjer og funktioner.
Ved at skabe et stærkt partnernetværk, der bruger dit API, får du nye salgskanaler og en forlængelse af din egen salgs- og marketingafdeling. - Indtjening på konsulenttimer
Hvis din kunde er på udkig efter en feature, du ikke har, kan dit åbne API hjælpe med at lande kunden og åbne op for konsulenttimer. For enterprise-software er det ret almindeligt at have et implementeringsteam, der bygger features til særlige kunder. Så kan dit udviklingsteam fokusere på at udvikle de strategisk udvalgte features på jeres roadmap.
Hvordan er vi endt her?
Tilbage i 2002 sendte Amazons CEO, Jeff Bezos, en mail til alle deres udviklere. En mail, der har fået enorme konsekvenser for udbredelsen af åbne API’er. I mailen, der er blevet døbt ”Amazon API manifestet”, stod der (frit fra internettet):
• All teams will henceforth expose their data and functionality through service interfaces.
• Teams must communicate with each other through these interfaces.
• There will be no other form of inter-process communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
• It doesn’t matter what technology they use.
• All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
Bezos sluttede den nu berømte email med en iskold påmindelse om, hvor kompromisløs han er:
• “Anyone who doesn’t do this will be fired. Thank you; have a nice day!”
En temmelig voldsom udmelding, der viste sig at være ekstremt fremsynet. Det var en helt anden tid. Kun de absolut mest visionære tænkere i verden kunne forudse, det Bezos så.
Bezos vidste at:
Alle virksomheder er softwarevirksomheder!
Software bliver en større og større del af stort set alle virksomheders kerneforretning. Med det kommer stigende krav til features og funktionalitet. Som udviklere skal vi levere mere, hurtigere og bedre. Og helst med færre medarbejdere.
En måde at lykkes med det er, ved at bruge den software cloud– og API-udbydere stiller til rådighed allerede. Der er med andre ord ingen grund til at bygge alt fra grunden. Ved at bruge de byggesten, der er tilgængelige på nettet, sparer du en masse udviklertimer.
Tag for eksempel en webshop. Det kan være API’er, der står for lagerstyring, dynamisk prisstyring, katalogstyring, videoafspilning, fragtberegner, integration af sociale medier, anbefalede produkter eller e-commerce platform.
At have et åbent API og at designe din forretning med omkring API’er kan have mange fordele. Det kan også skabe nogle væsentlige udfordringer.
Vi har samlet nogle af de ting, vi typisk ser volde problemer:
1. Et åbent API er ikke en ”feature” – det er et produkt i sig selv
Præcis som ethvert andet produkt, skal der ligge et forretningsbehov bag et åbent API. Men der skal også være brugerpersonaer, et roadmap, en strategi og ambassadører, og ligesom alle andre produkter har et API behov for marketing, salg, support, brugermanualer og sikkerhed. De behov kan være sammenfaldende med, men er typisk fuldstændig separate fra, de behov din kerneforretning har.
Det er dog vigtigt at være strategisk konsistent og holde fast i at alle produkter støtter op om den samlede strategi.
Det er på ingen måde usædvanligt at virksomheder har en dedikeret teknisk produktansvarlig for deres API og partner/udvikler-community.
Udviklere og ingeniører vil bidrage med en masse input, men i sidste ende er det den produktansvarlige, der skal udstikke retningen.
Han skal sikre at alle funktionaliteter er i tråd med den overordnede strategi. Derfor anbefaler vi helt klart, at der er en teknisk produktansvarlig.Åbne APIer er et af de områder hvor store muligheder også kræver en høj grad af ansvarlighed. Der følger en masse nye udfordringer med og den produktansvarlige skal kunne forklare fordele og muligheder videre til forretningen.
Det er helt essentielt at forretningen forstår, hvad der skal til for at det åbne API bliver en succes. Men den produktansvarlige er også nødt til at forstå hvornår det åbne API er den rigtige løsning – og hvornår det ikke er. Både strategisk, men også timingmæssigt indadtil i organisationen.
Vi ser ofte at organisationer vælger alle de rigtige teknologier og metoder, men fejler fordi organisationen stadig ikke er moden.
2. Et åbent API lader dine kunder styre tempoet
Uanset hvor hurtigt du frigiver nye funktioner og features, vil du gøre alle kunder 100% tilfredse. Med et API giver du dine kunder (og deres udviklere) frihed til at tilpasse din software til deres behov. I stedet for om seks måneder, når du kan frigive næste version af din software.
Er din forretning rettet mod mellemstore og store virksomheder, så er det et must. Din produktstrategi skal definere hvilke API’er du skal bygge først, så du kan tilbyde den vigtigste funktionalitet hurtigst muligt.
3. Gå altid ud fra, at dit API vil være offentligt
Mange af de API’er, som udvikles i dag, udvikles med udgangspunkt i forretningens nuværende model. Det betyder at:
• API’et er (som regel) ikke brugervenligt, for dem der har designet API’et er også dem, der skal bruge det
• Dokumentationen er mangelfuld, fordi det antages, at man som bruger af API’et har adgang til at stille spørgsmål til dem, der har bygget API’et
• Sikkerheden er mangelfuld, fordi det antages, at aftagere af API’et vil være venligtsindede og have gode intentioner
• API’et er bygget med de nuværende behov for øje og kan derfor ikke håndtere væsentligt større belastning
• Der er ikke en klar definition af, hvordan API’et kan og ikke kan udvikle sig i fremtiden. Dermed kan det åbne API’s klienter tro at det aldrig vil ændre sig. Hvis det ændrer sig, så går klienterne (måske) i stykker. Det kan låse dig fast og helt stoppe dig fra at udvikle dit API
Ovenstående betyder, at API’et ikke kan åbnes op. Du kan ikke lade partnere og kunder bruge API’et, for det er det slet ikke gearet til. Det ville måske endda fremstå lidt uprofessionelt. Dermed vil API’ets design og kvalitet begrænse vækstpotentialet og muligheden for at åbne nye indtægtskilder.
Går du i stedet fra start ud fra, at dit API en dag vil være åbent, kan du bygge din software så den bedst understøtter det:
Fire hurtige tips til dit åbne API:
- Byg et brugervenligt, åbent API, som eksterne udviklere nemt kan bruge uden anden instruktion end den medfølgende dokumentation
- Sørg for, at dokumentationen betragtes som en del af API’et – som en del af produktet. Dermed sparer du og dine kolleger tid ved ikke at skulle svare på spørgsmål
- Byg sikkerhed ind fra start, så du med ro i maven kan åbne for eksterne aftagere
- Design API’et så det kan udvikle sig inden for nogle på forhånd definerede rammer. På den måde kan du videreudvikle dit API uden at ødelægge noget for eksisterende klienter
Afsluttende tanker:
For det bedst mulige resultat af API som produkt-tænkningen, må du antage, at det bliver offentligt en dag. Det vil sikre bedre definerede end points, mere effektiv routing og bedre skaleringsmuligheder. Det vil også betyde interfaces, der er veldokumenterede og -definerede – selvom de måske aldrig bliver offentlige.
Det er ikke alle API’er, der naturligt passer ind i den klassiske opfattelse af, hvad en forretning er. Nogle API er kun til intern brug, eller til meget begrænsede kundegrupper. I mange tilfælde vil der slet ikke være en direkte indtægtskilde. Men alligevel.
Alle API’er har deres egne unikke forbrugere. Derfor vil det have enorm indvirkning på forbrugerne at se dit API som et vitalt forretningsområde.
Hvad har du at tabe ved at se dit API som produkt?
Det værste der kan ske ved, at du bygger med henblik på at åbne API’et op, er at du får et API af høj kvalitet. Det vil være nemt at aftage, og udviklingsprocessen vil være mere effektiv. I sidste ende vil det føre til et bedre produkt. Det bedste der kan ske? At du ligesom Bezos vil være langt foran alle andre i din tænkning.
Dit åbne API kan give dig en markant konkurrencemæssig fordel og kan reelt transformere din forretning. I den forbundne verden, vi lever i, kan det meget vel være forskellen mellem at blive brancheførende eller at uddø.
Men – selvom det lyder lovende, så er det vigtigt at analysere alle de medfølgende udfordringer grundigt. Sådan sikrer du, at din virksomhed er klar til at understøtte transformationen – ikke bare udviklingsmæssigt. Et åbent API er et regulært produkt, der påvirker hele organisationen og ikke kun udviklerne.
