Over API en de architectuur van uw webshop software

Tom Obdam •  15 december 2016

 

Het is nogal een open deur om te stellen dat techniek een belangrijke rol in e-commerce speelt. Toch wordt deze rol nog vaak onderschat. Er wordt onvoldoende nagedacht over de inrichting van de techniek, waardoor het te weinig als middel wordt gebruikt om onderscheidend te zijn. De technische inrichting van de e-commerce omgeving kan beperkend gaan werken als een retailer wil doorgroeien naar een omnichannel retailer, waar de consument op alle devices een consistente ervaring heeft.

Uitgangspunten
Maar hoe zorg je er dan voor dat het systeemlandschap toekomstvast wordt ingericht? Bij het beantwoorden van deze vraag zou het makkelijk zijn om helder te hebben wat de toekomst brengt. Dat is natuurlijk niet het geval, wat betekent dat de uitgangspunten helder gedefinieerd moeten worden. De belangrijkste uitgangspunten zijn:

  1. Open systeemlandschap
    Een systeem dat niet kan samenwerken met andere systemen is in een ‘connected’ wereld vrijwel nutteloos. Daarom is het belangrijk dat het systeem open is. Bij voorkeur gebeurt dat via een goed gedocumenteerde API.
  2. Schaalbaar systeemlandschap
    Zorg ervoor dat de omgeving zo is ingericht dat deze opgeschaald kan worden op het moment dat het aantal bezoekers en transacties toeneemt. Bij voorkeur gebeurt dat volledig flexibel.
  3. Vervangbaar systeemlandschap
    Systemen/applicaties hebben een bepaalde levensduur. De behoefte aan vervanging kan meerdere redenen hebben. Belangrijke redenen zijn:– Het systeem voldoet functioneel niet meer
    De functies die men het systeem wil laten uitvoeren zijn niet mogelijk, waardoor het niet meer voldoet aan de wensen/eisen die er aan gesteld worden.

    – Het systeem voldoet technisch niet meer
    De stabiliteit of performance van het systeem is onvoldoende, waardoor de verwerking van informatie stokt, het systeem te traag wordt of het systeem uitvalt.

    – Het onderhoud op het systeem is te omslachtig geworden
    Om vernieuwingen aan te brengen in het systeem is onevenredig veel inspanning nodig; de kosten van de vernieuwing wegen niet op tegen de opbrengsten van de vernieuwing.

    De ‘ideale’ situatie
    Er is niet één ideale situatie die voor alle bedrijven toepasbaar is. Maar uitgaande van een greenfield wordt in de onderstaande visual weergegeven wat een ideale invulling van de architectuur kan zijn:

