Er is een beweging gaande op het gebied van eCommerce. Iets wat wij bij Product League de "weg naar composable" noemen. Terwijl je je digitale bedrijf runt, bouwt en schaalt, wist je misschien niet eens dat je op deze weg zat. Je denkt misschien dat alle problemen die zich voordoen bij elke nieuwe eCommerce-kans alleen de jouwe zijn. Wees gerust - we lopen deze weg samen.
Het onderwerp van vadaag: Composable Freedom…
Dit is het derde en laatste deel van onze blogreeks waarin we de verschillende fasen op de weg naar composable ontdekken. In het vorige artikel keken we naar de mogelijkheid om headless te gaan, de redenen om dit te overwegen en de waarde die het kan opleveren. Samengevat: door je frontend los te koppelen van de backend, stem je je systemen beter af op het tempo van verandering. Waardevol op zichzelf, en bovendien de eerste stap naar echte composability.
Lees de eerdere artikelen in onze reeks:
Op weg naar composable – De monoliet
Op weg naar composable – Headless worden
Composable
Tijdens je overstap naar headless, of misschien zelfs al daarvoor, begin je te experimenteren met de eerste microservices. Denk aan een speciale on-site zoekmachine of een modern contentmanagementsysteem dat van nature headless is. Je zet nu echt de stap richting composable: een landschap dat niet langer wordt beperkt door de vraag “wat past er nog binnen het monolithische platform?”, maar juist wordt bepaald door de vraag “wat past het beste bij mij?”.
In een composable landschap blijft je op maat gemaakte gebruikerservaring losgekoppeld van de backend (headless). Maar in plaats van dat de backend één grote, nog steeds vrij monolithische e-commerce-engine is, ga je denken in microservices. Welk systeem, proces of welke service past het beste bij de behoeften van mijn bedrijf? Investeren in een speciale prijs- en promotie-engine wordt logisch als je bedrijf sterk afhankelijk is van prijs- en promotielogica om klanten op elk moment de beste deals te bieden. Een app die op spannende manieren gebruikmaakt van backend-klantdata om voordelen te tonen, kan jouw bedrijf onderscheiden als je een op maat gemaakt, gelaagd loyaliteitsprogramma hebt.
De revolutie begint wanneer je jouw technologie niet langer ziet als één groot backendsysteem, maar als een veelzijdig landschap van headless microservices, die specifiek zijn ontworpen om te voldoen aan de doelen die ze moeten vervullen.
In de afgelopen jaren is er een beweging ontstaan, geïnitieerd door enkele leveranciers van dit soort applicaties, genaamd de MACH Alliance. MACH staat voor:
- M icroservices
- A PI-gedreven
- C loud-native
- H eadless
Deze bedrijven realiseerden zich dat hun producten zeer goed waren in het oplossen van een specifieke subset van problemen. Ze wilden niet uitbreiden en hun oplossingen verwateren totdat de producten ook one-size-fits-all-platformen zouden worden. In plaats daarvan kozen ze ervoor om zich te richten op het worden van best-in-class binnen hun niche.
Ze besloten samen te werken met andere bedrijven die relevante problemen oplosten en zich te richten op de principes van de MACH-architectuur om de beste wederzijdse integraties te garanderen. Op deze manier kan elk (eCommerce-)probleem worden opgelost, simpelweg door de juiste puzzelstukjes aan elkaar te koppelen. MACH-landschappen bestaan niet langer uit grote monolithische platforms, maar uit meerdere gespecialiseerde services van SaaS-leveranciers die naadloos met elkaar samenwerken.
Een voorbeeld van MACH – het ontkoppelen van een CMS
Een klassiek voorbeeld van de MACH-mentaliteitsverandering is een dedicated contentmanagementsysteem (CMS). Een ouder CMS was verantwoordelijk voor zowel de creatie van content als de weergave ervan op de site. Vaak is dit type CMS nog steeds onderdeel van een monolithische eCommerce-applicatie. Het CMS pusht de content naar buiten en genereert de site volgens de ingestelde regels. Dit zorgt vaak voor conflicten tussen de HTML binnen het CMS en de rest van de site. Bovendien is het moeilijk op te schalen, omdat je voor elke component precies moet beschrijven hoe deze zich moet gedragen, terwijl je rekening houdt met de rest van het monolithische platform.
Daarentegen houdt een headless CMS zich niet bezig met de weergave van content, maar alleen met de content zelf. Voor elk gedeelte van een pagina vraagt de ontkoppelde frontend aan het CMS: "Heb je content voor me?" En het CMS antwoordt met de beschikbare data. De frontend bepaalt vervolgens zelf hoe deze content visueel wordt weergegeven.
Dit “pull”-model is niet alleen veel sneller dan het oude “push”-model, maar biedt ook veel meer mogelijkheden. Wil je een banner op de homepage op een bepaalde manier tonen en op de zoekresultaten op een andere manier? Geen probleem, je kunt dezelfde content gebruiken maar anders stylen. Beter nog, als je die content later ook wilt gebruiken voor een display in de winkel, dan ben je vrij om dat te doen. En dan hebben we het nog niet eens over alle personalisatiemogelijkheden waarmee je klanten relevante, op maat gemaakte content kunt bieden.
Dit is de MACH-manier van werken: je communiceert alleen met deze systemen via API's. Stel je de opluchting voor binnen je teams: de content editors kunnen nu hun content creëren zonder zich zorgen te maken over het insluiten van HTML. Ze kennen de regels voor het eindproduct en kunnen “fire and forget”. De frontend-ontwikkelteams hoeven zich ook geen zorgen meer te maken, omdat hun zorgvuldig ontworpen pagina's niet langer kunnen worden verpest door een onzorgvuldige of onjuiste contentupdate. Zij behouden volledige controle over de weergave.
Een nieuwe alles-in-één oplossing?
Overstappen van een monolithische en/of headless eCommerce-engine naar een composable eCommerce-landschap brengt zeker veel voordelen met zich mee. Automatische schaalbaarheid, zodat je nooit meer verrast wordt door pieken zoals op Black Friday. Hoge prestaties, omdat elke tool alleen doet waarvoor het is bedoeld. En een sterk verbeterde time-to-market: Gartner voorspelde dat organisaties die een composable aanpak hanteren in 2023 de concurrentie met 80% zouden overtreffen in de snelheid van nieuwe feature-implementaties.
In plaats van één grote beslissing om de vijf jaar (gaan we door met onze monoliet, upgraden we deze, of doen we iets anders?), maak je nu veel kleine beslissingen (is deze tool nog steeds de beste oplossing voor dit specifieke probleem?). Dit betekent dat de Total Cost of Ownership (TCO) innovatie niet langer in de weg staat. Het is veel eenvoudiger en goedkoper om één enkele microservice te vervangen dan om je hele eCommerce-landschap te veranderen!
Toch zijn er zeker uitdagingen op de weg naar composable. Zo wordt je leverancierslandschap complexer. Het beheren van al deze contracten en leveranciers kan behoorlijk lastig zijn. Ook belangrijk: is jouw organisatie in staat om zo'n digitale transformatie te orkestreren? Dit vereist strikte naleving van architectuurprincipes, een veel hogere eis aan teams om silo’s te doorbreken en een geheel nieuwe organisatorische mindset. En laten we niet vergeten dat de technische vaardigheden om dit nieuwe landschap te bouwen en te beheren, met de nieuwe databehoeften, API-orkestratie en aangepaste frontend-flows, niet te onderschatten zijn.
Er zijn twee benaderingen om deze complexiteit aan te pakken:
- Je probeert je uit dit probleem te kopen door zoveel mogelijk SaaS-oplossingen aan te schaffen, met implementatiepartners voor al deze oplossingen. Het probleem hierbij is dat dit nog steeds veel coördinatie vereist tussen al deze verschillende partners. Bovendien bieden de SaaS-oplossingen, vooral aan de frontend-kant, veel functies out-of-the-box, maar zijn ze beperkt in maatwerkopties en is de code vaak moeilijk herbruikbaar.
- Je probeert je uit dit probleem te bouwen door veel teams van engineers in te zetten die op maat gemaakte oplossingen bouwen met high code. Hoewel dit zeker de meest flexibele en best presterende applicaties oplevert, vereist het dat een organisatie een IT-bedrijf wordt, wat voor veel retailers een verre toekomstdroom is. Bovendien kan deze route de duurste worden als je probeert alle oplossingen zelf te bouwen die andere bedrijven al voor je hebben uitgewerkt.
Bouw betere ervaringen met composable commerce + low code
In de praktijk kiezen de meeste organisaties voor een combinatie van beide strategieën: ze kopen oplossingen voor “opgeloste” problemen (zoals commercetools voor de eCommerce-engine of Contentful als CMS) en investeren in maatwerkoplossingen waar de meeste waarde te behalen valt. Dit maatwerk wordt ofwel intern ontwikkeld, of in samenwerking met externe ontwikkelingspartners.
We zien dat de meeste groei in de eCommerce-oplossingsmarkt zich bevindt tussen deze Buy- en Build-tactieken. Aan de Buy-kant worden SaaS-oplossingen steeds flexibeler en meer gericht op composable architecturen. Dit geldt voor veel moderne, headless SaaS-oplossingen, maar ook voor de oudere monolieten die naar de cloud verhuizen om de aansluiting met jongere concurrenten te behouden (hoewel alleen de tijd zal leren of dit levensvatbare oplossingen zijn of slechts een vorm van “cloud washing”). Een groot nadeel van deze SaaS-oplossingen blijft echter hun gebrek aan flexibiliteit. Wat als je een maatwerkfrontend nodig hebt voor een specifieke zakelijke use case? Of een orkestratieservice voor gegevens tussen een paar systemen die niet vaak worden gebruikt, maar wel cruciaal zijn voor je digitale ervaringen? Deze use cases komen vaak voor in een eCommerce-landschap, maar zonder te investeren in maatwerkontwikkeling verdwijnen ze langzaam naar de onderkant van je backlog.
Aan de Build-kant zien we een opkomst van low-codeplatformen. Low code richt zich op het toegankelijker maken van maatwerkontwikkeling door de kosten te verlagen. Ofwel je hebt minder ontwikkelaars nodig voor hetzelfde resultaat, of dezelfde hoeveelheid ontwikkelaars levert meer op. Sommige eCommerce-frontend SaaS-oplossingen, zoals commercetools frontend, bewegen zich in deze richting en stellen citizen developers in staat om zelf oplossingen te bouwen. Zelfs Salesforce biedt een zeer beperkte low-code drag-and-drop eCommerce-starterkit. Er zijn ook pure low-codeplatformen die deze markt betreden.
Bij Product League kiezen we voor het high-performance low-code platform OutSystems om onze eCommerce-oplossingen te ontwikkelen. We kozen voor OutSystems omdat het herbruikbaarheid omarmt. Zo kun je iets één keer bouwen en het zowel als een reactieve website als een hybride app publiceren. Je kunt integratiemodules maken die het sneller integreren van systemen mogelijk maken, wat steeds belangrijker wordt naarmate je landschap verschuift naar composable. Bovendien kun je snel meerdere frontends bouwen voor specifieke back-end gebruikers. Omdat eCommerce centraal staat in je bedrijfsproces, hebben veel gebruikers toegang nodig tot eCommerce-systemen met specifieke functionaliteiten die niet gemakkelijk kunnen worden bediend met één generiek “backend portal”. Met OutSystems kunnen we zowel klantgerichte frontends als specifieke frontends bouwen op dezelfde backend, speciaal voor de medewerkers die eCommerce beheren.
Het nadeel van de Build-aanpak blijft het gebrek aan herbruikbare oplossingen. Je wilt immers niet steeds opnieuw het wiel uitvinden. Helaas besteed je de eerste maanden vaak aan het opnieuw bouwen van wat SaaS-oplossingen al eerder hebben gedaan, om daarna pas te kunnen beginnen met het echte maatwerk. Hier komt het spannende concept van Accelerators in beeld. Een accelerator is bedoeld om je maatwerkontwikkeling te versnellen met out-of-the-box componenten. Hiermee kun je voortbouwen op eerder werk, zodat een project bij aanvang al voor 60% staat, in plaats van op 0 te beginnen. Bij Product League hebben we voor deze aanpak gekozen, omdat dit naadloos aansluit bij de low-code mindset: herbruikbaarheid centraal stellen bij het ontwerpen en bouwen van elke component. Door herbruikbaarheid en accelerator-gestuurde ontwikkeling in gedachten te houden, denk je al vroeg na over waar je moet kopen en waar je moet bouwen. Hierdoor kun je “opgeloste” oplossingen in je architectuur integreren en je ontwikkelinspanningen richten op de use cases die echt onderscheidend zijn.
Een reis, geen bestemming
Waar staat jouw bedrijf op de weg naar composable? We hebben in onze 3-delige blogserie vele pieken, dalen en hobbels doorgemaakt. Hier is een lijst van de vragen die we onszelf gedurende deze serie hebben gesteld:
- Voldoet mijn eCommerce-technologie aan de vraag van de klant, zonder schaalproblemen?
- Houdt mijn technologie-stack me tegen?
- Welke zakelijke problemen maken mijn bedrijf uniek?
- Welke unieke waarde bied ik klanten?
- Probeeer ik nieuwe problemen op te lossen of kom ik bestaande problemen tegen?
Terwijl je deze vragen zelf beantwoordt, hopen we dat je deze serie verlaat met een gevoel van richting en doel, om de principes van composable toe te passen waar ze zinvol zijn en ze te negeren waar ze (nog) geen goede oplossing bieden.
Het creëren van een nieuwe eCommerce-erfenis:
Onze serie 'Road to Composable' mag dan ten einde zijn, maar jouw avontuur naar eCommerce-uitmuntendheid staat misschien pas aan het begin. Het is tijd om inzichten om te zetten in actie en theorieën in tastbare resultaten, en samenwerken met Product League zal je helpen de opwindende wereld van composable eCommerce te verkennen. Pas je niet alleen aan aan verandering – wees de voorloper van verandering. Neem nu contact op, en samen creëren we een nieuwe erfenis in eCommerce door systemen te bouwen die net zo uniek en dynamisch zijn als jouw bedrijfsvisie!