Alles over MACH commerce: voordelen, verschillen en tips

Moderne klanten zijn enorm veeleisend en wil graag de allerbeste klantreis van oriëntatie tot bezorging. Een simpele webshop is daarom al lang niet meer genoeg. In plaats daarvan richten we ons nu op complexe e-commerce ervaringen, die plaatsvinden over meerdere kanalen waaronder social media en online zoekmachines.

Hoewel frameworks als Magento of Shopware krachtig zijn, bestaan er kleinere oplossingen die uitblinken in één taak. Wanneer je deze bundelt en met elkaar verbindt, creëer je een geheel dat de potentie heeft krachtiger te zijn dan bestaande frameworks. In deze blog leggen we je uit hoe MACH commerce werkt, welke voordelen je er uit haalt en hoe jij de eerste stappen zet om deze voordelen in huis te halen.

De term MACH is een acroniem voor vier verschillende technieken: Microservices, API-first, Cloud(-native) en Headless. De MACH-architectuur wint populariteit binnen e-commerce land omdat het voor veel bedrijven en merken een slimme stap voor de toekomst is. MACH commerce heeft namelijk een aantal grote voordelen ten opzichte van een traditionele e-commerce architectuur.

Waar staat MACH voor?

• Microservices
  Bij traditionele, of monolithische platforms, heb je één systeem waar je vanuit werkt.Vandaar ook de naam: het betekent letterlijk ‘een eenheid’. Met MACH-architectuur is het werken binnen grote, all-in-one platforms verleden tijd. Hier kies je juist voor kleinere, onafhankelijke zogenaamde ‘microservices’. Dit zijn de allerbeste oplossingen voor de toegewezen taak of jouw favorieten. Voorbeelden van microservices zijn PIM-systemen, betaalmethodes, accountmanagement en mailing platforms, of denk aan kleinere taken zoals de checkout, zoekbalk of verlanglijst. In een MACH frontend vervang je deze taken door betere alternatieven.

• API's (Application Programming Interfaces)
  Gebruik maken van die onafhankelijke services is natuurlijk mooi, maar los van elkaar doen ze niets. Daarvoor gebruik je API’s. Als de microservices de bakstenen zijn van je MACH-huis, dan zijn de API’s het cement dat alles bij elkaar houdt. De API’s verbinden de microservices met elkaar en maken het mogelijk om data over en weer te zenden. Uiteindelijk krijg je zo één naadloze ervaring als gebruiker.

• Cloud-native
  Een beetje controversieel, maar steeds meer e-commerce platforms zijn volledig gehost in de cloud. Bij MACH-commerce is dit niet anders. Sterker nog, het is één van de vereisten. Cloud-native betekent dat alle op het platform aangesloten microservices gehost zijn in de cloud. En aangezien die services het geheel vormen, draait alles dus in de cloud. Veel oplossingen waar MACH-architectuur gebruik van maakt, zijn SaaS platforms: Software as a Service. Voor een vast bedrag per maand of per jaar neem je deze af. In ruil daarvoor hoef je zelf niets te hosten, te updaten of te downloaden. Zo heb je dus (zolang je internet hebt) vanaf alle locaties en devices toegang tot alle onderdelen van je e-commerce platform.

• Headless
  Simpel gezegd is headless commerce het lostrekken van je frontend en je backend. Aangezien bij een MACH-architectuur eigenlijk alles toch al losgetrokken is, is een headless opzet vaak vanzelfsprekend. De headless opzet van je MACH platform maakt het mogelijk om de data vanuit je verschillende microservices te presenteren op zoveel mogelijk kanalen. Denk aan websites, apps, maar ook bestelzuilen of zelfs interfaces zonder beeld zoals voice assistants. Met headless maak je je MACH platform pas echt flexibel.

Er zijn verschillende voordelen van een MACH-architectuur ten opzichte van een monolithische architectuur zoals Magento of Shopware:

