CIO, let op uw API’s!

Binnen vijf tot tien jaar heeft elke grote onderneming een team dat zich bezighoudt met het organiseren, beheren en vermarkten van de eigen Application Programming Interfaces (API’s). API’s faciliteren de snelle aanpassing van bedrijfsmodellen en maken bedrijven daarmee klaar voor het veel dynamischer concurrentieveld dat zich aftekent.

Iedereen kent wel een voorbeeld waarin Application Programming Interfaces (API’s) een belangrijke rol spelen. Het lijkt om niet meer te gaan dan enkele succesvolle puntoplossingen, een handige zet van ontwikkelaars. Salesforce.com bijvoorbeeld jongleert met API’s zodat onderdelen van de online CRM-applicatie in vele andere programma’s naar voren kunnen komen. Google en Microsoft gebruiken API’s om uitwisseling van gegevens binnen hun kantoorapplicaties makkelijk te maken. En advertenties in de browser op basis van eerder bezochte pagina’s? Het mechanisme daarachter berust ook op het gebruik van API’s. Marktonderzoekers als Gartner en Forrester Research spreken dan ook al een paar jaar over een potentieel omvangrijke API-economie. Toch dringt in de markt het besef nog niet echt door dat API’s niet alleen wat saai ontwikkelaarsgereedschap zijn, maar waardevolle bedrijfsmiddelen die een cruciale rol gaan spelen in de overlevingskansen van veel bedrijven.

 

Two Speed IT

API’s stellen een onderneming in staat functies en gegevens uit het bedrijfsproces op een toegankelijke manier beschikbaar te stellen voor intern en extern gebruik. In de huidige situatie kan de IT-afdeling maanden of jaren bezig zijn met een aanpassing op het ERP-systeem waarmee bijvoorbeeld de buitendienstmedewerker specifieke informatie kan ophalen of een speciale berekening kan maken. Met een goede set API’s moet daar straks in een paar weken of zelfs binnen dagen een app voor kunnen worden gebouwd. Komt er een verandering in de behoefte van de buitendienst, is de app ook in een mum van tijd weer aangepast.

Gartner omschrijft deze ontwikkeling als Two Speed IT. Aan de ene kant staat de klassieke software-ontwikkeling waarin veiligheid en betrouwbaarheid voorop staan en aan de andere kant zijn snelheid en flexibiliteit het belangrijkst. Die tweede vorm gaat verder dan agile softwareontwikkeling en biedt een bedrijf nieuwe mogelijkheden kansen te grijpen wanneer die zich voordoen. Om dat mogelijk te maken moet de CIO of de CDO (Chief Digital Officer) betrokken raken bij de start van elk bedrijfsinitiatief. Hij brengt IT als voorwaardenscheppend hulpmiddel in bij de strategische teams, in plaats van achteraf ingeschakeld te worden voor de technische invulling van een plan dat door anderen is bedacht. Dit noemt Gartner The Digital Transformation.

De API’s spelen een belangrijke rol in de ontwikkeling van het Internet of Things. Sensoren verzamelen grote hoeveelheden meetgegevens die voor anderen weer interessant kunnen zijn. In de Verenigde Staten zijn bedrijven er al wat verder mee dan in Europa, constateert Ep Heijting, regionaal directeur Benelux bij APIgee, producent van het gelijknamige API-managementplatfom. “Ford bijvoorbeeld weet inmiddels veel over zijn klanten door alle sensoren in de auto die gegevens over de conditie en het gebruik van de auto naar de fabriek sturen. De autoproducent werkt nu aan een open API om autobezitters op basis van die gegevens te adviseren bij de verhuur van hun eigen auto. De autoproducent draagt zo bij aan de ontwikkeling van een deeleconomie.” Een ander voorbeeld is Nike. Het sportkledingconcern heeft bedacht dat het weinig zin heeft de sensoren die ze in loopschoenen bouwen, alleen met de Nike Fuelband te laten communiceren. Het bedrijf beseft dat lang niet iedereen zin heeft speciaal met een Fuelband te gaan lopen als ze straks ook al een smartwatch en een smartphone bij zich hebben. Heijting: “Dus ontwikkelde het bedrijf een open API zodat de ontwikkelaars van apps voor smartwatches de gegevens uit de schoen kunnen combineren met andere data.”

 

Bouwen met wat beschikbaar is

De meerwaarde van deze API-economie zit in het combineren van functies en data uit verschillende bronnen. “API’s stellen innovatieve bedrijven in staat als met Lego te bouwen met wat beschikbaar is”, zegt Anthony Doerga, van het Neder­landse AppyThings. Het bedrijf dat hij ruim een half jaar geleden oprichtte met Bert van Vught, ziet een gat in de markt om bedrijven te helpen bij deze digitale transformatie. Zijn visie: “Bedrijven hebben moeite met het bijbenen van de ontwikkeling van de technologie en de reactie van de samenleving daarop. Daardoor ontstaat Digitaal Darwinisme: niet de sterkste overleeft maar degene die het slimst omgaat met technologie. En wie niet beweegt, verliest zijn positie op de markt.” Als slachtoffers van zo’n gemiste verandering noemt Doerga Kodak en busbedrijf OAD. PostNL noemt hij als voorbeeld van een bedrijf dat de noodzaak vo0r digitale transformatie wél begrijpt en steeds kijkt hoe bedrijfsmodellen moeten worden aangepast.

