Composable commerce loont, mits je de juiste aanpak en oplossingen kiest

Onderscheidende klantbelevingen, snelle ‘go-to-market’, toekomstbestendigheid en schaalbaarheid: de voordelen van een composable architectuur zijn groot. Er zijn dan ook bijzonder veel manieren om ermee te beginnen. Hoe bepaal je wat bij jou bedrijf past? En hoe vind je wat echt composable is?

Het uitgangspunt van composable commerce is het opdelen van de commerce-oplossing in meerdere kleinere oplossingen die ieder een stuk van de benodigde functionaliteit bieden, zoals bijvoorbeeld de commerce-transactie (prijs, voorraad, winkelwagen, check-out), contentmanagement en promoties. Wat voorheen een all-in one monoliet was met heel veel functies bij elkaar, is met de composable-aanpak een samengestelde oplossing opgebouwd uit losse SaaS-diensten die zijn verbonden via API’s.

De composable architectuur bestaat dus geheel uit cloudoplossingen. Die leveren snelle responstijden en een hoge stabiliteit, terwijl je zonder uitval of veel ontwikkeltijd makkelijk componenten kunt wisselen. Logisch dat Gartner stelt dat composable de toekomst is van commerce. Dat betekent ook dat het loont voor softwarebedrijven om zich als ‘composable’ te presenteren, zelfs als ze dat niet volledig zijn.

Composable gaat veel verder dan headless

Een grote misconceptie is het idee dat headless en composable commerce eigenlijk hetzelfde zijn. Bij headless opereren de front-end en de back-end onafhankelijk van elkaar, en zijn ze verbonden met een API. Het voordeel daarvan is dat je allerlei verschillende front-ends kunt toevoegen zodat je een naadloze klantervaring kunt aanbieden: echte omnichannel. Een ander headless-voordeel is dat je echt onderscheidend kunt zijn met je front-end en dat je niet afhankelijk bent van de standaard templates die monolithische softwareoplossingen veelal bieden. Ook biedt headless flexibiliteit: wordt Social Commerce bijvoorbeeld relevant voor jouw bedrijf, dan kan dit als nieuwe front-end worden toegevoegd zonder hiervoor het hele back-end-landschap te hoeven aanpassen.

Composable commerce gaat echter nog een stap verder. Ook de front-end zelf is modulair opgebouwd uit verschillende back-end SaaS-diensten, voor bijvoorbeeld de commerce-engine, contentmanagement en zoekfuncties. Voor elke functionaliteit kies je de beste aanbieder. Zo kun je snel een nieuwe betaaldienst toevoegen aan een app, een PIM-systeem vervangen in de back-end of hetzelfde commerceplatform hergebruiken voor meerdere merken.

Meer ‘buy’ en minder ‘make’

Bij composable kies je individuele blokken die allemaal het beste zijn voor dat ene stukje functionaliteit: de zogeheten best-of-breed-aanpak. Een commercepakket is nooit echt goed in contentmanagement zoals een contentmanagementsysteem ook niet de beste is in commerce, personalisatie of promoties. Door best-of-breed te kiezen krijg je een oplossing die in de breedte voldoet aan je verwachtingen. Ook kun je efficiënter innoveren: door specifieke Saas-diensten te integreren is er minder maatwerk nodig. Bovendien worden nieuwe features vrijwel altijd ontwikkeld door nieuwe partijen en niet door de traditionele legacy-partijen. Wil je je dus blijven onderscheiden dan moet het mogelijk zijn om makkelijk nieuwe bouwstenen te kunnen toevoegen.

De overstap van een monoliet naar een composable architectuur is echter uitdagend. Niet elke organisatie en technologie die zichzelf ‘composable’ noemt, biedt ook echt de flexibiliteit, modulariteit en schaalbaarheid die composable commerce behoeft. Je zult due diligence moeten toepassen bij het kiezen van je puzzelstukjes.

Composable-leveranciers valideren met acht vragen

De interesse uit de markt voor composable groeit sneller dan sommige leveranciers hun producten kunnen aanpassen. Aanbieders van full-suite-oplossingen die een API bieden kunnen te snel de stempel ‘composable’ toepassen, terwijl hun oplossing in de kern nog steeds monolithisch is. Een monolithische oplossing bestaande uit modules kun je bijvoorbeeld nog steeds modulair noemen, maar deze zijn niet inwisselbaar met SaaS-diensten van andere providers.

