De opmars van de API-economie

De opmars van de API-economie
Met Application Programming Interfaces (API) ontsluit je op grote schaal diensten, informatie en applicaties. Aan welke voorwaarden moet je voldoen om een API-strategie te bepalen? ‘Elke strategie dient te beginnen met de vraag: Wat is zinvol voor onze business?’
Hessel Pijpker
Mobiele applicaties zijn uitgegroeid tot een drijvende kracht achter de verandering van ons digitale landschap. Niet alleen staan ze aan de wieg van nieuwe softwarecategorieën, ook hebben ze de manier veranderd waarop we toegang krijgen tot en gebruik maken van content en diensten. De kracht van mobiele applicaties ligt echter zelden in de applicatie zelf, maar in dat waarmee ze verbonden zijn: in de data die ze uit achterliggende systemen kunnen onttrekken. De succesvolste apps maken onderdeel uit van een ‘omnichannel’-strategie waarin de distributie via mobiele platforms, internet en partners een cruciale rol speelt. In die strategie staat de Application Programming Interfaces (API) centraal, en niet zozeer de individuele apps die door de API aangedreven worden.
Met de API worden diensten, informatie en applicaties op steeds grotere schaal ontsloten. Er zijn tal van praktijkvoorbeelden: van de energiemeters die ieder apparaat in je huis aflezen, tot aan de vele vergelijkingssites die je de beste verzekering, hotel of vliegticket laten kiezen. API’s faciliteren de toegang tot de digitale infrastructuur en vormen de sleutel tot de communicatie tussen apparaten, applicaties en data. Vandaag de dag is er sprake van een opkomende ‘API-economie’ waar je compleet nieuwe businessmodellen op kunt bouwen. De data-economie en de API-economie zijn sterk aan elkaar verwant en onlosmakelijk met elkaar verbonden. Hoewel de meerderheid van de API’s rond data draait, zijn API’s ook een cruciale factor voor het creëren van ‘moderne applicaties’: applicaties die verder gaan dan de uitrol van een mobiele app of webapp alleen. Moderne applicaties worden namelijk niet beperkt in schaalbaarheid, kanaalkeuze of de kennis van de IT-afdeling. Een moderne applicatie vormt juist de brug naar een breed scala aan databronnen, diensten, apparaten en andere applicaties die samen de systems of systems vormen. Niet elke organisatie is echter een Amazon, Google of Facebook. Deelname aan de API-economie hangt grotendeels samen met de visie van je eigen organisatie op moderne applicaties en de wijze waarop je wenst deel te nemen aan de data-economie. Sommige aspecten van API’s zullen sterker draaien om moderne applicaties, waar andere aspecten zich exclusief richten op de data-economie.
Vier ontwikkelingen
Er zijn vier ontwikkelingen geweest die de toename van het API-gebruik hebben bespoedigd en die belangrijk zijn om de rol van je eigen organisatie in de API-economie te leren begrijpen:
1) API’s creëren ruimte voor nieuw businessmodel
Informatie wordt door meerdere partijen met elkaar gedeeld en geïntegreerd op één plek om het bereik onder consumenten te vergroten. Denk bijvoorbeeld aan vergelijkingssites die de aanbiedingen van een groot aantal vliegtuigmaatschappijen overzichtelijk maken, waarbij je vaak niet eens de vergelijkingssite hoeft te verlaten om de reis te boeken. Door het grote aanbod is het voor vliegtuigmaatschappijen lonend om via API’s actuele reisinformatie te delen met derde partijen, zodat de tickets via meerdere kanalen onder de aandacht worden gebracht. Deze derde partijen bouwen dus hun businessmodel op dat van de vliegtuigmaatschappij, die een grotere afzet creëert zonder zelf interactie te hebben gehad met de consument.
2) Applicatiebeheer geen interne aangelegenheid meer
Omdat met API’s bepaalde gevoelige bedrijfsinformatie openbaar gemaakt wordt, is het voor de API-distributeur van belang om het gebruik ervan goed te beheren en monitoren. Bij voorkeur weet de API-aanbieder dan ook of de gebruikers over de meest recente versie beschikken, of ze nieuwe functionaliteiten optimaal inzetten, of er een plotselinge piek te zien is in hun API-gebruik en of ze geautoriseerd zijn voor het gebruik van specifieke bedrijfsinformatie. Voorheen werden bedrijfsapplicaties ontsloten via de interne ‘service oriented architecture’. Middels web-API-management wordt dit nu verder doorgetrokken naar de buitenwereld, en zo ondersteunt API de verschuiving van ‘systems of record’ naar ‘systems of engagement’.
3) Decentralisatie van informatieopslag
Enterprisesystemen zijn ontworpen rondom discrete stukjes informatie, zoals klantgegevens en productieorders, plus de databases en automatiseringsprocessen die daarbij horen. Vandaag de dag is het echter steeds moeilijker om met deze systemen een competitief voordeel te behalen nu ze deels ingehaald worden door technologieën als SaaS en de Cloud. Daardoor verschuift het competitieve voordeel naar de kwaliteit van de informatie die in de systemen verscholen liggen. Met systems of engagement is de opslag van informatie gedecentraliseerd en kan gebruik worden gemaakt van cloudtechnologie om interacties tussen werknemers, businesspartners en derde partijen op een laagdrempelige manier te faciliteren. De samenwerking tussen diverse partijen leidt op deze wijze tot hoogwaardigere informatie.
4) De juiste API-combinatie vinden
API’s vormen de sleutel tot de toegankelijkheid van informatie die beschikbaar gesteld wordt. Het is voor een organisatie cruciaal om zicht te houden op wie welke informatie kan inzien, aangezien de meeste betrokkenen over een combinatie van verschillende typen API’s beschikken. Er bestaan API’s die puur intern gebruikt worden, vaak ter bevordering van de productiviteit van de werknemers. Daarnaast zijn er API’s gericht op een select aantal businesspartners, om cruciale data te synchroniseren of om het bereik onder een specifieke doelgroep te vergroten. Ten slotte is er de relatief nieuwe ‘open API’, die door iedereen te gebruiken is en daarmee een brede doelgroep bereikt.
Randvoorwaarden
De veelzijdigheid van API’s biedt mogelijkheden voor organisaties van elk formaat om nieuwe markten aan te boren. Zo stelt IBM de rekenkracht van haar Watson-computer via een API beschikbaar aan ontwikkelaars. Derden kunnen apps ontwikkelen voor allerlei doeleinden: in de gezondheidszorg voor het bepalen van de juiste behandelingsmethode, op culinair gebied om nieuwe recepten te ontdekken op basis van de beste ingrediëntencombinatie. Hoewel de druk om een API-strategie te bepalen toeneemt nu meer en meer organisaties er in meegaan, dienen er een aantal randvoorwaarden goed in acht gehouden te worden:
• Begin met het bepalen van je eigen rol binnen het open web en weet in welke businesscontext je organisatie opereert. Voor de een speelt open data een grote rol binnen de bedrijfsomgeving. Voor andere organisaties kan adaptive intelligence een belangrijke drijfveer zijn, waarbij realtime data vanuit meerdere richtingen met elkaar uitgewisseld worden. Van belang hierbij is een goede datamanagementoplossing die data-aggregratie vanuit meerdere systemen stroomlijnt. Deze kun je vervolgens via een API beschikbaar stellen.
• Start met het uiteenzetten van een strategie voor de digitale ervaring die je de doelgroep wilt bieden. De digitale ervaring dient over meerdere kanalen uniform en consistent te blijven, zoals smartphones, tablets, games, smarttv’s of bijvoorbeeld Google Glass. Deze aanpak helpt je de specifieke vereisten te definiëren voor de opzet van je API-strategie.
• Het bouwen van een mobiele app is geen doel op zich, maar maakt onderdeel uit van de uitrol van een moderne applicatie, een applicatie die per definitie omnichannel is. Op deze wijze kan de ondersteuning van nieuwe kanalen relatief simpel worden toegevoegd.
• Tijdens de vertaling van bovenstaande context naar een goede API-strategie, dien je ervoor te zorgen dat je ontwerpstrategie in lijn is met je businessstrategie.
• API’s en beveiliging zijn niet los van elkaar te zien. API-beheer voor securityprofessionals is daarom een cruciale factor in elke aanpak. Zorg er dus voor dat je te allen tijde je collega’s van security betrekt bij de vorming van een API-strategie.
• Iedere API dient consistent te zijn met de achterliggende ontwerpstrategie. Kies om te beginnen de technologie en protocollen die je gebruikt om je API’s aan te bieden, daarna welke messaging style (RPC of ‘document style’) je gebruikt. Kies vervolgens een aanpak voor transaction handling en error handling en bepaal daarna hoe je de API’s toekomstbestendig maakt, onder meer op het gebied van veiligheid.
 
