In het vorige blog werd duidelijk wat de disruptiviteit van API’s is in alledaagse diensten: webwinkels, vliegwinkels, etc. Nu naar onze Agri– en Food sector. Dé sector waarin transparante en verrijkende informatievoorziening een must is. Zeker gekeken naar de productie-, milieu- en sociale uitdagingen waarmee de globale productie-en handelsketen te maken heeft.

Hoewel RESTful API’s al een paar jaar meegaan, zijn er nog weinig disruptieve ontwikkelingen in onze sector gaande. Zijn wij een stel blauwe reuzen die liggen te slapen? Ik denk het soms wel! Het verhaal in het vorige blog is ook van toepassing op hotels (Trivago), restaurants, horeca (Thuisbezorgd.nl), verzekeringen (Independer), energie en ga zo door. En hoewel de meeste aansprekende en bekende voorbeelden uit de Business to Consumer (B2C) markt komen, zijn er ook al genoeg voorbeelden in de B2B markt waar wij actief zijn. Waarom zou een dergelijke grote ontwikkeling dan aan de Agri- en Foodbranche voorbijgaan? Gaan we zitten wachten totdat een paar slimme agri-studenten kunstmestwinkel.nl, gewasbeschermingswinkel.nl of meststoffenwinkel.nl opstarten om vervolgens net als die grote luchtvaartmaatschappijen jarenlang achter de feiten aan te lopen? Een soortgelijk iets is gebeurd met MijnVoer.nl. Hier kunnen veehouders bij aangesloten veevoederfabrieken een bestelling plaatsen voor een specifiek mengvoer met zelf opgegeven nutritionele kenmerken. Vervolgens bestelt de veehouder bij de goedkoopste producent, in plaats van bij een vaste voerproducent. Bovendien, inmiddels internationaliseert MijnVoer.nl Misschien denken we dat de B2B markt minder toegankelijk is voor nieuwe toetreders. Maar betekent dat dat de gevestigde orde genoegzaam achterover kan leunen? Als er dan geen nieuwe toetreders actief worden, loop je dan niet het risico dat één van je bestaande concurrenten ineens het licht ziet en er als een haas vandoor gaat?

De Nederlandse Agri– en Food sector is toonaangevend en heeft ook op het gebied van ICT en standaardisatie een mooi track record. Organisaties als Agroconnect, Floricode, FrugICom, FreshUpStream en, wat meer aan zijlijn van onze sector, GS1 hebben in bijna 30 jaar een enorme bijdrage geleverd aan de digitalisering van de sector. De huidige wereld vraagt om een stap meer te doen. Standaarden voor digitalisering zijn bijna allemaal ontstaan vanuit het idee dat we data met elkaar willen uitwisselen: EDI ofwel Electonic Data Interchange. Of eigenlijk: Electonic Document Interchange: een paradigma waarbij we documenten (met daarin informatie) met elkaar uitwisselen in berichten (messages). De standaarden bestaan dan onder andere uit beschrijvingen van de dataelementen en syntax van de documenten (vroeger EDI formaten als EDIFact en ADIS of ebXML). Ook de wijze van transport (e-mail, ftp, soap), de toegepaste codelijsten en afhandeling van berichten (business rules) horen bij deze standaarden.

Dit EDI-paradigma is in die 30 jaar zo ingebakken geraakt in onze denkwijze, dat het de kracht van de REST/API technologie dreigt te overschaduwen. Opnieuw: gevestigde organisaties zijn vaak in het nadeel bij disruptieve innovaties. Dat geldt niet alleen voor de organisatie die ICT gebruiken, maar ook voor ICT-bedrijven die blijven hangen in hun oude credo. In dit geval is er een technologische wet van de remmende voorsprong. De kennis over de wijze waarop we systemen de afgelopen decennia hebben laten samen werken via EDI zit ons meer in de weg dan dat dat het nog helpt.

