-

Slim omgaan met je API’s: het nut van een interne marketplace

Hergebruik van software is op papier een goed idee, maar komt in de praktijk maar mondjesmaat van de grond. De services die worden gedeeld zijn niet plug-and-play en de kosten vallen daardoor altijd hoger uit dan beraamd. Hoe kun je softwarehergebruik wel succesvol vormgeven? Met interne API-marketplaces.

Elk groot bedrijf wil een zo efficiënt mogelijk IT-landschap. Daarom is hergebruik van software een belangrijk thema. Dus maken we kennisdelingsstructuren, corporate Confluence-pagina’s, OSGI-componenten, SOAP- of REST-services, enzovoorts, enzovoorts, maar al die vormen van hergebruik stellen teleur. De reden? We blijven interne peers en andere afdelingen beschouwen als partijen die we bijzondere persoonlijke aandacht moeten geven. Juist het feit dat we dit nodig achten, geeft aan dat de services die we willen delen niet plug-and-play zijn. Er is toch altijd mankracht nodig om software geschikt te maken en te implementeren.

Dat probleem verhelp je met een interne API-marketplace, waar je API’s vermarkt en productkenmerken deelt. De API’s zijn direct te gebruiken. Een andere afdeling ‘koopt’ het product op de marketplace en kan meteen aan de slag. We hoeven niets meer af te stemmen, de interne klanten zijn ‘anonieme’ self-servicing clients die een API compleet met een afrekenmodel en documentatie afnemen. Het is een intern winkeltje, gefaciliteerd en gehost door IT, waarvan het kostenmodel helder is en het nut van de geboden oplossing meteen duidelijk is.

Dit gaat verder dan een intern developer portal. De API-marketplace zegt iets over de pricing van een service en interne verrekening of budgettering. Daarnaast geeft het aan wat voor type corporate governance er op een API beschikbaar is. Bijvoorbeeld in ISO27001-scope of niet, wel of niet geschikt om in bepaalde legal processen in te zetten, wel of niet opgenomen in een internal audit, enzovoorts.

Interessant voor grote organisaties met veel data

Voor welk type bedrijven is dit nu interessant? Bedrijven met grote hoeveelheden interne data waarop veel diensten draaien. Denk aan ontwerp, logistiek, openbaar vervoer, finance en global commerce. Maar ook voor bedrijven met grote fysieke locaties, zoals luchthavens, fabrieken, raffinaderijen, ziekenhuiscomplexen, elektriciteitscentrales, conferentieoorden en evenementenhallen zijn API-marketplaces een goede manier om de kennis die al aanwezig is in huis opnieuw te benutten.

In onderwijs en wetenschap zijn ook toepassingen te bedenken. Uit de onderzoeken die daar worden gedaan komen veel data voort. De bedoeling is dat die data open zijn maar het is in de praktijk lastig om er toegang toe te krijgen. Je zou onderzoeksgegevens ook op een marketplace kunnen zetten. Zo’n marketplace hoeft niet publiek te zijn – je kunt aanvragen beoordelen of bepaalde rollen meer toegang geven. Maar het is wel belangrijk dat je het zo simpel mogelijk houdt.

Naast een eenvoudige structuur zijn er meer voorwaarden waaraan een goede interne API-marketplace moet voldoen:

– Elke API heeft een heldere marketingomschrijving;

– Het is duidelijk wie voor de API verantwoordelijk is (afdeling, organisatie);

– Er is nagedacht over versionering en een support lifecycle, of tenminste de aanzet daartoe;

– Er is OpenAPI-documentatie opgenomen in de vorm van een developer portal;

– Er zijn gebruiksvoorbeelden gemaakt van algemene use-cases;

– Indien de API een verdienmodel heeft (en dat is meestal zo) is er een duidelijk ‘monitization’-model zichtbaar;

– Een ‘sandbox’ of speeltuinomgeving biedt de mogelijkheid om meteen even te experimenteren met de API;

– Je kunt gemakkelijk zoeken en selecteren.

Dus daarom een API-marketplace

De rationale van hergebruik is dat er volumevoordelen en kostenbesparingen uit ontstaan. API’s zijn supersimpel te integreren, dus je hebt meteen voordeel. Het past ook perfect in de agile gedachte – het is al getest dus er kan meteen opgeschaald worden. En bedrijven kunnen hun hergebruik-strategie beter gaan meten met behulp van een KPI op de gepubliceerde APIs in een interne marketplace en de tractie rond die marketplace. Tractie die je kunt aanjagen vanuit al die corporate potjes voor hergebruik en ‘global cooperation’: maak daar eerst maar eens wat logische API’s mee in je marketplace en de klanten komen vanzelf. Je kunt dat stimuleren met leuke proof-of-concepts door studenten of stagiairs. Zien kopen, doet kopen, ook intern.

Die tractie op zo’n marketplace wordt alleen maar groter nu er een nieuwe, tweede generatie API-specificatie populair aan het worden is. GraphQL biedt nog meer flexibiliteit door de query language. Met GraphQL geef je veel meer vrijheid aan je clients. Dat is ideaal als je niet goed alle use cases kunt overzien. Het vergt wel bijzondere back-ends waarbij traditionele technieken op de server zoals JavaEE of grote .Net applicaties minder goed passen dan datagrids of lambda’s in de cloud. Maar per saldo maakt GraphQL de businesscase voor een interne API-marketplace nog sterker.

Deel dit bericht

1 Reactie

Meindert Rickelman - SSC-ICT

Speel intussen ook een tijd met ongeveer deze gedachte. Zeker het delen van data uit systemen via die ‘marketplace’ (marktplein) zou op overheidsniveau een enorme stap kunnen zijn. De problematiek van het via Servicing Agreements ondersteunen van deelnemers is inderdaad lastig. Maatwerk na maatwerk na maatwerk.

Dan liever geheel loskoppelen en je clients meer anoniem met een vast service model benaderen. De schaalbaarheid die altijd gewenst is is dan ook veel beter haalbaar. Het aspect rondom het inkaderen van de juridische context waarin een service gebruikt kan worden is interessant en neem ik mee.

Duurt denk ik nog wel even voor overheden hier zijn, maar heb goede hoop voor de voortgang die tooling maakt nu en wat er uit het bedrijfsleven komt.

Plaats een reactie

Uw e-mailadres wordt niet op de site getoond