‘Waarom zou een onderneming ervoor kiezen om diensten van KBC Bank te integreren? Je kunt het dan uitgebreid hebben over de bedrijfswaarde van die diensten. Maar even relevant is de manier waarop bedrijven diensten en componenten voor hun platformen en apps selecteren. "Het succes van diensten wordt grotendeels bepaald door hoe vlot je ze kunt integreren, hoe rijk de API's en de documentatie zijn en door de algehele ontwikkelaarservaring", zegt Friso Geerlings (CTO van digital agency Isaac). Geerlings, gespecialiseerd in het effectieve gebruik van - veelal - open source internettechnologie in sterk geïntegreerde contexten, nam zelf de proef op de som en dook in de KBC Developer Portal. Hij heeft het over de sterke punten van de API's en schetst de ontwikkelingen voor de nabije toekomst.
Digitale diensten als verrijking voor partners
"KBC besteedt veel aandacht aan diensten die perfect passen in de workflow van ondernemingen. De fietskredietservice is daar een voorbeeld van. Ondernemingen die fietsen verkopen kunnen de fietskredietservice van KBC gemakkelijk integreren in hun digitale omgeving. Dat geeft hun verkoop vaak een aanzienlijke boost, terwijl het kredietaanvraagproces volledig door KBC wordt afgehandeld. Dergelijke diensten beschikbaar maken via een API is natuurlijk een goede manier om je bedrijfsmodel te innoveren. Maar tegelijkertijd is het ook een nieuwe manier om met je klanten te communiceren, loyaliteit op te bouwen en data te verzamelen die je servicegericht kunt gebruiken."
Om ondernemingen warm te maken voor diensten als het fietskrediet is het tegenwoordig uiterst belangrijk om rekening te houden met de ervaringen van ontwikkelaars. Je product kan fantastisch zijn, maar als het te ingewikkeld of onaantrekkelijk is voor ontwikkelaars, kun je het wel vergeten. Zij zijn degenen die het uiteindelijk moeten integreren en hun ervaringen zijn van cruciaal belang in het selectieproces. Een goede ontwikkelaarservaring met technische en digitale producten is dan ook essentieel om met een dergelijke strategie succes te hebben. Vergelijk het met het belang van gebruikerservaring, maar dan voor technische producten", legt Geerlings uit.
Zes vuistregels voor ontwikkelaarservaring
Om de kwaliteit en maturiteit van ontwikkelaarservaring te garanderen en te beoordelen, hebben ze bij digital agency Isaac zes vuistregels:
- Eenvoudige experimenten: is er een 'explore and play' Sandbox en in hoeverre gedraagt die zich als een productieomgeving?
- Het 3:30:3-principe: kun je in 3 seconden begrijpen wat het platform of de dienst doet? Kan ik in 30 seconden een test doen en heb ik binnen 3 minuten een eerste waardevol resultaat?
- Gelaagde documentatie: krijgen ontwikkelaars en product owners snel de belangrijkste informatie? En komen ze te weten welke functionaliteiten een platform of dienst biedt en wat de meerwaarde daarvan is? Scrum teams kijken naar andere dingen dan de gespecialiseerde ontwikkelaar die uiteindelijk voor de integratie zal zorgen. Daar moet je rekening mee houden in de documentatie.
- De API-triade: op welke niveaus kun je in interactie gaan met het platform en de diensten? Is het beperkt tot REST, of worden de andere twee opties Webhooks en GraphQL ook aangeboden?
- Beschikbaarheid en traceerbaarheid: in welke mate zijn diensten met SDK's en plug-ins beschikbaar op platformspecifieke marktplaatsen, zoals Magento, en op public cloud serverloze integratieplatformen (ook vaak iPaaS genoemd), zoals Azure of Amazon?
- Beschikbaarheid van informatie: is de informatie verstopt op de eigen website of is ze ook breed toegankelijk op websites en community's waar veel ontwikkelaars aanwezig zijn, zoals Github en Stack Overflow?
3:30:3-principe sterk toegepast
"Als we kijken naar de manier waarop KBC probeert aan te sluiten op workflows van ondernemingen, bijvoorbeeld met het fietskrediet, dan is het interessant om in te zoomen op twee aspecten: het 3:30:3-principe en de API-triade. Bij de toepassing van het 3:30:3-principe vallen drie dingen echt op. Ten eerste wordt beknopt en vanuit een businessperspectief uitgelegd wat je van de API kunt verwachten. Daarnaast besteedt KBC veel aandacht aan de testbaarheid van de API. De Partner Hub is daar een goed voorbeeld van. Daar kunnen ontwikkelaars ook zonder integratie testen en volop experimenteren met de nieuwe Sandbox-functionaliteit. Ten slotte wordt er context gegeven voor het eerste API-testresultaat, zodat de gebruiker gemakkelijk kan beoordelen wanneer het goed of fout gaat en hoe de eigen software daar gemakkelijk op kan reageren. Naar onze mening is de toepassing van het 3:30:3-principe een van de krachtigste middelen die je kunt gebruiken voor een goede ontwikkelaarservaring. Als je dat, zoals KBC, al goed gedaan hebt, dan heb je al een grote stap gezet", benadrukt Geerlings.
API-triade
Geerlings gaat ook in op de API-triade: "Als de API-triade in zijn meest volledige vorm wordt gebruikt, kun je op drie niveaus met een platform of dienst in interactie treden. Het eerste niveau is REST, dat betrekking heeft op het synchroon verzenden en ontvangen van informatie. Het tweede niveau is Webhooks die (asynchrone) pushberichten van de service versturen in geval van statusupdates of andere relevante gebeurtenissen, zoals het al dan niet verkrijgen van het fietskrediet. Het derde niveau is GraphQL, waarmee gebruikers naar eigen inzicht specifieke data kunnen opvragen via query's. Bijvoorbeeld, als je wilt weten hoeveel fietskredieten er zijn afgesloten in een bepaald gebied, in een bepaalde periode, of tot wanneer de kredieten lopen. Informatie uit de GraphQL API kan zeer waardevol zijn voor de dienstverlening aan de eindklant, maar voor veel diensten en digitale producten staat die nog in de kinderschoenen."
Tweerichtingsverkeer tussen aanbieder en gebruiker
Als je mij zou vragen waar we naartoe gaan, denk ik dat de verrijking van API's volgens de API-triade de volgende grote stap is voor veel bedrijven om de ontwikkelaarservaring te verbeteren. De informatie die je met GraphQL beschikbaar kunt maken, wordt nu vaak in portals en dashboards weergegeven. Voor zowel de aanbieder als de gebruiker van de API is het waardevol om dit uit te wisselen voor query's in de GraphQL API. Zo kan de aanbieder beter aan de verwachtingen voldoen. En het is gemakkelijker voor de gebruiker, omdat hij query's kan gebruiken in plaats van te worstelen met vaak ingewikkelde en handmatige filters in dashboards en portals".
Tweerichtingsverkeer is het motto, zegt Geerlings: "API's bevorderen de openheid en de mogelijkheden van diensten. Daar wil je zo goed mogelijk gebruik van maken. Het is goed denkbaar dat de verkoper van de fietsen graag contact wil met een klant nadat die met succes een fietskrediet heeft afgesloten. Het is dan erg handig als hij die gegevens met een query kan opvragen via de GraphQL API bij KBC. Met het gebruik van GraphQL vindt de aanbiedende partij altijd direct een antwoord in de data die beschikbaar is."
Het potentieel van Azure Logic Apps en AWS AppFlow
Hoewel de API-triade veel mogelijkheden en voordelen biedt voor een bedrijf, ziet Geerlings ook veel werk op de plank voor ontwikkeling. Die rijkdom van REST, Webhooks en GraphQL zorgt ook voor een hoge integratie. In dat geval heb je in feite je ontwikkelaarservaring als dienstenleverancier, maar speel je niet echt in op de populariteit van low-code ontwikkeling of de wens om 'zo snel mogelijk resultaat' te hebben. Steeds meer bedrijven bouwen hun integratie- en businesslaagfunctionaliteit op de grote public cloud serverloze integratieplatformen. Denk aan Azure Logic Apps integraties en AWS AppFlow. Die kun je moeilijk links laten liggen. Het ligt dan ook voor de hand om boven op je API SDK's en plug-ins te ontwikkelen, die je aanbiedt op die public cloud serverloze integratieplatformen en op bekende platformspecifieke marktplaatsen, zoals Magento Commerce, Salesforce Commerce Cloud, CommerceTools en WooCommerce."
Geerlings vervolgt: "Een groot voordeel van zichtbaarheid in dat soort stores is dat het de nieuwe plek is waar bedrijven op zoek gaan naar interessante integraties en connectoren. In tegenstelling tot de on-premise integratieplatformen (zoals Oracle, Camel, Dell Boomi en IBM), waarvoor de connectoren meestal alleen op protocolniveau beschikbaar waren, creëren de public cloud-platformen nu marktplaatsecosystemen waarop je als dienstenleverancier onmiddellijk beschikbaar kunt zijn met je business service. Een bedrijf als Stripe bijvoorbeeld, was al heel vroeg aanwezig in betalingen op Azure. Voor veel bedrijven liggen daar op dit moment kansen."
Tot slot zegt Geerlings: "Ik word enthousiast als bedrijven zoals KBC hun technische producten goed presenteren en duidelijk goed nadenken over de ontwikkelaarservaring. Het is gewoon heel leuk en interessant om te zien hoe het evolueert. Zeker met de positie die Azure al heeft veroverd en de weg die Amazon nu inslaat. Er staat ons gewoon nog veel te wachten dat eindeloos veel nieuwe mogelijkheden zal bieden. En aan KBC zou ik zeggen: doe zo voort!"