Het e-commerce platform

Drie technologische hoofdrichtingen voor architectuur

Het e-commerceplatform is de spil in de online business. Met de verdere beweging richting een volledige omnichannel is het tevens een spil in het offline werkveld. Eigenlijk mogen we niet meer spreken van offline en online als kanalen, de integrale klantreis wordt ondersteund door functionaliteit uit het e-commerceplatform.

Waarom letten op architectuur?

Ervaring leert dat het selecteren van een volgende generatie e-commerceplatform heel wat voeten in aarde heeft. Idealiter zou het een eenvoudige upgrade naar een nieuwe versie zijn of enkele componenten in het landschap vervangen. Vaak is er echter sprake van een monolytische omgeving, ontstaan als combinatie van een standaard platform met daarbij een flinke dosis maatwerk. Deze monoliet vervangen betekent voor alle verzorgde functies een waardige opvolging realiseren of regressie voor lief nemen.

Wanneer een traject voor ‘replatforming’ wordt ingezet is dit meestal ingegeven vanuit de zichtbare nadelen van het huidige platform, bijvoorbeeld missende features of optredende fouten. Deze negatieve business value is een uitstekende motivatie voor het tijdstip van vervanging en bepaalt het nieuwe pakket van wensen en eisen. De onzichtbare nadelen worden gevormd door ‘technische schuld’, hierin zijn aspecten als beheersbaarheid en toekomstbestendigheid besloten. Een juiste architectuur van de omgeving draagt bij aan deze aspecten. Des te meer reden om bij de selectie voor een nieuw platform of opzet een kritische afweging te maken welke basisarchitectuur bij de organisatie past.

Hiervoor hanteert XSARUS drie scenario’s:

Scenario 1: Full-Suite

Dit is het meest klassieke scenario, waarbij gekozen wordt voor een standaard pakket, één primaire suite. Uitgangspunt is dat binnen de standaardfunctionaliteit van dit pakket zowel de storefronts (webshopomgevingen) als de backoffice (order management, CMS-functies, marketingfuncties) wordt gebruikt.

Voordelen:

  • Best-practices beschikbaar, storefronts en backoffice sluiten naadloos op elkaar aan
  • Veel ervaring mee bij implementatie partners
  • Vaak standaardmodules en add-ons aanwezig voor specifieke webshop functionaliteit
  • Standaard integraties met bijvoorbeeld payment providers, logistieke providers, marketing software

Nadelen:

  • Implementatie en go-live meestal big-bang
  • Maatwerk ontwikkeling relatief kostbaar en onderhoudsintensief
  • Herhaald risico op monolytische architectuur
  • Platform / vendor lock-in

Voorbeeld: Storefronts en backoffice draaien beide op Magento. Magento storefronts worden opgezet met behulp van best-practice, templates en themes. Extra functionaliteit wordt verkregen door maatwerk en Magento add-ons.

Scenario 2: Hybride

Het hybride scenario bestaat uit twee primaire, bij voorkeur eveneens standaard pakketten. Hierbij wordt het storefront in een ander systeem opgezet dan de backoffice functionaliteit. De pakketten worden geselecteerd op hun specifieke kracht. Gegevensuitwisseling tussen de omgevingen vinden plaats via standaard API’s. Elk van de systemen heeft het eigen benaderbare backoffice deel, de backoffice van het storefront wordt primair gebruikt voor het onderhouden van de webshop, content, catalogi (CMS). Het backoffice pakket is de centrale plaats voor order management en logistieke functies (OMS).

Voordelen:

  • Elke oplossing in zijn kracht, geen of minder consensus in de oplossing en dus weinig maatwerk nodig
  • Storefronts en backoffice krijgen eigen lifecycle. Dus minder big-bangs en risicovolle implementaties
  • Door API integratie in de toekomst onafhankelijke delen eenvoudiger te upgraden en te vervangen

Nadelen:

  • Twee systemen hebben samen een grotere footprint, impact op operationele kosten
  • Dataduplicatie doordat onvermijdelijk gegevens worden gekopieerd van en naar systemen

Voorbeeld: Storefronts worden opgezet in Magento, backoffice wordt opgezet in Tabletop. Door gebruik te maken van Magento zijn veel standaard storefront features beschikbaar. Orders worden doorgezet naar Tabletop welke via de API is gekoppeld. In TableTop wordt door middel van business rules het order management vrijwel geheel geautomatiseerd. Complexere pick, pack en ship scenario’s zoals click&collect, multi-inventory-sourcing en de integratie met een fulfillment partij worden gerealiseerd.

Scenario 3: Mashup

Het mashup scenario is aan te merken als het meest vooruitstrevende. Niet langer slechts één of twee pakketten maken samen de oplossing. Binnen een mashup spreken we over een slim samengestelde set van componenten (services) die bijeen worden gebracht in een storefront. Wanneer dit samenbrengen plaatsvindt in het endpoint, de browser van de gebruiker, spreken we tevens van headless. Meer algemeen spreken we over een decoupled of service-oriented architecture. Uiteraard worden standaard API’s gebruikt voor de integraties.

Voordelen:

  • Best-of-breed componenten, voor elke functie de beste oplossing in zijn soort
  • Eenvoudig gebruik kunnen maken van SaaS-componenten
  • Kleine footprint en hoge performance, enorm schaalbaar
  • Focus op ‘orchestration’ ipv maatwerk
  • Door API integratie zijn componenten eenvoudiger te upgraden en te vervangen

Nadelen:

  • Technologisch risico. Het is een moderne aanpak en er is minder ervaring mee
  • Er is geen standaard oplossing voor het storefront
  • Vele externe componenten hebben gezamenlijk vaak hogere kosten

Voorbeeld: Backoffice wordt opgezet in Magento welke via de standaard API’s wordt ontsloten. Content Management wordt in een headless CMS ondergebracht. Search en merchandizing wordt ontsloten middels Tweakwise, overige productinformatie wordt uit het PIM betrokken. Het storefront wordt opgezet in een lightweight Zend Expressive framework wat de diverse bronnen combineert.

Conclusie

Niet een enkel scenario heeft de voorkeur boven de andere, dit is geheel contextafhankelijk. Welke uitgangspunten wegen mee in de beslissing en met welk gewicht? Heeft de organisatie al een sterke pakketvoorkeur vanuit eerdere ervaringen? Zijn er al services en componenten binnen de bestaande architectuur die kunnen worden aangesproken? Is de focus van de vernieuwing gericht op de frontend of juist op de backoffice processen? XSARUS stelt klantsucces en -doelstellingen centraal en denkt graag mee over verschillende mogelijkheden. Wij zijn kritisch, stellen de juiste vragen en komen met een passende oplossing!

Door gebruik te blijven maken van onze website, geef je toestemming en ga je akkoord met het gebruik van cookies. Meer informatie kan je vinden op onze cookiespagina.