KADER: Master password verleden tijd met OAuth
OAuth, een open protocol bedoeld voor API-autorisatie, regelt ‘handshakes’ tussen desktopapplicaties en/of webapplicaties en wordt gebruikt wanneer een API-distributeur wil weten wie met het systeem communiceert. In plaats van te vertrouwen op een master wachtwoord, creëert OAuth een token die één applicatie toegang geeft tot één API namens één gebruiker. Op deze wijze hoeven bijvoorbeeld smartphonegebruikers geen wachtwoord voor elke app in te voeren, maar wordt er gebruik gemaakt van een token waarvan de duur na een bepaalde periode verstrijkt. Elke versie van OAuth ondersteunt diverse authenthicatiemethodes voor API-clients. De simpelste is een ‘bearer token’, een grote serie willekeurige getallen die na elke request middels SSL-encryption verzonden worden. OAuth ondersteunt ook een ‘signature’-optie, die zowel een token als een secret gebruikt. Wanneer een request verzonden wordt die een OAuth signature bevat, wordt de data gedecodeerd met behulp van het token secret, maar het secret zelf wordt nooit over het netwerk verzonden. Dit zorgt ervoor dat het tokensecret ook zonder SSL nooit toegankelijk is voor onbevoegden. De beste manier waarop je OAuth tokens kunt beveiligen, hangt af van hoe ze gebruikt worden.
• Wanneer bearer tokens gebruikt worden, dienen ze vanaf de server versleuteld te worden als een ‘one way hash’.
• Wanneer signatures gebruikt worden, moeten de tokens en secrets gelezen kunnen worden door de server, dus versleuteld worden met behulp van ‘field level database’-encryptie.
• Naarmate technologie verandert, komen hier mogelijk nog vereisten bij. De enige constante is zorg en waakzaamheid.
 
