Composable commerce, ärligt förklarat

Vad composable commerce faktiskt är

Composable commerce är en arkitekturapproach för e-handel där varje förmåga — commerce-motor, sökning, CMS, betalning, PIM, CRM, OMS — kommer från en separat specialistleverantör och ansluter till resten av stacken via API:er. Handlaren sätter samman dessa tjänster till ett fungerande e-handelssystem istället för att köpa en enda monolitisk plattform som gör allt.

Termen popularierades av Gartner 2020. Varje förmåga i en composable-stack är vad Gartner kallar en Packaged Business Capability, eller PBC. Arkitekturen är API-first per definition. Varje tjänst exponerar sin funktionalitet via endpoints som andra tjänster kan konsumera.

I praktiken är composable commerce mer en filosofi än en fast arkitektur. Det finns inget certifierande organ som bestämmer om en given stack är composable. De flesta projekt ligger någonstans på ett spektrum mellan monolitiskt och fullt composable.

För en sida-vid-sida-beslutsram som täcker monolitisk, headless och composable i en vy, se composable vs headless vs monolitisk. Det här inlägget fokuserar specifikt på composable-modellen i sig.

Composable vs MACH

MACH är akronymen som oftast förväxlas med composable. Den står för Microservices, API-first, Cloud-native och Headless, och formaliserades av MACH-alliansen 2020 som en uppsättning arkitekturprinciper.

En MACH-kompatibel stack är composable per definition. Det omvända är inte sant. En stack kan vara composable utan att uppfylla varje MACH-kriterium. Till exempel kan en composable-stack innehålla en tjänst som inte är strikt en microservice, eller en leverantör som inte kör cloud-native infrastruktur. MACH är en strikt delmängd av composable. Composable är den bredare kategorin.

För de flesta projekt spelar skillnaden ingen roll. Leverantörsmarknadsföring använder termerna utbytbart. Skillnaden spelar roll när ett enterpriseinköpsteam specifikt kräver MACH-kompatibla leverantörer, eller när en leverantör använder "composable" löst för att beskriva en stack som egentligen bara är headless med extra delar.

Packaged Business Capabilities (PBC)

En PBC är kompositionsenheten i en composable-stack. Det är en självständig tjänst som levererar en affärsförmåga via ett API. En composable-stack sätter samman en PBC per förmåga. De vanliga kategorierna:

• Commerce-motor: Norce, commercetools, Shopware, BigCommerce, Shopifys Storefront API, Salesforce Commerce Cloud
• Sökning och produktupptackt: Algolia, Elastic, Hello Retail, Meilisearch, Coveo, Bloomreach Discovery
• Headless CMS: Storyblok, Contentful, Sanity, Strapi, Hygraph, Amplience
• Product Information Management (PIM): Akeneo, Plytix, Salsify, Pimcore
• Betalning: Klarna, Stripe, Walley, Adyen, Vipps, MobilePay
• Checkout-orkestrering: Kustom, Ingrid, Walley Checkout
• Customer Data Platform (CDP) och CRM: Voyado, Klaviyo, Bloomreach Engagement, Tealium, Segment
• Recensioner och UGC: Lipscore, Trustpilot, Yotpo, Bazaarvoice
• Order management (OMS): fluent commerce, Manhattan Active Omni, nShift
• Personalisering och rekommendationer: Bloomreach, Dynamic Yield, Algolia Recommend

En verklig composable-stack väljer en PBC per förmåga och integrerar dem. Integrationslagret — typiskt en backend-for-frontend (BFF) — är där dessa tjänster möts för att mata storefronten.

Inte varje PBC behöver vara specialist från dag ett. En Norce-baserad stack använder Norces inbyggda katalog och produktinformation som standard. Att lägga till Akeneo som dedikerat PIM är ett senare beslut, fattat när katalogkomplexiteten växer ur vad Norce hanterar nativt. PBC-listan är en meny, inte en checklista.

När composable commerce är rätt val

Composable är rätt arkitektur när:

