Composable Commerce nel B2B: Quando Ha Senso e Quando No

Il composable commerce è splendido sulla lavagna. Scegli lo strumento migliore per ogni compito. Li colleghi tra loro. Sostituisci i pezzi quando arriva qualcosa di meglio. Lo capisco. Un concetto elegante.

Ma se sei un team B2B che gestisce SAP Commerce Cloud, la lavagna non paga le bollette. La vera domanda è se i compromessi funzionano davvero per la tua situazione. Il mercato globale dell’e-commerce B2B vale 32,1 trilioni di dollari, con una crescita del 14,5% CAGR (Statista, 2025). Quindi la scelta di architettura conta. Ma “composable per tutti” è la risposta sbagliata.

TL;DR: Il 76% delle organizzazioni prevede di adottare il composable commerce entro due anni (MACH Alliance, 2024). Ma il composable non è il default per ogni scenario B2B. Funziona quando hai alte ambizioni di UX, storefront multipli o rilasci modifiche al frontend di continuo. È sbagliato per team piccoli, timeline strette o semplici portali ordini. La nostra posizione: parti con SAP Commerce Cloud + Composable Storefront, poi passa al composable in modo incrementale.

Cosa Significa Davvero “Composable” nel Contesto SAP?

SAP è Leader nel Gartner Magic Quadrant for Digital Commerce da 11 anni consecutivi (SAP News Center, 2025). In termini di SAP Commerce Cloud, il composable si riduce a tre layer disaccoppiati:

Il commerce engine (SAP Commerce Cloud) gestisce contenuto di prodotto, prezzi, gestione degli ordini e stock. Davanti c’è uno storefront disaccoppiato: Composable Storefront (quello che una volta era Spartacus), un’app React/Vue.js personalizzata o un DXP come Contentful. Poi un experience layer gestisce personalizzazione, A/B testing e content management tramite strumenti dedicati.

Ciò che rende possibile tutto questo è il layer API OCC (Omnichannel Commerce) di SAP Commerce Cloud. Ogni funzionalità commerce esposta come API REST. Senza quel layer resti vincolato allo stack frontend di SAP e il composable rimane una bella idea su una slide.

Quando Ha Senso il Composable nel B2B?

A questo punto abbiamo condotto assessment di architettura su un buon numero di progetti commerce B2B. Il composable funziona in tre situazioni. Se nessuna ti descrive, la complessità extra probabilmente non vale la pena.

Vuoi una vera esperienza di brand, non un catalogo. Se il tuo storefront deve essere un autentico touchpoint di brand, il composable dà ai tuoi team di design e frontend la libertà di costruire esattamente ciò che vogliono. Senza combattere con la piattaforma. L’80% delle vendite B2B sarà generato digitalmente entro fine 2025 (Shopify, 2025). Le aspettative dei buyer B2B stanno convergendo rapidamente con il B2C. Il tuo storefront non può più sembrare un foglio di calcolo.

Gestisci più storefront. B2B e B2C? Più brand o mercati? Disaccoppiare il frontend permette a ogni esperienza di evolvere in modo indipendente da un commerce core condiviso. Un’unica istanza di Commerce Cloud, frontend completamente diversi. È qui che il composable si guadagna davvero il suo posto.

Rilasci modifiche al frontend di continuo. Quando il business ha bisogno di aggiornamenti più volte a settimana, separare lo storefront dal commerce engine disaccoppia i cicli di rilascio. Gli aggiornamenti di backend seguono il proprio calendario. Il frontend viene deployato quando vuoi. Nessuno aspetta nessuno.

Quando il Composable è la Scelta Sbagliata?

Il tuo team non ha persone frontend dedicate. Il composable richiede sviluppatori React, Angular o Vue in grado di costruire e mantenere una vera applicazione JavaScript. Se il tuo team è composto per lo più da persone SAP e backend, passerai più tempo a gestire lo stack frontend che a costruire funzionalità commerce.

Hai fretta. Il composable richiede più tempo per la prima delivery. Hai una scadenza a 6 mesi? Un approccio basato su accelerator con Composable Storefront ti ci porterà più in fretta. L’overhead di setup del composable (scelta dei componenti, collegamento, costruzione delle pipeline di deployment) aggiunge da 4 a 8 settimane rispetto a una partenza integrata. È tempo vero.

Il tuo caso d’uso è semplice. Se stai costruendo un portale ordini B2B funzionale con funzionalità standard, non un’esperienza di brand flagship, la flessibilità del composable non giustifica la complessità. Che senso ha un frontend React su misura per un portale di riordino? Composable Storefront lo gestisce out of the box.

Qual è la Via di Mezzo Pragmatica?