Om er zeker van te zijn dat een softwareleverancier ook echt ‘composable’ is, kun je het beste een proof of concept uitvoeren waarbij je een of twee belangrijke use cases implementeert en hun API’s gebruikt. Referenties met een vergelijkbare set-up zijn ook zeer relevant. Ook zijn er een aantal validatievragen waarmee je snel inzicht krijgt in een leverancier:

1. Hoe oud is het bedrijf? – De meeste leveranciers van echte composable zijn minder dan tien jaar oud en hebben hun software gebouwd op moderne MACH-ontwikkelingspraktijken. Dit geeft je al een eerste indicatie van hoe modern de software zal zijn.
2. Waar ligt de focus van het bedrijf? – Een commerce-leverancier die ook contentmanagement doet of een contentmanagementleverancier die ook commerce aanbiedt zijn beiden vaak niet composable. De meeste composable-leveranciers leggen de focus op één bepaald domein.
3. Waar is de API-documentatie online te bekijken? – Dit moet openbaar toegankelijk zijn voor ontwikkelaars. Is de beheerdersinterface bovenop ‘gedocumenteerde’ API’s gebouwd? Dit laat zien dat je echt met een API-first bedrijf te maken hebt wat de interface makkelijk uitbreidbaar maakt.
4. Is er een proefaccount beschikbaar? – De meeste SaaS-leveranciers bieden een proefaccount of sandbox om met de software en API’s te spelen voor evaluatiedoeleinden.
5. Hoe vaak wordt er nieuwe functionaliteit uitgebracht en hoe heeft dit invloed op implementaties? – De meeste composable-leveranciers gebruiken moderne ontwikkelingspraktijken. Zo brengen ze regelmatig updates uit zonder dat dit van invloed is op het bestaande gebruik van de API’s, zogeheten backwards compatibility.
6. Wat voor soort monitoring en rapportage wordt er aangeboden? – Je wilt in real-time weten hoe de API werkt en of er service-onderbrekingen of andere operationele problemen zijn.
7. Hoeveel integraties met andere composable-leveranciers zijn er beschikbaar? – Aangezien composable-leveranciers in een composable-landschap opereren, zijn kant-en-klare connectoren naar andere systemen cruciaal. Composable accelerators zijn ook interessant: deze bieden een vooraf samengestelde oplossing voor het snel neerzetten van veelgebruikte functionaliteiten.
8. Is de software te implementeren met elke programmeertaal? – De meeste composable-leveranciers hebben SDK’s beschikbaar voor de verschillende programmeertalen en bieden de mogelijkheid om nieuwe SDK’s bovenop hun API’s te ontwikkelen.

Denk niet alleen vanuit technologie

Er zijn drie belangrijke pijlers om composable succesvol te maken. De eerste is technologie, maar deze pilaar functioneert niet alleen en is ook zeker geen op zichzelf staand doel. De tweede pilaar is leiderschap. Je organisatie moet de flexibiliteit van het management krijgen om te kunnen innoveren, te experimenteren en de grenzen te verleggen. Je moet het ook accepteren als iets niet werkt: fail fast. Dit denken moet van bovenaf in de hele organisatie worden ingeprent. De laatste pilaar is het bedrijfsmodel. Er is nauwkeurige afstemming tussen business en IT nodig. In de vorm van cross-functionele teams en agile samenwerken, moderne ontwikkelprocessen en snelle release cycles.

Composable loont, mits juist toegepast

Wil je composable commerce succesvol in de praktijk brengen? Houd dan rekening met deze eindconclusies en aanbevelingen:

• Composable heeft de toekomst: gebruik het als middel om snel businesswaarde te creëren;
• Wees kritisch bij het selecteren van leveranciers, want iedereen noemt zich ‘composable’. Maak de juiste keuzes om de kans op langetermijnsucces te vergroten;
• Composable vraagt om puzzelwerk. Het is een combinatie van goed leiderschap, processen en techniek.

Over de auteur: Gijs Edelbroek is Solutions director bij Lab Digital.

Op de hoogte blijven van het laatste nieuws binnen je vakgebied? Volg Emerce dan ook op sociale media: LinkedIn, Twitter en Facebook.