Composable eller monolitisk e-handelsplattform?

Composable commerce har blivit ett av de hetaste orden i e-handelssammanhang, ofta framställt som den självklara framtiden. Verkligheten är mer nyanserad. Att bygga sin e-handel av separata best-of-breed-komponenter i stället för en allt-i-ett-plattform ger verklig flexibilitet – men också en verklig kostnad i kompetens och komplexitet. Här är en nykter genomgång av vad composable kräver, när monoliten är det klokare valet och var gränsen går.

Vad composable faktiskt kräver

Idén bakom composable är tilltalande: välj det bästa verktyget för varje del av e-handeln – en specialiserad tjänst för produktkatalogen, en för kassan, en för sök, en för innehåll – och koppla ihop dem via API. I stället för att acceptera en plattforms kompromisser på varje område får ni spjutspets överallt.

Priset står i det där ordet “koppla ihop”. Någon måste integrera tjänsterna, se till att de pratar väl med varandra, underhålla kopplingarna när tjänsterna uppdateras och vidareutveckla helheten när behoven ändras. Det kräver rejäl utvecklarkapacitet, egen eller inhyrd, och en integrationsbudget som löper över tid – inte bara vid bygget. Ansvaret för att helheten fungerar, som en monolitleverantör annars bär, landar nu hos er.

Composable är därför inte i första hand ett teknikval utan ett organisationsval. Frågan är inte om best-of-breed låter bättre – det gör det nästan alltid – utan om ni har musklerna att äga den arkitekturen över år. En vanlig missräkning är att stirra sig blind på den tekniska elegansen och underskatta det löpande arbetet med att hålla ihop en väv av tjänster som var och en utvecklas i sin egen takt.

När monoliten är det rationella valet

För många organisationer är svaret att en monolit helt enkelt är klokare. En monolitisk e-handelsplattform levererar produktkatalog, kassa, betalning och innehåll i en sammanhållen helhet. Delarna är redan gjorda för att fungera ihop, vilket ger mindre integrationsarbete, snabbare lansering och lägre teknisk overhead i förvaltningen.

Det passar särskilt en mindre organisation med relativt standardiserade behov. Om ni säljer på ett sätt som plattformen redan stödjer väl, finns det liten anledning att bygga och underhålla en komplex arkitektur för en flexibilitet ni ändå inte kommer att utnyttja. Enkelheten är i sig ett värde: färre rörliga delar, färre leverantörer att hålla ihop, mindre som kan gå sönder.

Att välja monolit är alltså inte att välja “sämre teknik” – det är att välja rätt komplexitetsnivå för sin situation. För de flesta bolag under en viss storlek är det det rationella beslutet.

En besluts-checklista med trösklar

Eftersom valet i grunden handlar om organisationens kapacitet och behov snarare än om vilken arkitektur som är finast, är det bäst att fatta beslutet mot konkreta trösklar. Gå igenom följande innan ni väljer:

• Omsättning. Är volymen så stor att en optimering av enskilda delar ger märkbar avkastning? Composable börjar löna sig först en bit upp i skala.
• Teamstorlek och kompetens. Har ni utvecklare, egna eller inhyrda, som kan äga integrationerna löpande? Utan det blir composable en börda.
• Behovens särart. Är era behov genuint speciella, eller täcker en standardplattform dem väl? Ju mer standard, desto starkare monolit.
• Faktiskt utnyttjande. Kommer ni verkligen att använda flexibiliteten, eller lockas ni av idén? Betala inte för komplexitet ni inte omsätter i nytta.

Faller svaren mot stor skala, egen utvecklarkraft och särskilda behov är composable rätt. Faller de mot mindre organisation och standardbehov är monoliten det. En vanlig medelväg är att börja monolitiskt och bryta ut enskilda delar när både behovet och resurserna vuxit.

Så väljer ni

Composable och monolit är inte bättre eller sämre i sig – de passar olika lägen. Väg er skala, er utvecklarkapacitet och hur speciella behoven verkligen är, och var ärliga om ni kommer att utnyttja flexibiliteten. Våra tjänster hjälper er läsa av var ni står och undvika att köpa mer arkitektur än ni behöver. Hör av er med er volym och er teamsituation så ger vi en rak rekommendation.