Per la maggior parte dei progetti SAP Commerce Cloud B2B che vediamo, vince la via di mezzo. Il 90% delle aziende che hanno migrato la piattaforma e-commerce ha riportato miglioramenti di fatturato (commercetools, 2024). Ma la scelta di architettura conta meno del fare bene i fondamentali.

Ecco cosa raccomandiamo davvero nella maggior parte dei casi. Usa SAP Commerce Cloud come commerce engine. Usa Composable Storefront come acceleratore frontend, personalizzato secondo necessità. Aggiungi Emarsys o un DXP per personalizzazione e content management. Poi passa al composable in modo incrementale, man mano che crescono le capacità del team e la complessità del business.

Parti integrato. Evolvi verso il composable. Non è un compromesso. È l’approccio che genera valore più in fretta mantenendo l’opzione di scomporre in seguito. Il layer API OCC significa che puoi sostituire il frontend in qualsiasi momento senza toccare il commerce engine. Prima vista sembra rimandare il problema, ma non è così. È pragmatismo.

Per i dettagli su come implementiamo SAP Commerce Cloud, incluse la delivery del Composable Storefront, gli scenari B2B e l’architettura di integrazione, visita la nostra pagina della soluzione SAP Commerce Cloud.

Come Dovresti Decidere?

Cinque domande. Sii onesto con te stesso.

1. Il tuo team ha 2 o più sviluppatori frontend dedicati? Se no, parti integrato.
2. Hai bisogno di più storefront distinti? Se sì, il composable ha argomenti solidi.
3. La tua scadenza di go-live è sotto i 6 mesi? Se sì, parti integrato.
4. Lo storefront è un elemento distintivo del brand o uno strumento funzionale? Distintivo del brand: composable. Strumento funzionale: integrato.
5. Puoi investire nella manutenzione a lungo termine di un frontend custom? Il composable non è una costruzione una tantum. È un impegno continuativo.

Sia chiaro, il fully composable è genuinamente la risposta giusta per alcune aziende. Ma non è il default. L’architettura giusta è quella che si adatta al tuo team, alla tua timeline e al tuo modello di business.

Vuoi capire quale approccio si adatta alla tua situazione? Conduciamo assessment di architettura che valutano team, timeline e requisiti, e poi raccomandiamo l’approccio che genera valore più in fretta. Parla con i nostri architetti commerce.

Domande Frequenti

Qual è la differenza tra composable e headless commerce?

Headless significa separare il frontend dal backend tramite API. È una scelta architetturale. Il composable va oltre: scegli componenti best-of-breed per ogni funzionalità commerce (ricerca, PIM, OMS, pagamenti) e li colleghi tra loro. Tutte le architetture composable sono headless, ma non tutte le implementazioni headless sono composable. SAP Commerce Cloud supporta entrambe tramite il suo layer API OCC.

Possiamo partire con Composable Storefront e passare al fully composable in seguito?

Sì. Ed è esattamente ciò che raccomandiamo per la maggior parte dei progetti B2B. Composable Storefront è costruito su Angular e consuma le API OCC di Commerce Cloud. Poiché tutto passa dalle API, puoi sostituire il frontend con un’app React o Next.js custom in seguito senza toccare il commerce engine. Il tuo investimento in configurazione di Commerce Cloud, modelli dati e integrazioni si conserva integralmente. È tutto il punto.

Quanti sviluppatori richiede un’architettura composable?

Uno stack composable richiede tipicamente da 2 a 3 sviluppatori frontend dedicati più 1 o 2 sviluppatori backend Commerce Cloud per la manutenzione continua. Confrontalo con un approccio Composable Storefront integrato, che può funzionare con 1 o 2 sviluppatori full-stack. Serve anche capacità DevOps per gestire pipeline di deployment multiple, configurazioni CI/CD e dipendenze tra servizi. Si somma in fretta.

Il composable commerce costa più dell’integrato?

Inizialmente sì. L’overhead di setup aggiunge da 4 a 8 settimane e tipicamente dal 20 al 30% al costo iniziale del progetto. Ma su un orizzonte di 3-5 anni il composable può costare meno, se la flessibilità ti serve davvero. Sostituire singoli componenti costa meno che rifare il replatforming di un intero stack integrato. Il break-even dipende da quanto spesso devi far evolvere il frontend e da quanti storefront gestisci.

SAP supporta l’architettura composable su Commerce Cloud?

SAP supporta attivamente gli approcci composable tramite il layer API OCC di Commerce Cloud e il framework Composable Storefront. La sua stessa guidance architetturale posiziona Commerce Cloud come “composable commerce engine” in grado di servire più esperienze frontend. La copertura API della piattaforma è solida per la maggior parte degli scenari B2B, anche se alcuni casi limite possono richiedere estensioni API custom via SAP BTP.