• Flexibiliteit en modulariteit
  Het gebruik van de microservices als backend, gecombineerd met de headless frontend maakt een MACH platform enorm flexibel. Aanpassingen aan bijvoorbeeld productdata of zoekalgoritmen zijn mogelijk zonder andere onderdelen van je platform te moeten aanpassen. Bovendien update je de microservices onafhankelijk van elkaar naar hun nieuwste versie. Ook op frontend gebied ben je erg flexibel. Voor een frisse look van een pagina maak je gebruik van dezelfde API’s als voorheen. Ten slotte is het binnen een MACH-architectuur ook makkelijk om nieuwe microservices toe te voegen of microservices die niet meer nodig zijn te vervangen. Kortom, je hebt veel meer controle over je e-commerce platform.

• Schaalbaarheid
  Een ander voordeel van een opgesplitste backend bestaande uit microservices, is dat je daarmee een enorm schaalbaar platform hebt. Lange laadtijden op je e-commerce platform zorgen voor minder conversies. Is een van je microservices te traag? Dan schaal je deze binnen een MACH opzet omhoog zonder impact op je andere services. Dat scheelt weer kosten voor je cloudhosting. Andersom bespaar je natuurlijk ook kosten door services met overhead terug te schalen. En wederom blijven andere services even snel. Met positieve gevolgen zoals efficiëntie en conversies.

• Snellere ontwikkeling en implementatie
  Dat de backend en frontend services los van elkaar aan te passen zijn, is superhandig. Daarmee ben je niet alleen flexibel (zoals eerder benoemd), maar ook sneller. Je frontend en backend developers werken dankzij de headless opzet tegelijkertijd en zonder hinder van elkaar. Sterker nog, zelfs voor verschillende backenders is het mogelijk parallel te werken aan verschillende microservices. Developers hoeven niet meer op elkaar te wachten om een update te doen, aangezien de API’s onveranderd blijven. Dat scheelt tijd. Bovendien werken ze geconcentreerd aan één feature, aangezien ze geen rekening hoeven te houden met impact op andere systemen. Zo rol je binnen no-time nieuwe updates uit. Perfect om in te spelen op veranderende consumentenbehoeftes als uitgebreidere bezorgopties en opkomende trends, bijvoorbeeld een AI-tool.

• Inspelen op piekmomenten
  Bij piekmomenten heeft een server in eigen beheer het soms zwaar te verduren. Omdat MACH-platforms gehost worden in de cloud, ben je niet meer afhankelijk van je eigen servercapaciteit. Dit maakt het veel makkelijker om bij te schalen op high-traffic momenten. Zo blijft je platform lekker snel. Veel cloud-native tools hebben vaak dynamische opties, zodat je hier zelf amper naar om hoeft te kijken.

• Geen volledige replatforming
  Replatformen met piek-investeringen is verleden tijd met MACH commerce. In plaats daarvan vervang je bijvoorbeeld enkel je CMS wanneer deze verouderd is. De rest van je architectuur blijft onveranderd, dus je bent binnen snel weer up-to-date voor een fractie van de kosten die je bij een monoliet zou maken.

• Integreren en experimenteren
  De flexibiliteit van MACH commerce benut je pas echt goed wanneer je gaat experimenteren. Een MACH platform stelt je in staat om nieuwe toevoegingen aan je architectuur te proberen met beperkt risico. Dankzij de API’s sluit alles wat je wilt testen naadloos aan op je architectuur. Bovendien koppel je het ook met gemak los, mocht het niet bevallen.

Hoewel een MACH-architectuur veel voordelen biedt, zijn er ook nadelen vergeleken met een monolithische architectuur. Houd dit in gedachten:

• Complexiteit van het beheer
  Ondanks de beperkte vrijheid die je bij monolithische platforms hebt vergeleken met MACH, zijn ze wel makkelijker te beheren. De microservices bij een MACH-architectuur zijn hyper-gespecialiseerd, waardoor je voor elke taak moet inloggen bij een ander platform. Bij een monoliet geniet je van het gemak dat je slechts op één platform moet inloggen. Bovendien zijn de verschillende onderdelen van een monolithisch platform al automatisch aan elkaar verbonden. Bij een MACH platform moet je alle microservices via de API’s aan elkaar koppelen voordat je architectuur met elkaar verbonden is.

