Door alle beschikbare technologieën stellen klanten steeds hogere verwachtingen aan organisaties. Bedrijven die willen meetellen, moeten gebruikmaken van een groot aantal technologieën zoals SaaS-applicaties, blockchain, AI, cloudservices en ga zo maar door. Klanten willen tegenwoordig snelle digitale ervaringen die altijd beschikbaar zijn. Krijgen ze die niet? Dan gaan ze veel liever naar de concurrent.

Digitale transformatie geen optie maar noodzaak

De Covid-19 ontwikkelingen benadrukken nog eens extra dat bedrijven snel moeten kunnen aanpassen en innoveren. Bedrijven weten dit en zijn er dan ook druk mee bezig. Echter blijkt dit in de praktijk niet zo gemakkelijk gezegd als gedaan. Veelal wordt de rol van integratie hierbij onderschat. Zo blijkt uit een onderzoek van MuleSoft dat 90 procent van de organisaties aanzienlijke integratie-uitdagingen heeft, wat kan leiden tot een negatief effect op de omzet, time-to-market en klantervaringen.

De meeste organisaties hebben ruim 500 applicaties, waarvan nog geen derde met elkaar is verbonden. Onder meer de aanwezigheid van legacy-systemen zorgt voor problemen bij het integreren van data, applicaties en apparaten. Daarnaast draaien applicaties veelal in verschillende omgevingen, zoals cloud en on-premise. En dan hebben we nog de wens van klanten om nieuwe technologieën en services te integreren om concurrerend te blijven. Met deze complexiteit verdwijnt de flexibiliteit en snelheid van IT.

API-led aanpak

Traditioneel werden integraties op ad-hoc wijze uitgevoerd via point-to-point-verbindingen. Dit betekent dat als een endpoint of applicatie verandert dat de hele integratie weer opnieuw moet worden gebouwd. Het vergt dus veel tijd en middelen om deze koppelingen te onderhouden. Ondanks dat vaak wel bekend is dat deze manier van integreren niet duurzaam is, kom ik het nog steeds tegen. Niet alleen van oudsher, maar zelfs ook bij nieuwe integraties. Enerzijds heeft dit te maken met druk en tijdslijnen (point-to-point kan sneller worden opgeleverd) van projecten. Anderzijds wordt er niet onder architectuur gewerkt, omdat simpelweg niet bekend is wat de juiste integratiearchitectuur is.

En daar komt de API-led aanpak om de hoek kijken. Doel van deze aanpak is om verschillende applicaties, processen en afnemers te ontkoppelen door gebruik te maken van standaard API’s en die te classificeren en in te zetten als:

• Systeem API’s: integratie naar systeem, applicatie of databron om data of een bedrijfsfunctie te ontsluiten middels een standaard API. Denk hierbij aan een database of een CRM-applicatie
• Proces API’s: integratie ter ondersteuning van een proces (registreren van een nieuwe klant) of het bieden van een uitgebreide service (ophalen van een 360° klantprofiel). In deze API’s worden vaak meerdere verschillende systeem API’s aangeroepen en georkestreerd om de gespecificeerde functie in zijn geheel uit te kunnen voeren.
• Experience API’s: integratie met als doel om een specifieke ervaring te bieden voor een afnemer, waarmee bepaalde wensen en beveiliging kunnen worden geïmplementeerd. Daarnaast kunnen de afhankelijkheden met andere afnemers worden geminimaliseerd. Denk hierbij aan een ander dataformaat (XML in plaats van JSON), transport (SFTP) of de hoeveelheid data (alleen het emailadres van de klant en niet zijn complete adresgegevens).

Door het toepassen van deze methode ontstaan herbruikbare integraties, waardoor deze in de toekomst niet opnieuw gebouwd hoeven te worden. Daarbij speelt API Management ook een belangrijke rol. Hierdoor kun je namelijk standaard beveiliging toepassen, monitoring en analytics. Ook kun je deze API’s beschikbaar stellen in een ‘market place’. Een van de belangrijkste doelen is dat API’s te ontdekken zijn en dat de beschrijvingen en specificaties accuraat zijn. Zo kan iemand die een integratie nodig heeft dit blokje gemakkelijk en snel selecteren, testen en toepassen. Dan is het zo simpel als het aanvragen van toegang en je kan ermee aan de slag!