API.jpg

  1. Marketing & Sales systemen
    Dit zijn de systemen die het contact met de klanten verzorgen. Deze systemen zijn bij voorkeur via de API (eventueel gebruikmakend van middleware) gekoppeld aan de Commerce en Content Systemen. De belangrijke voorbeelden zijn:- Website / Webwinkel;
    – Smartphone / Tablet app voor consument;
    – Kassa integratie van het e-commerce assortiment om nooit meer nee te hoeven verkopen;
    – Websites van derden (Amazon, Bol, Zalando) waar productfeeds naartoe gaan en waar orders en klanten vandaan komen.
  2. Commerce & Content systemen
    Deze zorgen ervoor dat de juiste content op het juiste moment aan de juiste bezoeker wordt getoond. Hierdoor wordt er bijgedragen aan de doelstellingen. Dit zijn de systemen waar de marketeer aan het stuur zit en het gedrag van de website en apps afstemt op het gedrag van de bezoekers daarvan.
  3. API
    Application Programming Interface, ofwel het loket (of de loketjes) waarmee systemen met elkaar kunnen communiceren. Volgens Wikipedia: “Een API is een verzameling definities op basis waarvan een computerprogramma kan communiceren met een ander programma of onderdeel.” In bovenstaande visual staan de API om de Commerce & Contentsystemen getekend. Dat hoeft niet de enige plek voor de API te zijn. Bij voorkeur hebben alle losse systemen ook een API, wat het makkelijker maakt om ze waar nodig te vervangen en onderling te koppelen.De API in de visual zorgt ervoor dat de commerce- en contentfunctionaliteit beschikbaar is voor de Marketing & Sales Systemen. Door die functionaliteit te centraliseren en via de API beschikbaar te stellen, kunnen klanten een consistente gebruikerservaring hebben over kanalen en devices, maar kunnen bijvoorbeeld ook hun winkelmandje van het ene naar het andere device meenemen.
  4. Externe systemen
    De externe systemen verzorgen functionaliteit waarvoor het verstandig is om dat uit te besteden. De meest voorkomende voorbeelden van deze externe systemen zijn een Payment Service Provider en een E-mail Service Provider. Andere voorbeelden zijn een zoekfunctie, waarvoor soms een cloud-dienst wordt gebruikt.
  5. Middleware
    De middleware wordt ingezet om de communicatie te verzorgen. Daarin is het volgende belangrijk:– Verzorgen van berichtenverkeer;
    Het is belangrijk om erop te kunnen rekenen dat een bericht van het ene systeem naar het andere systeem aankomt. Middleware vervult die rol, inclusief het loggen en signaleren van uitzonderingen.

    – Verzorgen van berichttransities;
    Als het wenselijk is dat een bericht vanuit een systeem bij meerdere systemen aankomt, ieder in een andere vorm, dan kan middleware worden ingezet om die transitie te doen. Een voorbeeld: een orderbericht uit het commerce platform moet worden verzonden naar het WMS (Warehouse Management Systeem), het OMS (Order Management Systeem), het ERP en een Datawarehouse. In veel gevallen worden er dan vier berichten geprogrammeerd in de koppeling tussen het commerce platform en de eerder genoemde systemen. Veel beter schaalbaar is het om één bericht te definiëren dat naar de middleware gaat, waarin het bericht wordt gesplitst naar de vier doelsystemen. Dat maakt het eventueel vervangen van het commerce platform ook makkelijker.

    Middleware zorgt ervoor dat rechtstreekse communicatie tussen systemen niet nodig is. Dat levert een positieve bijdrage aan de vervangbaarheid van onderdelen in het systeemlandschap en schaalbaarheid van de totale architectuur.

  6.  Interne systemen
    De interne systemen zijn vaak bestaande systemen die bestaande processen binnen een organisatie ondersteunen. Binnen een retail-organisatie vormen drie entiteiten het hart van de onderneming: het product dat wordt aangeboden, de klant die dat product koopt en de order die daarmee tot stand komt. Dat is direct het argument om voor systemen te zorgen die rondom die drie entiteiten de ‘waarheid’ bevatten. Het gaat in de visual dan om de volgende systemen:– PIM – Product Informatie Management
    Omdat het belangrijk is dat in alle kanalen (Marketing & Sales Systemen) een eenduidig beeld is over het assortiment, is het raadzaam om het beheer op de productinformatie centraal in de organisatie in te richten. Een PIM helpt bij het centraal vastleggen van de productinformatie, maar ook bij het faciliteren van de workflow die rondom die informatie geldt.

    – OMS – Order Management Systeem
    In een omnichannel organisatie komen orders vanuit meerdere bronnen binnen en worden orders op meerdere plekken geretourneerd. Het is belangrijk dat er één systeem binnen de organisatie is waar de waarheid rondom een order vastligt. Prijzen per orderregel en status per orderregel moet op elk moment actueel en inzichtelijk zijn voor de klant. Dit kan worden aangevuld met informatie over refunds en betalingen.

    – CRM
    Als klanten via meerdere kanalen contact hebben is het zeer wenselijk om op een centrale plek de profielen van die klanten bij te houden. Alleen op die manier is een compleet klantbeeld te verkrijgen.

    Wilt u meer informatie over het inrichten van de API en de architectuur voor uw webshop software? Neem gerust contact met ons op! We vertellen u er graag meer over.