• Complexer voor ontwikkeling
  Werken binnen een MACH-architectuur vereist een nieuwe manier van werken, met name voor developers. Deze zijn vaak de ‘klassieke’, monolithische manier van werken al jaren gewend. Binnen MACH platforms moeten ze op een andere manier wijzigingen doorvoeren. Aanpassingen doen in MACH moet bijvoorbeeld zo veel mogelijk aan de bestaande API’s, om de afhankelijkheden tussen microservices te waarborgen.

• Netwerk overhead
  Het functioneren van een MACH platform is volledig afhankelijk van de communcatielaag, de API’s. Deze sturen data over en weer tussen de verschillende microservices, wat bij veel dataverkeer de serverlast (of eigenlijk cloudlast) van je platform verhoogt. Bij monolithische platforms is dit vaak minder het geval. Daar zijn de verschillende services namelijk onderdeel van één pakket en specifiek gemaakt om met elkaar te communiceren. Omdat ze binnen hetzelfde platform draaien, weten ze van elkaar hoe de data ontvangen moet worden. Bij de losse microservices binnen MACH ontbreekt deze kennis, waardoor er meer dataverkeer plaatsvindt.

• Toename van operationele complexiteit
  Hoewel developers sneller werken binnen een MACH-architectuur, kost het behoorlijk meer operationeel (denk)werk. Er zit veel werk in bijvoorbeeld het onderzoek naar implementatie en het beheren van toegang. Dat laatste komt doordat je veel losse services onder je beheer hebt, waaronder bijvoorbeeld PIM-systemen en securityplatforms, elk met hun eigen inloggegevens. Ook het plannen van onderhoud en ontwikkeling van al deze systemen tegelijkertijd is bij MACH een uitdaging.

• Gevoeligheid voor downtime
  Omdat je met MACH commerce afhankelijk bent van een flink aantal kleinere platforms, ben je ook gevoeliger voor downtime. Is er serveronderhoud aan de microservice van je zoekfunctie, dan gaat dat meteen ten koste van de gehele klantervaring. Idem dito voor de checkout of payment services. De cloudhosting van MACH platforms is een potentieel voordeel, maar op deze manier mogelijk ook een nadeel. Met een monolithisch platform in eigen beheer bepaal jij zelf wanneer de downtime plaatsvindt.

Ondanks bovenstaande punten blijft de MACH-architectuur een slimme en moderne keuze voor veel organisaties. Veel van deze uitdagingen zijn te overwinnen met sterk beheer en een goede implementatie.

Heb je al een e-commerce platform en klinkt dit allemaal aantrekkelijk? Wij raden je af in één keer volledig over te gaan op MACH. Wil je overstappen naar een MACH-architectuur, dan is het beter om verschillende onderdelen van je platform stap voor stap te vervangen door cloud-based alternatieven. Begin bij frontend: als deze nog niet headless is, start je hiermee. Daarna zou een logische stap zijn om een PIM-systeem toe te voegen aan je composable architectuur. Vaak kom je dan al snel aan bij een integratieplatform zoals Elastic.io, en dan ben je eigenlijk al voor een deel over naar een MACH-architectuur. Realistisch gezien blijf je bij veel e-commerce platforms nog steeds een aantal functionaliteiten samen onderbrengen. Zelfs de meest populaire MACH backend, commercetools, is een verzameling van meerdere features.

Overstappen naar MACH ziet er in een notendop zo uit:

• Beslis welke functionaliteit je wilt vervangen door een microservice. Kies datgene waarmee je de meeste stappen kunt zetten of winst kunt behalen.

• Stel een lijst op met de eisen voor de service en doelen voor je platform na de toevoeging van de service.

• Onderzoek welke services er bestaan voor deze functionaliteit en hoe deze aansluiten op je huidige architectuur.