Doerga wil ook laten zien wat er kan door binnen het eigen bedrijf zelf concepten te ontwikkelen. Zo werkt AppyThings een bedrijfs­model uit voor een nog niet bestaande onderneming die het voor de doorsnee burger eenvoudiger moet maken de zaken rond een verhuizing te regelen. Tot nog toe moet je bij een verhuizing een plan opstellen en zelf partijen benaderen. Busje huren, verhuisdozen regelen, lunch voor tijdens de verhuisdag, verhuisberichten enzovoort. De app die AppyThings gaat ontwikkelen, brengt al die dingen bij elkaar. Er zit een tooltje in dat een vergelijking maakt van de goedkoopste of beste verhuurder in jouw buurt, toont de aanbieders van verhuisdozen en suggereert bijvoorbeeld de broodjeszaak of snackbar die een lunch langs kan komen brengen. Alle betalingen kunnen via de app lopen.

De app maakt gebruik van allerlei diensten die al via API’s aanwezig zijn op het web en combineert deze met functies van tablet of smartphone. Voor het contract bij het verhuurbedrijf kan de app een foto maken van het rijbewijs en van de bewijzen dat adres en rekening kloppen. Daardoor kan het proces bij het verhuurbedrijf sneller en ook efficiënter verlopen. De API’s van de verschillende dienstverleners maken het mogelijk hun diensten samen te brengen in de app.

Een deel van die functionaliteiten bestaat nog echter niet. Verhuurbedrijven zijn bijvoorbeeld niet allemaal zo ver dat ze hun interne processen via een API ter beschikking kunnen stellen. Daar wil AppyThings een cloudplatform voor bieden.

 

Versnelling in innovatie

AppyThings is niet de enige onderneming die zich stort op deze nieuwe markt. Ook de grotere, bekende bedrijven met hun wortels in de systeemintegratie en- ontwikkeling zien de kansen. “De API’s die nu publiek beschikbaar zijn, vormen slechts het topje van de ijsberg”, constateert Geert Batterink, managing director bij Accenture Digital. “Veel bedrijven beginnen nu voorzichtig met het gebruik van API’s voor interne toepassingen of voor gebruik met trusted partners. De web first-strategie uit het verleden is inmiddels vervangen door mobile first en dat vertaalt zich in de markt tot API first.”

Het voordeel voor bedrijven met een goede API-strategie is dat ze sneller kunnen groeien. Ze zijn flexibeler bij de ontwikkeling van nieuwe producten en diensten door het integreren van bouwstenen die al beschikbaar zijn. “Daarmee krijg je een versnelling in innovatie”, zegt Batterink. Zowel de aanbieder als de gebruiker van de API’s profiteren van het vergroten van het bereik onder klanten door van elkaars prospects gebruik te kunnen maken. Batterink: “Daarmee kunnen start-ups hun voordeel doen, maar ook gevestigde bedrijven.” Accenture ontwikkelde een capability-raamwerk om bedrijven door de voorbereidingen te helpen.

Naast het ontwikkelen van een API-strategie is het ook belangrijk een goed API-beheer op te zetten. De API’s moeten makkelijk vindbaar en goed gedocumenteerd zijn en voorzien van handig gereedschap zodat ontwikkelaars er snel mee aan de slag kunnen. Wanneer ontwikkelaars hun ervaringen kunnen delen in een community rond de API’s, helpt dat een snelle ingebruikname.

Een API-managementplatform maakt het ook mogelijk hackathons te organiseren om snel baanbrekende ideeën te genereren. Ontwikkelteams krijgen op basis van hun inlog toegang tot een beperkte set API’s en kunnen daar al hun creativiteit op loslaten.

De combinatie met analytics is erg belangrijk, vindt Batterink. De aanbieder van de API’s moet snel actuele informatie kunnen krijgen over het gebruik en de prestaties van de API’s en de apps die er gebruik van maken. In combinatie met de feedback uit de community van ontwikkelaars kan de aanbieder besluiten API’s te verbeteren of nieuwe API’s te creëren. De metingen zijn ook belangrijk wanneer een bedrijf voor het gebruik van zijn API’s een vergoeding wil vragen. Een ander verdienmodel is de API’s in te zetten om meer klanten te trekken via de apps van derden.

