Blog

MACH op de markt: wanneer wel/niet een slimme keuze?

In deze blog vatten we onze learnings vanuit onze expertgroep (de omni-commerce architectuur van de toekomst) samen. Met deze keer uitleg over MACH, welke na- en voordelen er zijn, MACH-aanbieder Commercetools en wanneer het wel en juíst niet een slimme keuze is.

Je slimme koelkast die automatisch yoghurt bestelt als deze op raakt of een product bestellen in je auto bij een melding dat een product weer op voorraad is. Het zijn scenario's die voor sommigen nog niet realistisch lijken, maar dat dachten we tientallen jaren geleden ook over het gebruik van de mobiel. Als technologie iets makkelijker maakt, is de kans groot dat we het adopteren.

Om in te spelen op dit soort ontwikkelingen, wil je als organisatie je architectuur flexibel inrichten. Dat betekent niet volledig leunen op een monoliet zoals Magento of Shopify, maar je platform aansluiten met zogenaamde ‘microservices’, die heel goed werken op een bepaald gebied zoals zoekfunctie, producten of shopping cart. Zo zetten organisaties hun landschap flexibeler op en zijn ze toekomstvaster.

De markt naar MACH(o)

Om de zoveel jaar een nieuw buzzword of trend lijkt een garantie in e-commerce. We spreken nu van MACH - wat ongetwijfeld een buzzword is – en toch zeker een waardevolle ontwikkeling voor veel merken in de toekomst. MACH houdt in:

  • Microservices
    Een microservice draait een aparte applicatie die je koppelt aan bestaande systemen. Die gaan bijvoorbeeld over zoekfunctie, shopping cart, producten, bestellingen, klanten, enzovoorts. Het voordeel hiervan is dat je het kunt schalen, optimaliseren, verbeteren of zelfs compleet vervangen, zonder dat dit impact heeft op andere systemen. Dit maakt het onderhoud van een volledige e-commerce architectuur een stuk makkelijker en je beperkt de risico’s.

  • API-first
    Alle systemen communiceren met elkaar via API’s, waarbij in elke API strak gedefinieerd staat welke functionaliteiten een microservice ter beschikking stelt en welke data daarvoor nodig is. Belangrijk: ze communiceren dus met elkaar, maar zijn niet afhankelijk van elkaar.

  • Cloud-native
    Als jij je architectuur wilt integreren met meerdere systemen dan lukt dat niet wanneer eigen systemen niet cloud-native zijn aangezien ze dan niet kunnen communiceren.

  • Headless
    Dit betekent dat je kernsystemen niet meer verantwoordelijk voor de frontend zijn. Frontend en backend opereren dus min of meer zelfstandig en zijn ook afzonderlijk te onderhouden of te vervangen.

Sommige mensen plakken een ‘O’ aan 'MACH' vast, omdat ‘omnichannel’ niet zou mogen ontbreken. Feit is dat er een zogenaamde MACH-alliantie bestaat, waar je niet zomaar toe mag treden. Al je producten moeten namelijk onder de strenge criteria vallen. Dat wil zeggen dat je als je nog een dienst aanbiedt die niet MACH is, je deze niet verder mag ontwikkelen. Zo spreekt men zelfs al van ‘MACH-washing’.

Hier vind je de MACH selectiecriteria.

MACH is toekomstbestendig en flexibel, en daarmee richt je je op het leuke gedeelte: groeien en schalen. Waar MACH meer uitdagingen kent:

  • Selectieproces
    Een nadeel van een MACH-oplossing is dat je meerdere selectieprocessen hebt. Je moet een PIM-systeem, CRM, search service, enzovoorts selecteren en blijven evalueren. Dat kost tijd en is een doorlopend proces;

  • Partnerkeuze
    Je partner gaat ervoor zorgen dat alles met elkaar communiceert, kijk daarom naar de ervaringen van je partner en zoek een goede samenwerking. Ook omdat doorlopend blijft evalueren en optimaliseren;

  • Kosten
    Deze kunnen hoger zijn op de lange termijn, aangezien je meer implementatiekosten kwijt zou kunnen zijn aan de verschillende systemen en microservices die je gaat integreren. Ook de total cost of ownership (TCO) zouden hoger kunnen zijn, aangezien je eerst de componenten neer wilt zetten. Gelukkig kun je na ongeveer twee jaar juist veel sneller ontwikkelen in vergelijking met een monoliet, waar het in de praktijk vaak draait om het updaten van het systeem.

Monoliet of MACH?

Net zoals wanneer je een nieuwe auto koopt en de motor moet vervangen, dan kan een monolithische oplossing wellicht niet de beste oplossing zijn. Voldoet de auto precies aan jouw wensen, juist wel.

Toch zien we dat steeds meer organisaties wegbewegen van een monolithische oplossing zoals Magento of Shopware en kiezen voor een MACH of composable oplossing. Monoliet of MACH: wat is de beste keuze voor jouw? Hieronder geven we je een aantal handvatten.