• Richt een testomgeving in voor de nieuwe service en test of deze echt voldoet aan jouw eisen.

• Tevreden? Koppel dan de nieuwe service met je architectuur en ontkoppel indien nodig je oude service of component.

• Zet je geüpdatete architectuur live en verzamel data. Haal je hiermee jouw gestelde doelen?

• Evalueer de toevoeging van de microservice en verbeter je operationele proces.

• Herhaal de bovenstaande stappen totdat je platform volledig MACH is.

Voor veel partijen is het soms beter om niet volledig MACH te gaan. Een simpelere opzet met bijvoorbeeld enkel Shopware, PimCore en een headless frontend is vaak al meer dan genoeg. Bovendien heb je door zo’n semi-composable opzet minder overheadkosten en complexiteit. Simpel gezegd geniet je zo van de voordelen van een MACH-architectuur en de betrouwbaarheid van een monolithisch platform. Let wel op wanneer je op deze manier gedeeltelijk voor MACH gaat, dat je niet te veel features afhankelijk maakt van je backend. Je wil immers wel de optie houden deze te vervangen, bijvoorbeeld wanneer de kosten hiervan oplopen.

Een mooi voorbeeld van zo’n semi-MACH-architectuur is het e-commerce platform van Kwalitaria. Hun bestaande kassasysteem werd de basis voor het productmanagement, wat communiceerde met de nieuwe headless frontend. Bovendien zijn er losse componenten voor het zoeken van producten en zelfs voor het valideren van postcodes. Na de livegang van het platform hebben we een volledig nieuw loyaliteitsprogramma toegevoegd. Dankzij de semi-composable opzet, was deze uitbreiding gemakkelijk en snel uit te voeren.

Bekijk Kwalitaria case

Steeds meer bedrijven zien baat in de flexibiliteit en schaalbaarheid van MACH commerce. Headless, PWA en serverless: allemaal termen die we de afgelopen jaren voorbij zagen komen. Met MACH-architectuur is het makkelijker dan ooit om in te spelen op dit soort trends.

Ook neemt de populariteit van omnichannel commerce toe. Onze directeur Wim, ook onderdeel van expertgroep ShoppingTomorrow (de omni-commerce architectuur van de toekomst), voorspelt dat in 2030 alles shoppable gaat zijn. Daarmee bedoelt hij dat er winkelmogelijkheden ontstaan op alle kanalen van smartwatch tot metaverse. De headless opzet en uitgebreide API’s van MACH platforms maken het mogelijk om in de toekomst shopping ervaringen op maat aan te bieden over een breed scala aan platforms. De data die je over de verschillende kanalen verzamelt, zet je vervolgens weer in om overal personalisatie toe te passen. Er zijn dus veelbelovende omnichannel kansen voor platforms met een MACH-architectuur.

Juist omdat MACH steeds meer grond wint, verschijnen er ook meer tools en frameworks die hierop inspelen. Kort gezegd: de tech stack verbetert. Naarmate de lifecycle van MACH commerce evolueert, is het steeds makkelijker om deze platforms te ontwikkelen en beheren. Plus, meer bestaande platforms gaan openstaan voor MACH integraties naarmate het gebruik hiervan toeneemt. Dat opent weer mooie kansen voor nieuwe samenwerkingen.

Of je MACH commerce nodig hebt, hangt af van de complexiteit van je platform. Voor e-commerce bedrijven die op kleinere schaal opereren, voldoet een monolithisch platform als bijvoorbeeld Shopware. Heb je grote ambities? Dan is MACH-architectuur een slimme investering in de toekomst van je platform. De eerste stap is een piek-investering, maar die heb je daarna niet meer. In plaats daarvan ben je vrij om microservices te vervangen naar jouw wens. Bovendien stel je met MACH commerce een naadloze ervaring samen die uitblinkt op elk onderdeel. En dat is precies wat jouw klanten willen.

Platformkeuzehulp Contact opnemen