Aanbieders en gebruikers maken afspraken over de prestaties en het gebruik van API’s en leggen die vast in Service Level Agreements (SLA’s). Doorgaans kunnen deze worden verwerkt en automatisch geëffectueerd in het API-managementplatform. Zo kan voorkomen worden dat het achterliggende bedrijfsproces vastloopt als gevolg van een plotselinge stijging van het aantal ‘calls’ op een API, bijvoorbeeld doordat een app die er gebruik van maakt plotseling erg populair wordt. Het API-managementplatform knijpt dan gewoon de toegang tot dat proces af.

API is geen ESB

De Enterprise Service Bus (ESB) is een onderdeel van de ontwikkeling van webservices zoals die in een ­service-oriented architecture (SOA) vlak na de eeuwwisseling werden gepositioneerd als een moderne manier om verschillende, relatief los-vast gekoppelde componenten van een computersysteem met elkaar te laten communiceren. Hoewel de ESB in functionaliteit als een voorloper kan worden gezien van de API, is de uitvoering heel verschillend. De ESB is door de vele code die hiervoor moet worden ­geschreven veel minder geschikt voor het dynamisch speelveld waarin de API functioneert. Een API is niet zozeer gebaseerd op nieuw gecodeerde elementen op de software, maar configureert instellingen op het backendproces waardoor een specifieke taak uitgevoerd kan worden en de antwoorden terugkomen. In een ideale vorm heeft een API dan ook geen enkele negatieve invloed op de runtime, is zeer robuust, veilig en in hoge mate schaalbaar, eigenschappen die niet gelden voor een ESB.

RESTful versus SOAP

API’s bestaan er in twee categorieën. API’s die vooral snel zijn en makkelijk toegang geven tot data of diensten zijn gebaseerd op principes van REST (REpresentational State Transfer). De tegenhanger komt vooral kijken bij uitwisseling tussen producent en toeleveranciers in een business-to-businessrelatie; de API’s maken dan gebruik van SOAP (Simple Object Acces Protocol).

SOAP werd ontwikkeld door Microsoft in 1998 en door het World Wide Web Consortium geratificeerd in 2003. Het vormde een alternatief voor protocollen die minder geschikt waren voor gebruik in combinatie met het web zoals CORBA en DCOM. SOAP is volledig gebaseerd op XML. SOAP werd door veel ontwikkelaars te omslachtig gevonden en zo werd in 2008 REST ontwikkeld op basis van veel eenvoudiger HTTP-instructies. In praktijk heeft het gebruik van zowel SOAP of RESTful API’s ieder zijn voor- en nadelen.

API-beheer

Succesvolle toepassing van API’s vereist een API-managementplatform. Die bestaan er in vele soorten en maten. Zo hebben veel grote softwareproducenten al de kennis en het gereedschap in huis gehaald, bijvoorbeeld door de overname van een startersbedrijf dat zich hierin heeft gespecialiseerd. Microsoft nam APIphany over (2013), IBM deed dat met Cast Iron System (2010), CA lijfde Layer 7 (2013) in en Intel kocht Mashery (2013). Zij stellen inmiddels de functies van hun eigen API-management soms als dienst aan externen ter beschikking. SAP deed geen overname maar sloot vorig jaar een alliantie met APIgee, de grootste nog onafhankelijke leverancier van een API-managementsuite. SAP levert dit platform nu onder eigen naam bij zijn ERP- en CRM-portfolio.

Het aanbod van API-managementgereedschap valt ­grofweg uiteen in twee categorieën:

API-management dat voortborduurt op de ontwikkeling van webservices en de Enterprise Service Bus. Deze categorie behandelt de API’s als gereedschap voor ontwikkelaars, op dezelfde manier als de ESB dat voor het bouwen van webservices was. API-beheergereedschap dat door een aantal jonge bedrijven volledig op nieuwe leest is geschoeid. Deze tweede groep kenmerkt zich door faciliteiten die zijn gericht op het faciliteren van nieuwe bedrijfsmodellen. Dat betekent dat er rond het ontsluiten van de API’s bijvoorbeeld uitgebreide statistische analyses op het gebruik ervan kunnen worden uitgevoerd. Ook zijn er mogelijkheden om externe ontwikkelaars al dan niet tijdelijk toegang te geven tot delen van het API-platform en daar deel te nemen aan een community die rond de API’s ontstaat.

Volgens Forrester Research (2014) zijn de leidende partijen in API-management CA Technologies, SOA Software en APIgee, met als ‘strong performers’ IBM, Intel Services, WSO2, MuleSoft, Tibco, and Axway.

Gartner (2013) zet juist IBM, Axway, Software AG, CA Technologies, SOA Software en Intel in het ‘Leaders’-kwadrant terwijl APIgee, WS0O2, Mulesoft en 3Scale de ‘Visionairs’ zijn, met Intel en Oracle als ‘Challengers’.digitaal darwinisme: niet de sterkste maar de slimste overleeft

Tag

ESB

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