Signalen om over te stappen naar MACH:

  • Limitaties
    Zijn er bepaalde endpoints die je niet aan kunt spreken, is een bepaalde promotie niet mogelijk of ben je gelimiteerd in het aanbieden van nieuwe merken, landen of businessmodellen? Dan is een overstap naar composable of MACH wellicht waardevol;

  • Complexiteit
    Denk aan het hebben van veel integraties of producten met unieke eigenschappen die je toebedeeld met een productconfigurator;

  • Flexibiliteit
    Als je snel wilt schakelen of nieuwe touchpoints zoals in-car commerce of een chatbot wilt aansluiten, kan een composable architectuur sneller in dienst staan door de aangesloten microservices;

  • Modulariteit
    Je wilt geen lock-in, maar constant de mogelijkheid om functionaliteiten te vervangen wanneer je dat wilt;

  • Headless
    Veel merken lopen tegen een muur wanneer ze iets willen aanpassen aan de voorkant, maar daarbij afhankelijk zijn van de backend. Met een headless architectuur ben je vrijer en flexibeler;

  • Schaalbaar
    Als je bijvoorbeeld veel producten aanbiedt, veel traffic hebt op feestdagen of wanneer je uitbreidt naar een ander land, dan blijft de performance van je webshop goed;

  • Time to market
    Bijvoorbeeld wanneer je ambitie is om te internationaliseren. In een composable architectuur kun je beginnen met één land en vervolgens doorontwikkelen naar andere landen of implementaties gefaseerd doen.

Signalen om niet over te stappen naar MACH:

  • Standaard is genoeg
    Wanneer je aan standaardfunctionaliteiten genoeg hebt – als je bijvoorbeeld voor 95 procent goed zit -, raden we je aan om niet over te stappen. Een monoliet zoals Shopify met aanvullingen van SaaS-oplossingen kan dan voldoende zijn;

  • Geen ambitie voor innovatie
    Heb je een vrij standaarde e-commerce flow en niet de ambitie om te innoveren of uniek te zijn met bijvoorbeeld nieuwe technologie of UX, dan is een monoliet wellicht een betere optie. Vooral als je je shop in precies hetzelfde jasje wilt steken maar dan op een ander platform;

  • Focus op offline verkopen
    De meeste merken hebben de ambitie om steeds meer online te verkopen. Als dit voor jou niet zo geldt en je wilt bijvoorbeeld 70 procent offline verkopen en 30 procent online, ook in de toekomst, weeg dan af hoe groot de rol en het voordeel van een MACH-oplossing gaat zijn;

  • GO van organisatie
    Je gaat van zogezegd één systeem naar losstaande systemen, dat veel afdelingen en mensen binnen je organisatie beïnvloedt. De hele organisatie dient dus wel aan boord te zijn, anders gaat er nooit een druk op de groene knop komen;

  • Geen tijd, prioriteit of resources
    Als deze er niet zijn, dan zou je er niet aan moeten beginnen. Een MACH-oplossing vergt tijd en is echt iets voor de langetermijn, dan ga je de vruchten plukken. Onderzoek dus goed of hier tijd, prioriteit en resources voor beschikbaar zijn voordat je eraan begint.

Bij het maken van de keuze kijk je vooral ook toekomstgericht: wat is je strategie, welke systemen wil je nog aansluiten en welke functionaliteiten zijn onmisbaar – nu en in de toekomst. Vooral MACH en composable-oplossingen zijn meerjarige trajecten.

MACH-aanbieder: Commercetools

Aangesloten tot die MACH-alliantie is Commercetools, een headless e-commerce platform. Waar veel andere platformaanbieders een all-in-one systeem willen zijn, bekent Commerctools duidelijk kleur: ze zijn geen CMS of ERP, maar een e-commerce motor waar je oneindig veel systemen op aansluit. Wanneer een order is gedaan, verwerken zij deze zo snel mogelijk door hun trigger-gestuurde architectuur.

Met Commercetools leg je een extreem sterke, flexibele basis en voor hen maakt het niet uit welke ‘head’ je daar op toepast. Want of het nu een winkel of ander point of sale is, een slimme koelkast of een Apple bril; ze modelleren steeds opnieuw voor aansluiting. In principe kun je 80 tot 90 procent vanuit commercetools bouwen, maar wil je een uniek businessmodel, tweedehandsmodellen, abonnementen, aansluitservices, virtuele producten, enzovoorts, dan wil je dit wellicht in de zogenaamde ‘microservices’ bouwen.

"Of er over zes jaar nog wel monolieten zijn? Lastig te voorspellen, maar we zien wel bij klanten dat ze hun monoliet steeds meer aanvullen, bijvoorbeeld met een CMS en search."

Waar Commercetools zich tijdens haar bestaan zich op B2C focust, hebben zij momenteel toch 40 procent B2B-klanten. De focus is daarmee verlegd. Ze gaan daar nieuwe B2B-functionaliteiten bouwen waar de nadruk bijvoorbeeld minder op ligt op transacties en meer op herhaalbestellingen.

Beginnen met MACH

Eerst maak je inzichtelijk wat er nodig is qua organisatie en technologie. Leun hierbij ook zeker op de expertise van je implementatiepartner. Dan is snel en klein starten belangrijk. Gebruik hiervoor microservices en test en deploy kleinere use cases - kies bijvoorbeeld een land, merk of nieuw product - en schaal daarna pas door.

Vervolgens raden we je aan om je monoliet als het ware uit te kleden en deze stukje voor stukje te vervangen door microservices (via een strangler approach). Verder enorm belangrijk om te sparren met partijen die ervaring hebben met MACH en van hen praktijkervaringen te leren.

Conclusie

We zien dat steeds meer organisaties kiezen voor een MACH of composable oplossing. Het brengt meer schaalbaarheid en flexibiliteit, maar ook toekomstperspectief. Voor veel organisaties lijkt het nu al een opgave om website, app, winkel en click-and-collect naadloos op elkaar aan te sluiten, laat staan als daar de verkoop van tweedehandsproducten, abonnementen, aansluitservices, virtuele producten, enzovoorts bij komen.

Toch hoeft MACH of een composable oplossing niet voor iedereen de beste keuze te zijn. Overleg daarom goed met stakeholders en je implementatiepartij (als deze hier ervaring mee heeft) om tot een architectuur te ontwikkelen die toekomstbestendig is.