Composable commerce är ett av de mest använda — och mest misshandlade — begreppen i e-handelsbranschen just nu. Det slängs in i säljpresentationer, analytikerrapporter och upphandlingsunderlag, ofta utan att någon i rummet skulle kunna förklara det för en kollega på ekonomiavdelningen. Det här är ett försök att göra just det: förklara composable commerce på vanlig svenska, utan buzzwords, och framför allt svara på frågan som faktiskt spelar roll — när är det värt något för din affär?
Vad composable commerce betyder — på en minut
Traditionella e-handelsplattformar är monoliter: en enda stor programvara som innehåller allt — produktkatalog, varukorg, kassa, kampanjer, innehåll, sök. Allt hänger ihop, allt uppgraderas tillsammans, och vill du byta ut en del får du ofta byta ut helheten.
Composable commerce är motsatt idé: e-handelslösningen sätts samman av separata delar som pratar med varandra via API:er. Produktinformationen kan bo i ett system, kassan i ett annat, söket i ett tredje och kundens gränssnitt — butiken du ser — byggas fristående ovanpå. Varje del kan bytas ut utan att resten rivs.
Det är hela idén. Resten är varianter på temat. Begrepp du stöter på i samma andetag:
- Headless — att skilja butikens gränssnitt (framsidan) från affärslogiken (baksidan). En delmängd av composable, inte en synonym. Vi har skrivit separat om när headless är värt det.
- API-first — att systemets funktioner är byggda för att nås av andra system, inte bara av det egna gränssnittet.
- Best-of-breed — att välja den bästa komponenten i varje kategori i stället för en leverantörs paket.
- MACH — en akronym (Microservices, API-first, Cloud-native, Headless) som beskriver samma arkitekturideal.
Vad problemet är som composable löser
Monoliternas svaghet visar sig med tiden. Butiken växer, kraven förändras, och plötsligt sitter du fast: söket är för svagt men går inte att byta, kampanjmotorn klarar inte B2B-priser, och varje uppgradering är ett projekt eftersom allt hänger ihop. Många Magento-handlare känner igen sig — stora versionslyft som i praktiken är ombyggnationer. Vår jämförelse med Magento går djupare i just det.
Composable löser detta genom utbytbarhet. Behöver du bättre sök byter du sökmotor, inte plattform. Vill du öppna en ny försäljningskanal — app, marknadsplats, butiksskärmar — hämtar den kanalen samma produktdata och priser via API, utan nybygge i botten. Affärsnyttan är alltså inte arkitekturen i sig. Den är förändringstakt: att kunna ändra en del av lösningen i morgon utan att riskera helheten.
Det är också därför begreppet fått fäste i just B2B. Företagshandel bär mer logik än konsumenthandel — avtalspriser, sortimentsstyrning, integrationer mot affärssystem — och i en monolit betyder varje sådan särlösning att du bygger in dig djupare i något du en dag måste lämna. I en composable arkitektur bor logiken där den hör hemma och nås därifrån av alla kanaler.
Det säljpresentationerna hoppar över
Här kommer den del av förklaringen som ofta saknas. Fullskalig composable — där du själv väljer och kopplar ihop varje komponent — flyttar ansvar från leverantören till dig:
- Integrationsansvaret. Tio best-of-breed-system betyder nio kopplingar som någon ska bygga, övervaka och förvalta. Det är ditt team eller din byrå.
- Felsökningen. När priset visas fel i kassan — är det PIM:et, prismotorn, API-lagret eller frontenden? I en monolit finns en leverantör att ringa. I en egenkomponerad lösning är du systemintegratören.
- Kostnaden. Flera licenser, flera avtal, mer utvecklartid. Composable i sin renaste form är byggt för organisationer med egna utvecklingsteam.
Slutsatsen är inte att composable är fel — det är att graden av composable måste matcha din organisation. Ett globalt varumärke med tjugo utvecklare kan äga hela kartan. En nordisk handlare med tre personer på e-handeln ska inte behöva bli sitt eget IT-bolag för att få en modern arkitektur.
Composable med förnuft: den nordiska medelvägen
Det finns en medelväg, och det är den vi själva valt med HDL Commerce: en composable plattform där kärnan — produktdata, priser, order, B2B- och B2C-logik i samma kärna, med inbyggd PIM — är sammanhållen och förvaltad av en leverantör, medan allt runt omkring är öppet och utbytbart via API:er och 200+ färdiga integrationer.
Du får utbytbarheten där den skapar värde: byt affärssystem, byt frontend, lägg till kanaler, koppla på nya tjänster. Men du slipper ta systemintegratörsrollen för kärnflödena, och du har en leverantör som ansvarar för drift — i vårt fall i Sverige, med 99,3 % upptid. Poängen är inte att vår modell är den enda rätta, utan att ”composable” inte är ett ja/nej-val. Det är en skala, och rätt läge på skalan avgörs av ditt team, din integrationskarta och din förändringstakt — inte av vad som låter modernast.
Tre frågor som avgör om composable är rätt för dig
Skala bort jargongen och beslutet kokar ner till tre frågor. Svara ärligt på dem — gärna skriftligt, tillsammans med den som äger budgeten — innan någon leverantör får visa arkitekturdiagram:
- Hur ofta behöver ni förändra? Om butiken i praktiken är stabil år efter år betalar ni för flexibilitet ni inte använder. Om ni ständigt bygger nytt — kanaler, marknader, tjänster — betalar sig utbytbarheten snabbt.
- Vem ska förvalta kopplingarna? Eget utvecklingsteam: fullskalig composable är möjlig. Litet team: välj en plattform där leverantören äger integrationerna.
- Var gör skräddarsytt verklig skillnad? Lägg flexibilitetsbudgeten där kunden märker den — ofta i frontend och kanaler — och köp beprövad standard i resten.
Vill du se hur det fungerar i praktiken?
Det enklaste sättet att förstå composable commerce är att se det köra, inte läsa mer om det. Boka en demo så visar vi hur kärna, PIM och integrationer hänger ihop i HDL Commerce — och funderar ni på att lämna en monolit gör vi en fri migreringsanalys av er nuvarande lösning. Kom igång här.