• Best-of-breed faktiskt spelar roll för verksamheten. Sökkvalitet är en primär kommersiell konkurrensfördel. PIM:et är en strategisk tillgång. CRM:et driver meningsfull omsättning. Om de här lagren är genuint strategiska är det värt att betala för specialistleverantörer.
• Flera kanaler delar samma produktkatalog. Webb, mobilapp, butikskiosk, kundtjänstverktyg och marknadsplatsintegrationer läser alla från samma commerce-API:er. Composable-arkitektur gör det mönstret rättframt.
• Teamet kan bära den operativa komplexiteten. Antingen finns plattformsingenjörskapacitet internt, eller så finns en leveranspartner som äger integrationslagret efter lansering.
• Leverantörskoncentration är en verklig oro. Stora företag och reglerade branscher behöver ofta kunna byta vilken leverantör som helst utan att bygga om. Composable gör det möjligt.

När composable commerce är fel val

Det här är avsnittet de flesta leverantörssidor hoppar över. Composable är fel val när:

• Katalogen är standard och sökkraven är enkla. En monolitisk plattforms inbyggda sökning kommer att vara tillräcklig. Att betala för Algolia eller Hello Retail ovanpå lägger till kostnad utan att tillföra värde.
• Teamet är litet. Composable kräver mer leverantörshantering, mer integrationsunderhåll och mer ingenjörstillsyn än monolitisk. Ett team på tre kan inte driva en tio-leverantörs-stack effektivt.
• Time-to-market dominerar. En Shopify-butik med ett bra tema kan lanseras på veckor. En composable-stack med flera nya leverantörer tar månader. Om handlaren behöver skeppa nu är composable fel startpunkt.
• Den nuvarande plattformen fungerar. Att replatforma från en fungerande monolitisk plattform till composable enbart av arkitekturskäl betalar sig sällan. Migreringskostnaden är hög och förbättringen för kunden är ofta osynlig.

Composable-adoption drivs ofta av arkitekturmodet snarare än av affärsbehov. Leverantörspåståenden om 80 procent snabbare feature-leverans eller 30 procent snabbare time-to-market är verkliga för vissa projekt och irrelevanta för andra. Frågan att ställa är vilken specifik förmåga som blockeras av den nuvarande arkitekturen, inte om composable generellt sett är bättre.

Var de flesta projekt faktiskt landar

De flesta produktionsprojekt som beskrivs som composable är inte fullt composable. De är commerce-stackar med två eller tre composable-mönster-PBC:er ovanpå en i övrigt integrerad plattform. Det vanligaste mönstret:

• En commerce-backend (Norce, Shopware, commercetools) som äger produkter, priser, varukorg, checkout och ordrar.
• Ett dedikerat headless CMS (Storyblok, Contentful) som ersätter plattformens inbyggda innehållsverktyg.
• En specialistleverantör för sökning (Algolia, Hello Retail) som ersätter plattformens inbyggda sökning.
• En modern headless frontend byggd på Vue, Nuxt, React eller Next.js.
• Allt annat — PIM, OMS, CRM, betalning — fortsätter att förlita sig på commerce-plattformens standard eller första parts integration.

Det mönstret levererar det mesta av composable-nyttan (specialist-sökning, specialist-CMS, flexibel storefront) utan hela overheaden av att driva en fullt composable-stack. Att lägga till fler PBC:er över tid är rättframt när en av dem blir en verklig flaskhals.

Hur Frntkey passar in i en composable-stack

Frntkey är en frontend-as-a-service för storefront-lagret i en composable- eller headless-stack. Den ansluter till Norce eller Shopware som commerce-backend. Den levereras med Storyblok inbyggt som CMS. Den kopplas in mot Meilisearch eller Hello Retail för sökning, Klarna eller Walley för betalning, Voyado för CRM, Lipscore för recensioner — var och en en distinkt PBC.

Arkitekturen är composable-redo, inte fullt composable från dag ett. De flesta projekt lanseras med den inbyggda stacken och lägger till ytterligare PBC:er över tid när specifika förmågor motiverar integrationskostnaden. Den inkrementella vägen är det vanligaste produktionsmönstret bland de handlare Frntkey servar.

För projekt som behöver fullt composable från lansering — enterprise PIM, separat OMS, specialist-CDP, anpassad checkout-orkestrering — stödjer Frntkey-storefronten det också. Begränsningen är leveransscope, inte arkitektur.