Veel bedrijven hebben tegenwoordig digitale services die perfect aansluiten op de workflows van andere bedrijven, of zijn dat van plan. Denk bijvoorbeeld aan services voor online payments, logistiek, fraudedetectie, bedrijfs- of personenverificatie, verzekeringen en kredieten of personalisatie. Maar om bedrijven daadwerkelijk enthousiast te krijgen voor het gebruik ervan in hun eigen workflows, is het cruciaal om rekening te houden met de ervaringen van developers. Je product of dienst kan nog zo fantastisch zijn, maar als het voor developers complex of niet aantrekkelijk is, kun je het echt vergeten. Zij gaan de services en producten uiteindelijk integreren en hun ervaringen zijn dan ook leidend in het selectieproces van mogelijke serviceproviders. Een goede Developer Experience van technische, digitale producten is daarom essentieel voor het succes. Zie het als het belang van User Experience, maar dan voor technische producten.
Zes vuistregels voor Developer Experience
Maar wat bepaalt een goede Developer Experience? Om de kwaliteit en volwassenheid van de Developer Experience van digitale services te beoordelen én te waarborgen, hebben wij bij ISAAC zes vuistregels die ons houvast geven:
- Eenvoudig experimenteren: is er een ‘explore and play’ Sandbox en in hoeverre gedraagt die zich als een productieomgeving?
- Het 3:30:3-principe: is het mogelijk om in 3 seconden te begrijpen wat het platform of de service doet? Kan ik in 30 seconden een test doen en heb ik binnen 3 minuten een eerste waardevol resultaat?
- Gelaagde documentatie: krijgen developers en product owners snel de belangrijkste informatie? En komen ze er daarmee te weten welke functionaliteiten een platform of service biedt en welke waarde dat toevoegt? Scrum-teams kijken naar andere dingen dan de gespecialiseerde developer die uiteindelijk gaat integreren. Daar moet je in je documentatie rekening mee houden.
- De API-triad: op welke niveaus kun je interacteren met het platform en de services? Beperkt het zich tot REST, of worden ook de andere twee poten, Webhooks en GraphQL, aangeboden?
- Aanwezigheid en vindbaarheid: in hoeverre zijn de services met SDKs en plug-ins beschikbaar in platformspecifieke marketplaces, zoals Magento, en op public cloud serverless integration platforms, zoals Azure of Amazon?
- Beschikbaarheid van informatie: staat de informatie verstopt op je eigen website of is het ook breed toegankelijk op websites en community’s waar veel developers zijn, zoals Github en Stack Overflow?
Meer hierover weten? Je leest het in onze whitepaper 21 tips voor User Experience en Developer Experience op platforms.
Populariteit van low code en ‘zo snel mogelijk resultaat’
De eerste vier vuistregels zijn meestal redelijk eenvoudig te vertalen naar to do’s voor je digitale services. Het zijn dingen waar je goed over ‘in control’ kunt zijn en slechts beperkt afhankelijk van externe ontwikkelingen. Heb je de aspecten uit de eerste vier vuistregels goed geregeld? Dan heb je in principe de Developer Experience als serviceprovider goed voor elkaar, maar speel je niet zozeer in op de populariteit van low code development of de wens voor ‘zo snel mogelijk resultaat’. Daar komen de laatste twee vuistregels juist om de hoek kijken.
Steeds meer bedrijven bouwen namelijk hun integratie- en businesslayer functionaliteit op grote public serverless cloud integration platforms, ook wel bekend als iPaaS (Integration Platform as a Service). Denk daarbij bijvoorbeeld aan Azure Logic Apps en AWS AppFlow. Je kunt er eigenlijk niet meer omheen om daar als serviceprovider rekening mee te houden. Het ligt dan ook voor de hand om boven op je APIs ook SDKs en plug-ins te ontwikkelen, specifiek voor een doelplatform. Vervolgens maak je die, voorzien van de juiste certificering en documentatie, beschikbaar op de marketplaces van die platforms. Let naast de grote cloudproviders, ook op je positie op meer specialistische platformen, zoals de commerce-omgevingen van Magento, Salesforce Commerce Cloud, CommerceTools en WooCommerce.
Potentie van Azure Logic Apps en AWS AppFlow
Een groot voordeel van zichtbaarheid in dat soort stores, is dat het dé nieuwe plek is waar door bedrijven wordt gezocht naar interessante integraties en connectoren. In tegenstelling tot de on-premise integratieplatformen (o.a. Oracle, Apache Camel, Dell Boomi en IBM) waarvoor connectors meestal alleen op protocol-level beschikbaar waren, ontstaan er op de public cloud platformen nu marketplace ecosystemen waarop je direct beschikbaar kan zijn als serviceprovider met je business service. Stripe in payments is er bijvoorbeeld al vroeg bij op Azure.
En het is ook wel begrijpelijk dat bedrijven graag (gaan) bouwen met workflow- of data-services als Azure Logic Apps of met het opkomende AWS AppFlow. Enkele voordelen voor bedrijven die op deze manier hun apps en architecturen opbouwen:
- Azure en Amazon zijn cloud based en serverless, dat betekent dat de (netwerk)infrastructuur en workflows ‘as code’ uit te rollen zijn, naar gebruik worden afgerekend en er nauwelijks beheer nodig is. De gebruiker van het platform kan zich meer op business dan techniek richten.
- Over schaalbaarheid hoeven bedrijven zich geen zorgen meer te maken. En ook de route naar een succesvolle deployment is eenvoudiger. Zo ondersteunt Azure DevOps bijvoorbeeld op een gestandaardiseerde manier het ontwikkelproces.
- Er is een heel ecosysteem van trainingen en certificeringen beschikbaar, waardoor het heel toegankelijk is om mensen op te leiden;
- Tot nu lijken zowel Azure en AWS curatie van connectoren en plug-ins serieus te nemen met duidelijke richtlijnen, waardoor er een kwaliteitsbaseline is op integraties.
- De pricing is aantrekkelijk ten opzichte van on-premise integratieplatformen, maar ook ten opzichte van pure low code platformen zoals Mendix.
Het is wel duidelijk dat spelers als Azure en AWS op al deze punten een stevige strijd om de harten van zowel de business als de developer strijden. En hun investeringsmiljarden andere spelers intussen flink de pas afsnijden. Die realiteit moet je als aanbieder van een service accepteren.
Next steps
Voor veel, misschien wel de meeste serviceproviders, is het dan ook een logische stap om aan de slag te gaan met aanwezigheid op bekende platformspecifieke marketplaces en de public cloud serverless integration platforms. En dus boven op je APIs ook SDKs en plug-ins te ontwikkelen die je via die stores beschikbaar kunt stellen. Daar liggen op dit moment gewoon grote kansen. Maar zie het natuurlijk wel zo: je ‘integratie experience’ ga je dan beschikbaar stellen op een extern platform. Het is dan nóg belangrijker dat alle zaken volgens de eerste vier vuistregels excellent in elkaar steken om uiteindelijk ook via de public cloud serverless integration platforms daadwerkelijk succesvol te zijn.
