Hvordan kommer du godt i gang med et åbent API?
Du har taget beslutningen; dit API skal åbnes op for omverden.
For at undgå unødvendige hovedpiner for dig og dit team, har vi samlet nogle af de barrierer, du kan møde på din vej mod et åbent API. På den måde kan du måske undgå dem.
Det handler om nye roller, nye perspektiver og budgetstyring – alle de afledte effekter af at blive et produkt.
1. Investering
Der er to typer udgifter relateret til at bygge et åbent API – udviklingstimer og infrastruktur/systemer.
Prisen er et element, der skal håndteres for at sikre, at det hele løber rundt. Skulle du løbe tør for budget og tillid fra ledelsen halvvejs igennem opbygningen af dit API, så har du måske ingenting at tilbyde forbrugerne. Omvendt kan det også være et problem konstant at arbejde på indtægtsskabende end points på bekostning af kernefunktionalitet til forbrugerne.
Det er derfor essentielt at forstå balancen mellem langsigtet udvikling, direkte indtægtsskabende features og forretningens budget og strategi.
God budgetstyring kan bidrage til at sætte de rigtige forventninger for udviklingsprocessen og, som absolut minimum, sikre et MVP, der kan afsøge markedet. Et MVP vil give noget feedback til forretningen, der kan allokere nye budgetter og tilpasse den overordnede strategi.
Så længe det drives som en iterativ proces, baseret på brugerfeedback og rigtige brugerdata, er du på det rigtige spor.
Nøglen er naturligvis, at API’et over tid giver et positivt ROI. Ikke bare i tilføjet værdi til stakeholders omkring API’et, men i reelle aktiver og ressourcer, der kan hældes direkte tilbage i udvikling.
Sådan sikrer du at API’et får et langt og succesfuldt liv.
2. Roadmaps og lifecycles for et åbent API
Hvis vi skal behandle API’et som et produkt, så giver det mening at bruge roadmaps og product lifecycles som værktøjer i udviklingsprocessen. Et defineret MVP og et roadmap til at styre den videre udvikling har flere store fordele:
- Først og fremmest modvirker processen scope/feature creep. Ved at fastsætte en kurs af funktioner, værdier og tilføjelser, kan du undgå at udvikle mere end det strategisk nødvendige. Det betyder, at du bedre kan styre begrænsede ressourcer og sikre at forbrugerne får de ting de har brug for, i prioriteret rækkefølge. Typisk vil en afledt effekt af den tilgang også være en mindre rodet kodebase, der er nemmere at udvikle på, dokumentere og vedligeholde.
- Ved at begrænse udvikling til de features, der er på roadmappet, sikrer du dig imod overflødige end points og features der aldrig bliver helt færdige. Du sikrer et mere strømlinet åbent api med alt hvad det indebærer af øget sikkerhed og reduktion af feature fatigue. Dette er særligt vigtigt, fordi dit API er en kontrakt mellem dig og aftagerne, og når først du har frigivet en feature, så er det en tung proces at trække den tilbage – særligt når dit API er åbent, og du ikke kender alle aftagerne.
- Ved at implementere en proces til at styre lifecyclen på din applikation, så den stemmer overens med de processer, der findes i for eksempel ITIL eller tilsvarende, kan du sikre langsigtet værdiskabelse og optimal brug af begrænsede ressourcer. Det vil sikre dit åbne API den lange levetid og den succes, det fortjener.
3. Den omvendte udvikler/forbruger relation
Det klassiske forhold mellem udviklere og forbrugere kunne se nogenlunde sådan ud:
”vi byggede den her fantastiske ting – hvordan får vi folk til at ville have den?”
Desværre er den tilgang ikke altid effektiv, når det kommer til API’er. Ved at behandle et åbent API som et produkt, vender du dette forhold på hovedet. I stedet bliver det til:
”Folk vil virkelig gerne have denne feature og kodebase – hvordan bygger vi noget fedt, der er nemt at arbejde med?”
Iteration og udvikling bygger i den perfekte verden altid hen mod forbrugerens behov. Iterationer på feedback fra use cases fra den virkelige verden, vil altid give bedre og mere tilpassede kodebaser. Og typisk sikre en højere grad af støtte fra folk omkring projektet. I det her tilfælde kommer forbrugeren først og teknikken følger efter.
Det er selvfølgelig ikke altid tilfældet. Et eksempel kan være meget specialiserede API’er eller API’er, der implementerer eksperimentelle systemer. I de tilfælde omtales API’et alligevel ikke typisk som et produkt. Med andre ord, er det undtagelsen, der bekræfter reglen.
4. Et åbent API skal være (for)brugervenligt
Et produkts succes går hånd i hånd med (for)brugervenlighed. Medmindre du er den eneste leverandør i et nichemarked, så er brugervenlighed essentielt for dit produkts konkurrencedygtighed. Det sagt, så er der nogle særlige ting, der gør sig gældende når det kommer til API’er:
- API’et skal have en god udvikler-oplevelse. Det betyder at det skal være nemt at sætte en konto op og styre brugerdata. Det skal være nemt at beskrive (kernefunktion der kan forklares) og nemt at (for)bruge (god dokumentation). Hvis ikke du sikrer at API’et er nemt at forbruge, kommer du til at bruge en masse tid på at hjælpe dine aftagere. Det koster skalerbarhed, og du risikerer helt at miste nogle aftagere, fordi de vælger simplere løsninger.
- API’et skal markedsføres ordentligt og promoveres inden for den rigtige kontekst. At omtale et API, der grundlæggende bruger eksisterende systemer og teknologier en smule smartere, er ikke (nødvendigvis) ”disruption”. Den type markedsføring kan både tiltrække brugere og skræmme dem væk – afhængig af, hvad de leder efter. Markedsføringen skal matche branchen og API’et på budskaber og konceptuelt.
- API’et skal være unikt. Hvis ikke du har nogle stærke differentierende parametre, er det svært at vinde markedsandele. I tilfældet med API’er, kan det for eksempel være en brugergrænseflade designet til en specifik arbejdsgang, eller at løsningen er nyskabende eller noget tredje. API’et skal have noget unikt, der gør det værdifuldt for interne og eksterne forbrugere.
- API’et skal være sikkert. Værdien af sikkerhed kan ikke undervurderes. Det er selve fundamentet for et åbent API.
Før du går i gang:
Tilfredse kunder, større omsætning, øget vækst, mindre arbejde… Det lyder næste for godt til at være sandt, ikke? Før du kaster dig ud i et åbent API, anbefaler vi, at du får tænkt de her punkter godt igennem:
1. Definer forretningsroller og tilpas organisationen omkring det åbne API
Det får nok hårene til at stritte på en del udviklere, men den bedste måde at indarbejde ”Api som produkt”-tanken, er at tilpasse sig klassiske forretningsroller i udviklerteamet. På den måde sikrer du, at dit team tænker, taler og agerer som resten af forretningen.
Der vil typisk være brug for følgende roller:
- En teknisk produktansvarlig der kan styre API’et i en retning, der matcher forretningens strategi og planer
- En kommercielt ansvarlig, der kan sælge API’et til partnere og kunder samt definere, hvilke indsatser der skal til for at støtte eksterne klienter
Ved at definere de to roller, kommer du langt med professionaliseringen af dit API. Der er naturligvis andre roller omkring API’et, men de to er oftest de sværeste at få på plads.
2. Udviklere er sandsynligvis meget forskellige fra dine andre kunder
Alle kunder er grundlæggende forskellige, men udviklere har som regel en række fælles personlighedstræk.
Fokus på dit åbne API skal være på at gøre det nemt for udviklerne i den anden ende. For REST API’er er det nemt selv at udvikle, men SOAP API’er kan være mere besværlige – der kan et SDK (software development kit) være en god ide. SDK’er i de mest almindelige programmeringssprog gør det nemmere og smidigere for potentielle kunder at komme i gang med at aftage det API, du udstiller.
Andre områder, der er værd at arbejde med, er dokumentation, gode udviklingsværktøjer og et stærkt community. De fleste udviklere er ekstremt kreative i deres kritiske tænkning – kan du give dem et forum, hvor de kan debattere deres tanker med ligesindede, er du allerede godt på vej til at have et succesfuldt åbent API.
Som tidligere nævnt er det en rigtig god ide at have en teknisk produktansvarlig til at lede indsatsen. De kommer med en forståelse af målgruppen, der vil gøre processen meget nemmere.
3. Hvordan kommer I til at tjene penge på et åbent API?
Det er ikke billigt at åbne dit API op, så det er vigtigt at have tænkt over, hvordan det vil bidrage til forretningen. Hvordan kommer det til at styrke virksomheden og dens produkter? Der er mange måder at tjene penge ved hjælp af et API – her er nogle af de mere almindelige:
- Den ligger lige til højrebenet – du kan tage penge for selve brugen af API’et. Den tilgang har virket godt for virksomheder som DropBox. Vær opmærksom på, at med denne tilgang skal du også bygge et system, der kan monitorere brugen.
- Øget salg af dit kerneprodukt. Ved at gøre virksomhedens kerneprodukt mere tilgængeligt og attraktivt, bliver det nemmere at sælge.
- Sælg konsulenttimer. Det kræver, at du opbygger et team af rådgivere, men det kan være et lukrativt marked at gå ind i.
- Sælg applikationer. Brug API’et som en platform til at bygge nye komponenter, som du kan sælge på en markedsplatform.
4. Vær forberedt på øgede driftsomkostninger
Hvis dit nuværende produkt er rettet mod brugere i salgsroller, og du tilføjer et modul rettet mod marketingfolk, så kan dit nuværende team nok dække den nye brugertype. Dine sælgere kan stadig pitche til CMO’en, din marketingafdeling kan stadig køre kampagner og din support kan stadig svare på deres spørgsmål.
Men når du får en helt ny brugertype – udviklere – så får du med al sandsynlighed behov for flere teknikere på dit eget team. Og det er heller ikke utænkeligt, at det eksisterende team skal igennem træning, for bedre at forstå den nye målgruppe.
Udfordringerne med at åbne et API fordelt 50/50 mellem teknik og forretning. Rob Adams skriver i bogen ”If you build it, they will come”, at virksomheder skal splitte budgettet 50/50 mellem udvikling og understøttende funktioner. Ellers kommer du nemt til at stå med et fantastisk API, der ikke får succes, fordi i ikke investerede i alt det uden om udviklerne.
Her er et udpluk af ikke-tekniske opgaver, der kræver budget:
- Markedsføring
- Sales enablement og salgssupport
- Partnerhåndtering
- Support
- Udviklercommunity
5. Sikkerhed og performance er (meget) vigtigt for et åbent API
Det er ret simpelt – sikkerhed og performance skal være i top. Når du laver strategien for et åbent API, er det derfor vigtigt at tænke ind allerede fra starten af. At åbne dit system for tredjeparts-udviklere kan potentielt være noget rod. Og – vær opmærksom på, at andre virksomheder bruger dit API som en integreret del af deres produkt. Derfor smitter det af på dem, hvis dit API er langsomt, fejlfyldt eller usikkert.
Det er et stort ansvar, så sørg for at have de punkter på agendaen i de tidlige møder med din arkitekt. Definer KPI’er og QA-processen før du starter udviklingen.
Hvis du ikke har styr på det fra starten af, kommer det sandsynligvis til at hæmme udbredelsen af API’et og dermed til at forfølge dig længe.
6. Det kan være svært at vise fremdrift internt
Det er ikke sikkert, at det er et problem i alle virksomheder, men i hårdt målstyrede virksomheder vil det være et stort problem. Chefer elsker demoer, der kan vise fremdrift. Sådan nogle er ofte centreret omkring brugergrænsefladen, fordi det er den del, ikke-teknikere kan forstå.
Udfordringen med et API er, at der ikke er nogen brugergrænseflade – det er ”kun” kode. Medmindre du er udvikler, er det nærmest umuligt at vurdere fremdriften ved at kigge på API’et.
Én måde at komme omkring dette på er at bygge små applikationer, der bruger API’et. På den måde kan resten af virksomheden se fremdriften. Det er samtidig en god måde at teste API’et på – ved at sætte dig i forbrugerens stol.
Selvom fokus i sidste ende skal være på funktionaliteten og ikke på en poleret grænseflade, så kan den tilgang til udviklingen være nødvendig for at sikre støtten internt. Sørg for at planlægge tid til det i din udviklingsproces.
Afslutning
Udviklingen på området omkring åbne API’er er noget af det mest spændende på det tekniske område lige nu. Vi håber, at vi kan give inspiration og hjælp til at komme godt i gang. Skulle der være noget, der stadig volder problemer, så tag endelig fat i os her.