Een tweede principe dat ik graag toepas is contract first. Dit betekent dat je de API eerst specificeert. Denk hierbij aan de request- en responseberichten, methode en eventuele foutcodes. Vervolgens stel je de API als ‘mock’ beschikbaar voor je afnemers. Zij kunnen deze API (met voorbeeldberichten) direct testen en er feedback op geven. Zo kun je voordat de bouw daadwerkelijk gestart is al wijzigingen aanbrengen indien dit nodig blijkt te zijn. Dit versnelt het proces, omdat je geen zaken opnieuw hoeft te bouwen. Mijn ervaring is dat dit tevens de samenwerking met front-end ontwikkelaars erg bevordert, omdat zij over het algemeen voorlopen op het back-end werk. Echter, door het toepassen van deze methode en beschikbaar stellen van een mock, kunnen ze al wel een stuk van de integratie-interactie (API-invocatie) implementeren. Ik zeg niet dat dit achteraf niet tot kleine hoeveelheden re-work kan leiden. Maar doordat er parallel gewerkt kan worden, mitigeer je wel een belangrijk nadeel van de integratie; de eeuwenoude afhankelijkheid tussen je front- en back-end. En dat is pure winst.

Kostenefficiënt en snel innoveren

Een mooi project dat de innovatiemogelijkheden en bovenstaande architectuurmethodiek met API’s illustreert, is een nieuwe manier van boodschappen doen. Ik heb het genoegen gehad om mee te mogen werken aan een pilot, waarbij het doel was om klanten een nog betere ervaring te bieden bij het doen van boodschappen. Door gebruik te maken van Near Field Communication (NFC) tussen de telefoon (of een fysieke pas) en een schaplabel kan een klant het product op een digitale boodschappenlijst en winkelmand plaatsen. Deze lijst met verschillende details was op elk moment in te zien in een app op de telefoon, waarbij ook kortingen, acties of productsuggesties naar de klant gedaan werden. Wanneer de klant dan klaar was met de boodschappen, hoefde hij niet in de rij te wachten om af te reken. Het bedrag werd namelijk automatisch afgeschreven van de rekening.

Wat uit deze beschrijving al duidelijk wordt, is dat er verschillende applicaties bij betrokken zijn; de (mobiele) app, het kassasysteem, de betaalprovider, NFC-provider en loyalty provider voor aanbiedingen.

Deze service was opgezet middels een headless architecture. Hierbij is de front-end geheel ontkoppeld van de back-end en zijn alle functies en applicaties door middel van API’s en de API-led aanpak aan elkaar gekoppeld. Denk hierbij aan experience API’s voor de mobiele app, proces API’s voor het registreren van de klant en systeem API’s op alle bovenstaande applicaties om data te kunnen ophalen, orkestreren of het laten uitvoeren van een functie (versturen van een incassoverzoek bij de betaalprovider). Door deze opzet konden er gemakkelijk nieuwe functionaliteiten worden bijgebouwd. Tevens ontstonden er herbruikbare bouwblokken die nodig waren om te kunnen integreren met andere bestaande applicaties en processen, zoals een integraal klantoverzicht.

En eerlijk is eerlijk; de investering om het op deze manier op te zetten is altijd groter dan wanneer je iets point-to-point bouwt. Maar de voordelen worden snel duidelijk wanneer er nieuwe functionaliteiten benodigd zijn of er een vraag komt om omnichannel te realiseren. Dan bestaat er ineens een landschap welke vrijwel meteen te gebruiken is. Je bent als organisatie dus flexibel, wendbaar en toekomstgericht om in te kunnen spelen op veranderende marktomstandigheden of de concurrentie. En onthoud dat hoe meer API’s er beschikbaar worden gesteld, des te meer waarde er gegenereerd wordt!

Wil je meer weten over hoe je snel kunt innoveren met API’s? Of hoe security is ingeregeld binnen de API-led aanpak? Luister dan naar de SynTouch Talks aflevering waarin dit en meer wordt besproken.