Middleware voor e-commerce; kostenpost of vooruit kijken?

Bart de Vries   •  11 mei 2016

Hoeveel vrijheid heb jij, als product owner of stakeholder, bij de doorontwikkeling van je webwinkel? Kun je voldoende nieuwe features implementeren? Heeft jouw webwinkel een hoge beschikbaarheid? Kun je updaten wanneer je wilt? Het antwoord hierop baseer je waarschijnlijk voor een groot deel op de flexibiliteit van je team en de flexibiliteit van de webwinkel leverancier. Maar heb je ook al eens gedacht aan de beperkende factoren van integrerende ICT systemen?

blog bart middleware (2)

In een gangbare e-commerce ICT omgeving is er vaak sprake van systemen zoals de webwinkel, betaalproviders, een order management systeem en een ERP/financieel systeem. Op het moment dat een order wordt geplaatst ga je betalen d.m.v. de betaalprovider, waarna de order wordt doorgestuurd naar het order management systeem en het financiële systeem.

Als we deze kennis allemaal integreren aan de e-commerce kant, kan het plaatje er als volgt uitzien:

grafiek3

Dat gaat prima werken! Wel mogen we hierbij een paar vragen stellen zoals:

  • Hoeveel afhankelijkheden (lees: beperkingen) heeft je e-commerce omgeving al?
  • Hoeveel systemen weten van elkaars bestaan?
  • Op hoeveel systemen kan een wijziging in het e-commerce platform uitstralen?
  • Hoeveel code is er voor nodig om al die systemen van elkaar te laten weten?
  • Wat zijn de gevolgen voor de beschikbaarheid?
  • Wat is de impact van een livegang?

Wat is middleware?

Laten we duidelijk zijn; de kop “Middleware voor e-commerce; kostenpost of vooruit kijken?” is mank. Middleware is per definitie een investering en het niet implementeren van een middleware kan een hele bewuste keuze zijn voor de voorziene termijn. Maar wat is middleware eigenlijk?

Middleware is een systeem dat dient als communicatiemiddel tussen verschillende ICT systemen. Je plaatst de middleware tussen ICT systemen om uitwisseling van gegevens te faciliteren en optimaliseren. Deze taken kunnen natuurlijk ook opgelost worden in andere ICT systemen maar ieder systeem heeft zijn specialiteit. Middleware heeft enkele eigenschappen die andere, maatwerk gebaseerde, systemen niet hebben. Denk bijvoorbeeld aan:

  • Flexibiliteit in de inhoud en structuur van de informatie
  • Mogelijkheden om informatie te splitsen of samenvoegen
  • Centrale inzage en beheer op de informatie-flow en eventuele incidenten
  • Asynchroon informatie ontvangen en verwerken
  • Informatie opsparen als een systeem niet beschikbaar is

Los van zijn eigenschappen heb je op het eerste gezicht het idee dat het toevoegen van een extra ICT systeem alleen maar meer complexiteit geeft. Echter, als je kijkt naar de hiervoor genoemde eigenschappen, dan zie je nieuwe kansen. Zo maakt een middleware het mogelijk om:

  • Rechtlijniger te communiceren in plaats van in een stervorm
  • Systemen onafhankelijk van elkaar te laten opereren
  • Systemen hoeven niet van elkaar te weten
  • Updates uitrollen zonder andere systemen te beïnvloeden
  • Code vereenvoudigen
  • Deelprocessen van elkaar lostrekken
  • Zware of minder belangrijke processen los te trekken van belangrijke processen

Los van wat een middleware kan ga je dus ook je processen en code anders inregelen en/of vereenvoudigen. Dit draagt allemaal bij aan de beheersbaarheid van het geheel.

Dat wil ik illustreren aan de hand van onderstaande grafiek. De grafiek staat voor een periode van 30 maanden. In deze periode zijn systemen toegevoegd en wordt na ca. 11 maanden een middleware geïntroduceerd. Dit is in maand 15 afgerond waarna het beheer doorgaat en nog een systeem wordt toegevoegd.

grafiek2

Wat af te lezen is uit de grafiek is de relatie tussen het aantal betrokken systemen en de impact op de beheersbaarheid, afhankelijkheid en hoeveelheid code. Voor de introductie van een middleware daalt de beheersbaarheid enorm en nemen afhankelijkheid en hoeveelheid code toe. De introductie van de middleware vormt een kantelpunt en je ziet de hoeveelheid code en de afhankelijkheid fors afnemen met als gevolg dat ook de beheersbaarheid toeneemt. De beheersbaarheid wordt, los van code en afhankelijkheid, versterkt door de mogelijkheden van een middleware op het vlak van beheer.

Een nieuwe tekening