KADER: API-strategie geeft geen garanties
Informatie, producten en diensten worden toegankelijk gemaakt met een API. De API is echter niet het einddoel. De volgende stap is het wachten op iemand die nieuwe apps of websites koppelt aan de API zodat deze van waarde wordt voor de doelgroep. En wanneer de doelgroep applicaties gebruikt die ondersteund worden door de API, wordt deze van waarde voor het bedrijf. Elke API-strategie dient daarom te beginnen met de vraag: Wat is zinvol voor onze business? De overwegingen daarbij zijn:
• Wie gaat de API gebruiken? Interne medewerkers, business partners of externe ontwikkelaars?
• Welke assets kunnen beschikbaar worden gesteld via een API?
• Wie krijgt toegang tot de assets?
• Op welke wijze dient de API de assets beschikbaar te stellen?
• Welke soorten applicaties dienen gebouwd te worden met behulp van deAPI?
• Wat zal ontwikkelaars motiveren om juist deze API in te zetten bij het ontwikkelen van applicaties?
• Hoe gaat het publiek de applicaties ontdekken?
Hoewel een strategie zekerheden geeft, leert de ervaring dat er veel obstakels op de weg liggen bij het ontwikkelen van API’s. Een gecalculeerd risico nemen om de mogelijk onbekende voordelen van een API te verzilveren, is dan het overwegen waard.
 
KADER: Vier API-businessmodellen
Al sinds 2005 zijn vier businessmodellen voor API’s te onderscheiden, en binnen deze businessmodellen is steeds meer diversiteit ontstaan.
• Gratis
• Ontwikkelaars betalen niets om de API te gebruiken. Voor API-distributeurs is de ontsloten informatie niet waardevol genoeg om deze exclusief voor zichzelf te houden.
• Ontwikkelaar betaalt
• Ontwikkelaars betalen een bepaalde som voor het gebruik van een API. De informatie die door de API-distributeur ontsloten wordt, dient bruikbaar en van aantoonbare waarde te zijn om een ontwikkelaar hiervoor te laten betalen.
• Ontwikkelaar ontvangt
• De API-distributeur biedt ontwikkelaars een deel van de omzet of een bepaalde som om de API te gebruiken. De ontsloten informatie moet een bepaalde waarde genereren om als ‘incentive’ te dienen voor ontwikkelaars die de API gebruiken.
• Indirect De API ontsluit informatie die indirect iets wezenlijks bijdraagt aan het businessmodel. Denk bij retailers bijvoorbeeld aan het zoeken naar de dichtstbijzijnde winkel of online productcatalogi. Dit zijn API’s die als doel hebben het aantal winkelbezoeken of online verkopen te vergroten.
 
 
Hessel Pijpker is Executive IT Architect (http://nl.linkedin.com/in/hesselpijpker).

Tag

API

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag