Composable commerce: wat het is en wanneer het bij je webshop past

Composable commerce is een manier om je online business op te bouwen uit losse, vervangbare onderdelen, die elk één bedrijfsfunctie afdekken: de productcatalogus, prijzen, winkelwagen en checkout, zoeken, content of orderbeheer. De onderdelen praten via API's met elkaar. In plaats van één platform dat alles doet, kies je per taak een onderdeel en vervang je er één zonder de rest opnieuw te bouwen. Shopify omschrijft het als het kiezen en koppelen van "best-in-breed technologies" via API's (Shopify).

Volgens Shopify heeft analistenbureau Gartner de term bedacht. De bouwstenen heten packaged business capabilities (PBC's) en de architectuur volgt meestal de MACH-principes. Voor de meeste middelgrote webshops is het praktische antwoord niet "volledig composable", maar "modulair waar het knelt": houd een commerceplatform als kern en vervang specialistische onderdelen één voor één. In elke variant heeft productdata precies één eigenaar nodig, en dat is de taak van een PIM.

Packaged business capabilities: één bedrijfstaak per onderdeel

Een packaged business capability is volgens Shopify een softwareonderdeel dat "a particular business function" vertegenwoordigt, zoals checkout of zoeken. Commerce Layer beschrijft een composable stack als opgebouwd rond PBC's die "individually developed, deployed, and managed, connected through APIs" zijn (Commerce Layer).

In een gangbare commercestack zien de PBC's en de data die ze beheren er zo uit:

• Productinformatie: producten, attributen, varianten, vertalingen, afbeeldingen en categorie-indeling.
• Prijzen en acties: prijslijsten per land of klantgroep, kortingen en couponregels.
• Winkelwagen en checkout: winkelmandjes, verzendopties en de btw-berekening bij het afrekenen, zoals 21% in Nederland.
• Betalingen: betaalmethoden zoals iDEAL en Bancontact, autorisaties en terugbetalingen.
• Zoeken en merchandising: de zoekindex, synoniemen en regels voor ranking en boosting.
• Content: landingspagina's, banners, koopgidsen en andere redactionele pagina's.
• Orderbeheer: orders, voorraadtoewijzing over magazijnen, fulfilment en retouren.
• Klantaccounts: logins, adressen, B2B-bedrijfsaccounts en loyaliteitspunten.

Een PBC is niet hetzelfde als een microservice. Checkout is een PBC omdat het een complete bedrijfsuitkomst levert; adresvalidatie binnen de checkout is een microservice. Eén PBC kan uit meerdere microservices bestaan, en één leverancier kan meerdere PBC's verkopen.

MACH, letter voor letter

MACH is het label dat de meeste composable-leveranciers gebruiken voor de technische principes achter hun producten. Het wordt gepromoot door de MACH Alliance, die in juni 2020 werd opgericht door commercetools, Contentstack, EPAM Systems en Valtech, en staat voor "Microservices based, API-first, Cloud-native SaaS and Headless" (Gilbane).

• M van microservices: elke functie bestaat uit een reeks kleine services die elk in een eigen proces draaien en via lichte API's communiceren, de definitie die Martin Fowler en James Lewis in 2014 gaven (Martin Fowler). In ons woordenboek lees je meer over microservices-architectuur in e-commerce.
• A van API-first: elke functie is via een gedocumenteerde API beschikbaar voordat er een gebruikersinterface op wordt gebouwd.
• C van cloud-native SaaS: de leverancier host, schaalt en updatet de dienst; jij gebruikt hem in plaats van hem te installeren.
• H van headless: geen ingebouwde webwinkel; de voorkant is een aparte applicatie.

MACH beschrijft onderdelen; composable beschrijft hoe je ze samenstelt. Een stack kan composable zijn zonder dat elk onderdeel MACH is. Veel composable opstellingen houden een on-premise ERP of een ouder magazijnsysteem aan en zetten daar een API omheen. Ons woordenboekitem over MACH-architectuur gaat in op de certificering.

Wat je wint door onderdelen één voor één te vervangen

De argumenten voor composable commerce komen neer op een paar concrete voordelen. Ze zijn echt, maar elk ervan hangt af van het integratiewerk dat verderop aan bod komt.

• Een zwakke functie vervangen zonder replatforming. Vindt je zoekfunctie technische artikelnummers niet, dan vervang je het zoekonderdeel en laat je checkout, orders en webwinkel met rust.
• Een specialist per taak. Een B2B-verkoper kan een pricing-engine toevoegen die prijslijsten per dealer aankan, iets wat veel alles-in-één-platformen alleen via apps afdekken.
• Losse releasecycli. Het frontendteam lanceert een nieuwe productpagina zonder op een back-end-release te wachten, en andersom.
• Schalen waar de drukte zit. Bij cloud-native SaaS-onderdelen schaalt de leverancier zoeken of de webwinkel op tijdens een actiepiek, zonder dat jij servers voor de hele stack hoeft in te richten.

Headless vs composable commerce, en de hybride tussenvorm

De splitsing tussen voor- en achterkant bespraken we in wat is headless commerce. Het korte verschil: headless verlegt één grens, tussen webwinkel en back-end. Composable verlegt er veel, binnen de back-end. In de praktijk komen webshops uit bij een van vier opstellingen:

• Alles-in-één-platform: één leverancier verzorgt webwinkel, catalogus, checkout en orders; extra functies komen uit de app store van het platform, zoals bij Lightspeed of CCV Shop.
• Headless op één platform: een eigen voorkant bovenop één commerce-back-end.
• Hybride of modulair: een commerceplatform blijft de kern, en één of twee functies, vaak zoeken, content of productinformatie, komen van gespecialiseerde tools.
• Volledig composable: de back-end zelf bestaat uit PBC's van verschillende leveranciers, met een headless voorkant en een integratielaag ertussen.

Die hybride tussenvorm komt zelfs bij grote bedrijven veel voor. In een onderzoek dat Shopify met IDC deed onder ruim 1.000 grote bedrijven, had 45% "a composable front end with a full-stack back end" (Shopify). Het onderzoek gaat over grote ondernemingen, niet over middelgrote webshops, die meestal minder developers hebben om een volledig composable back-end te draaien.

Welk systeem welke data beheert in een composable stack

De belangrijkste ontwerpbeslissing is niet welke leveranciers je kiest, maar welk systeem de bron is voor elk soort data. Neem een middelgroot outdoormerk met 4.000 SKU's, webshops in Nederland, België en Duitsland, een B2B-portaal voor dealers en verkoop via bol en Kaufland:

De regel achter deze tabel: elk veld wordt op één plek geschreven en overal elders gelezen. Kunnen de PIM én het commerceplatform producttitels aanpassen, of houdt het CMS een eigen kopie van een productomschrijving bij, dan lopen de versies uit elkaar en weet niemand meer welke klopt. SKU en GTIN worden de sleutels waarmee systemen elkaar vinden, dus die moeten uniek en stabiel zijn.

Wanneer composable commerce past bij een middelgrote webshop

Shopify zegt zelf dat composable "probably not right for you" is, tenzij je digitaal volwassen bent, met een ervaren ontwikkelteam en complexe leveringseisen. Voor een middelgrote webshop helpen deze signalen bij de keuze.

Signalen die voor composable onderdelen pleiten

• Eén functie van je huidige platform remt de omzet en geen app lost het op, bijvoorbeeld B2B-prijslijsten per dealer of zoeken in 40.000 technische SKU's.
• Je verkoopt via meerdere voorkanten (webshops per land, een B2B-portaal, schermen in de winkel) die producten, prijzen en voorraad moeten delen.
• Je hebt eigen developers of een bureau met een langlopend contract, en iemand die eigenaar is van de integratielaag.
• Je productdatamodel is al op orde: getypeerde attributen, echte varianten, één SKU per verkoopbaar artikel.

Signalen die voor een platform met een paar specialistische tools pleiten

• Je team past de webshop vooral aan via beheerschermen en apps, zonder developer op afroep.
• Je groeiprobleem is verkeer, assortiment of productcontent, niet de grenzen van je platform.
• Je draait één of twee webshops in een paar talen, en het platform doet checkout, betalingen en orders goed.
• Je catalogus heeft nog gaten, zoals ontbrekende attributen, leveranciersteksten en wisselende eenheden. Systemen opsplitsen verspreidt die gaten over meer plekken.

Veel webshops in die tweede groep hebben toch baat bij één composable stap: productinformatie uit het beheer van de webshop halen en onderbrengen in een PIM die elk kanaal voedt. Dat levert de meeste datavoordelen op zonder dat je je checkout opnieuw bouwt.

Doorlopende kosten die in een composable businesscase vaak ontbreken

Licentiekosten per onderdeel zet je zo op een rij. Deze kosten niet, en ze lopen door zolang de stack bestaat:

• Integraties bouwen en onderhouden: elke koppeling tussen onderdelen is code die iemand schrijft, test en bijwerkt als een van beide kanten zijn API verandert.
• Monitoring over leveranciers heen: mislukt een order, dan volg je hem door webwinkel, checkout, betalingen en orderbeheer, elk met eigen logs.
• Nieuwe API-versies: leveranciers schrappen oude API-versies op hun planning, niet op die van jou.
• Datamapping: elk onderdeel heeft een eigen model voor producten, prijzen en klanten, en iemand moet de vertaling daartussen bijhouden.
• Leveranciersbeheer: meer contracten, meer verlengingen, meer security-reviews.
• Kennis: composable vraagt mensen die het hele systeem overzien, niet één tool. Shopify waarschuwt dat onderhouds- en updatekosten met meerdere leveranciers snel oplopen.

De PIM als productfunctie die elk ander onderdeel uitleest

In een composable stack is productinformatie een functie op zich. De webwinkel, zoekfunctie, marketplaces, feeds, het B2B-portaal en het CMS lezen er allemaal uit. Dat legt de lat hoger voor wat de PIM moet leveren:

• Een helder datamodel: productfamilies, getypeerde attributen met eenheden, varianten en relaties, zodat elk systeem dezelfde structuur leest.
• Validatie vóór publicatie: regels voor volledigheid en formaat per kanaal, zodat zoekfunctie en feeds geen halve producten oppikken.
• API's en events: een API om te lezen en te schrijven, en events of webhooks zodat zoekindexen en caches van de webwinkel bijwerken zodra een product verandert. Ons woordenboekitem over event-driven architecture legt het patroon uit.
• Output per kanaal: hetzelfde product met een korte titel voor bol, een lange omschrijving voor de webshop en een andere attribuutnaam voor een feed.
• Lokalisatie: vertaalde teksten en gelokaliseerde attribuutwaarden voor elke markt, zoals Nederlands, Frans en Duits voor de Benelux en Duitsland.
• Stabiele identificatiecodes: SKU en GTIN blijven uniek, omdat elk ander systeem erop koppelt.

Een PIM die voor deze rol is gebouwd, heet vaak een headless PIM: het contentteam werkt in een eigen interface, maar de output wordt via API gelezen in plaats van in een eigen webwinkel getoond.

Deze functie inrichten is meestal de eerste stap van een composable roadmap, niet de laatste, omdat elk volgend onderdeel ervan afhangt. Ons stappenplan voor PIM-implementatie behandelt dat project stap voor stap.

Stapsgewijs naar composable, één functie per keer

In één keer overstappen op een volledig composable stack is de riskantste route. Voor middelgrote teams werkt een gefaseerde aanpak beter:

Vijf manieren waarop composable projecten een gedistribueerde monoliet worden

1. Onderdelen die een database delen. Lezen zoekfunctie en checkout dezelfde tabellen, dan kun je de een niet wijzigen of vervangen zonder de ander te breken.
2. Lange ketens van synchrone aanroepen. Wacht de productpagina op zoeken, dat wacht op prijzen, dat wacht op voorraad, dan legt één trage dienst de hele pagina plat.
3. Twee systemen die hetzelfde veld bewerken. Producttitels die zowel in de PIM als in het webshopbeheer worden aangepast, lopen binnen weken uiteen.
4. Koppelcode zonder eigenaar. Integraties die voor de lancering zijn gebouwd en nooit aan een team zijn toegewezen, breken bij de eerste API-wijziging.
5. Onderdelen kopen voordat het data-eigenaarschap vastligt. Zonder bron per veld voegt elke nieuwe tool weer een kopie van de catalogus toe.

WISEPIM inpassen in een hybride commercestack

WISEPIM vult de functie productinformatie in. Het importeert je catalogus, vult ontbrekende omschrijvingen, attributen, vertalingen en categorieën aan met AI, controleert de volledigheid met Quality Guard en stuurt het resultaat via platformsynchronisatie naar Shopify, WooCommerce, Magento 2, Lightspeed eCom, CCV Shop, Kaufland, Google Merchant Center en andere gekoppelde kanalen. Met de optionele auto-sync staat een opgeslagen product zo'n 30 seconden later in die kanalen; geplande imports en exports lopen via automatiseringen met een trigger per uur, dag, week of maand. Gebruik je al Akeneo, dan koppel je dat als bron.

Overweeg je een modulaire stack, begin dan bij de productfunctie: lees op het gratis plan je catalogus in (tot 100 producten) en zie welke velden elk ander onderdeel nodig heeft, nog voordat je één leverancier kiest. Wat een PIM precies doet, lees je in wat is PIM.