Natuurlijk vindt er uitwisseling van data plaats wanneer systemen via API’s communiceren. Maar de data in de API request- of respons is bedoeld om het proces dat door API geïmplementeerd wordt te ondersteunen: data-uitwisseling is op zich niet het doel, het proces is het doel.

Het verschil tussen EDI en API’s is groter dan veel mensen denken. EDI is een set strikte afspraken die aan twee zijden (zender en ontvanger) gemaakt zijn over hoe zij gestandaarde digitale documenten met elkaar uitwisselen en verwerken om bedrijfsprocessen (zoals bestellen, factureren, etc.) te ondersteunen. Deze documenten worden verstuurd op basis van data uit de bron-database en worden door het ontvangende systeem weer verwerkt in de doeldatabase, waarna de opvolgende business processen kunnen plaatsvinden.

Met API’s kan een organisatie (nieuwe) interacties op haar eigen systemen mogelijk maken door specifieke functies en services op haar systeem naar de buitenwereld te publiceren. Deze services kunnen geconsumeerd worden door applicaties van derden. Via API’s hebben klanten, leveranciers , medewerkers of wie dan ook toegang tot business- en dataservices vanaf elk door hen gewenste bron of device. Natuurlijk alleen na toestemming (autorisatie) van de eigenaar van het systeem dat de API’s publiceert. Een organisatie bepaalt dus in principe zelf, vanuit haar business visie, welke API’s zij voor de buitenwereld beschikbaar wil stellen. De buitenwereld kan daar dan als zijn wil op aanhaken. Niet voor niets biedt geautomatiseerde tooling rond API’s (API Management) enorme mogelijkheden om de API-definities aan potentiële gebruikers goed gedocumenteerd en testbaar te publiceren. Waar in de EDI-wereld allerlei afspraken overeengekomen, vastgelegd, gedocumenteerd en gedistribueerd moeten worden, gaat de API- wereld er van uit dat de aanbieder bepaalt hoe haar API’s werken en kan de consument eenvoudig aansluiten wanneer hij dat wil.

Dit heeft ook impact op de rol van de bovengenoemde standaardisatieorganisaties. Definitie, documentatie en distributie van wederzijdse EDI-standaarden en inrichting van testcenters werd en wordt vaak door deze organisaties binnen een sector uitgevoerd. Maar wat wordt de rol van dergelijke standaardisatie in de API-wereld als belangrijke organisaties zélf het initiatief kunnen nemen om API’s op hun systemen te definiëren en de tooling er omheen om de definities, publicatie en test van deze API’s vrijwel automatisch werkt? En andersom: wat als een standaardisatieorganisatie wel API standaarden beschrijft en een bedrijf Q in de sector publiceert toch haar eigen set API’s op haar systeem om haar klanten te ondersteunen? In de oude wereld zou die actie kansloos zijn omdat niemand haar EDI software specifiek gaat aanpassen aan de afwijkende eisen van bedrijf Q. Maar implementatie van API-consumers is zo eenvoudig dat die partijen die meerwaarde zien in de aangeboden digitale diensten van bedrijf Q, deze onmiddellijk zullen gaan gebruiken, gestandaardiseerd of niet!

Dat brengt ons bij de kern van dit betoog.

API-technologie geeft bedrijven met een digitale visie de mogelijkheid zich te onderscheiden en daarmee concurrentievoordeel te behalen.

Wie wil dat nu niet? En: waar blijft je concurrentievoordeel als je je API’s pas gaat implementeren als je eerst met je concurrenten gaat afspreken hoe deze API’s moeten gaan werken en ze dan allebei gaat implementeren? Dit is een andere tijd dan de jaren 90!

Onze sector heeft behoefte aan koplopers met een digitale visie! Bedrijven die inzien dat de digitale economie ook voor hen gaat werken. Bedrijven die het initiatief durven te nemen om de eerste stappen te zetten, daarvan te leren en weer verder te gaan. Ik zou niet weten waarom alleen nieuwe toetreders die visie zouden hebben en bestaande partijen niet. Het verkrijgen van de digitale visie en manieren waarop API’s nieuwe business kunnen genereren is hierin de sleutel.