Als we dan opnieuw een tekening gaan maken met daarin een middleware dan zal opvallen dat er 1) meer lijntjes zijn en 2) één systeem het centrale middelpunt vormt: een middleware.

grafiek1

De extra lijnen komen doordat deelprocessen meer van elkaar zijn ontvlochten. Het centrale middelpunt komt doordat een middleware gemaakt is als zeer flexibel communicatieplatform. Dit in tegenstelling tot een hard-coded stukje maatwerk. Ieder systeem kan op deze manier informatie krijgen via het voor hem gewenste kanaal (REST, FTP, …) en in het voor hem beste formaat (XML, JSON, CSV, ..).

Naast de benoemde opvallendheden is het in het nieuwe scenario mogelijk geworden wijzigingen in je e-commerce platform door te voeren zonder daarbij andere systemen dan de middleware te raken. Daarnaast kan het OMS offline gaan zonder dat de e-commerce omgeving hier last van heeft. Ook kan de middleware informatie naar meerdere systemen sturen zonder hiervoor veel te hoeven aanpassen.

Het toevoegen van een extra systeem (bijvoorbeeld omdat je orders ook via andere kanalen ontvangt) kan op deze manier ook aangesloten worden op de middleware. Dit zonder invloed op de e-commerce omgeving. Onderstaande afbeelding laat dezelfde architectuur zien waarbij het kassa-systeem is toegevoegd. Orders en retouren worden aangemeld op de kassa en verwerkt in het ERP systeem. Dit loopt voor een deel via bestaande kanalen en heeft geen verdere invloed op bijvoorbeeld de e-commerce omgeving.

grafieka

Een middleware toevoegen kan altijd nog!

Dat klopt! Uiteraard is het mogelijk om later nog een middleware te introduceren. In sommige gevallen is dat misschien ook een prima overweging. Het moet wel een doordachte keuze zijn.

Een belangrijke factor in deze keuze is het groeipad. Niet alleen in groei van bezoekers en orderaantallen (oftewel berichtverkeer) maar ook meer functionele groei en technische groei. Bij een functionele groei kun je denken aan het verkopen via andere kanalen. Het gevolg is dat je nieuwe systemen gaat integreren. Bij een technische groei doel ik bijvoorbeeld op het vervangen van je interne backoffice systemen. Dit kan bij een directe integratie met je e-commerce omgeving een grote, ongewenste impact hebben.

De ervaring leert ons echter dat het uitstellen van een middleware bij doorgroei kan zorgen voor “zorgelijke” situaties. Situaties waarbij het systeem en het proces onder druk komen te staan omdat er niet snel genoeg geschakeld kan worden vanuit business perspectief of omdat de beheersbaarheid van veel code en berichtverkeer te wensen overlaat.

Tegelijkertijd is het alsnog introduceren van een middleware een kostbare operatie. Alles en iedereen moet zich gaan aanpassen aan de nieuwe situatie en dat heeft veel impact. Niet alleen op de doorlooptijd maar ook wat investering betreft.

To middleware or not to middleware?

That’s the question! Bij het maken van deze keuze zijn een paar vragen relevant. Een van de vragen gaat over de businesscase. Heb je bijvoorbeeld een webwinkel met 200 orders per dag en een groeiambitie van 300% of meer binnen 2 à 3 jaar? Dan is een middleware veel beter in staat om de groei te managen.

Een tweede vraag gaat over de verscheidenheid en veranderingen in het technisch landschap. Is er maar één systeem betrokken in het ICT landschap en voorzien we hierin weinig verandering? Dan hoeft het geen probleem te zijn hier in eerste instantie direct op te integreren. Is er sprake van een variëteit aan systemen met verschillende eigenschappen, dan is het direct interessant te kijken naar een middleware om daarmee het geheel flexibel en beheersbaar te maken/houden. Ook als we weten dat ICT systemen vervangen gaan worden op afzienbare termijn kan dat een reden zijn om zeer zeker wel te kijken naar een middleware. Veranderingen van systemen zijn dan makkelijker op te vangen.

grafiek4

Kortom: een middleware kan veel toegevoegde waarde leveren en is echt het overwegen waard in een e-commerce omgeving. Budget, doelstelling en complexiteit van de ICT omgeving spelen een belangrijke rol bij deze overweging.

Bart is teamlead Techniek. Binnen De Nieuwe Zaak houdt hij zich bezig met de technische doorontwikkeling van de projecten en het aansturen van het technisch team.
Blijf op de hoogte

Meld u aan voor onze wekelijkse e-commerce nieuwsbrief en blijf op de hoogte van het laatste e-commerce nieuws!

© 2018 De Nieuwe Zaak