Composable commerce: cos'è e quando conviene nel B2B

Il composable commerce è un’architettura in cui le funzioni del commercio elettronico, come catalogo, prezzi, checkout, ricerca e CMS, sono componenti separati, collegati tramite API e sostituibili uno alla volta, invece di far parte di un’unica suite monolitica. Spesso segue i principi MACH: microservizi, API-first, cloud-native e headless. Con SAP Commerce Cloud significa in pratica tenere integrato il nucleo commerce (carrello, prezzi, promozioni, ordini) e collegarvi tramite le API OCC un frontend disaccoppiato e servizi specializzati come ricerca, CMS o pagamenti.

Sulla lavagna il composable commerce convince: per ogni compito lo strumento migliore, collegato tramite API, sostituibile appena arriva qualcosa di meglio. Per un team B2B su SAP Commerce Cloud la domanda utile è più circoscritta. Quali parti del vostro shop traggono vantaggio dall’essere indipendenti, e il vostro team è in grado di gestire le parti mobili in più?

Questa guida risponde proprio a questo. Distingue headless da composable, mostra come SAP Commerce Cloud supporta entrambi e si chiude con le domande decisionali che usiamo nelle valutazioni architetturali. I principi tecnici dietro i termini sono spiegati nel nostro articolo sull’architettura MACH in SAP Commerce Cloud.

In sintesi: headless separa lo storefront dal motore commerce; composable sostituisce inoltre singole funzioni come ricerca, CMS o pagamenti con servizi specializzati. Su SAP Commerce Cloud entrambi passano per le API OCC. Il composable conviene con ambizioni elevate sulla UX, più storefront o rilasci frontend frequenti. È la scelta sbagliata per team piccoli, scadenze strette o un semplice portale di riordino. La nostra impostazione predefinita: SAP Commerce Cloud come nucleo, Composable Storefront o un frontend personalizzato, servizi specializzati aggiunti uno alla volta.

Headless, composable, MACH: tre concetti diversi

I termini vengono spesso usati come sinonimi. Rispondono però a domande diverse.

Headless risponde a: come comunica il mio storefront con il motore commerce? Solo tramite API. Il backend non genera pagine, il frontend non accede al database. Così potete costruire lo storefront con qualsiasi framework, rilasciare frontend e backend in modo indipendente e servire web, app e chioschi dallo stesso backend. Significa però anche che servono sviluppatori frontend, un livello API con autenticazione e versionamento, e una pipeline e un monitoraggio propri per il frontend.

Composable risponde a: come compongo l’intero stack? Invece di una suite che fa tutto, scegliete servizi specializzati per ricerca, contenuti, pagamenti o personalizzazione e li collegate tramite API. Ognuno può essere sostituito senza ricostruire il resto.

MACH (Microservices, API-first, Cloud-native, Headless) descrive i principi tecnici che rendono possibile il composable. Servono componenti di tipo MACH per un’architettura modulare, ma usarli non vi rende automaticamente composable.

Si può quindi essere headless senza essere composable (uno storefront React su un unico motore commerce integrato) e composable senza essere headless (uno shop con rendering lato server che richiama un servizio di ricerca esterno). Oggi la maggior parte dei progetti SAP Commerce Cloud si colloca a metà strada: storefront disaccoppiato, nucleo commerce integrato e due o tre servizi specializzati.

Come SAP Commerce Cloud supporta entrambi

SAP Commerce Cloud è headless per progettazione e composable ai margini.

API REST OCC. Prodotti, categorie, carrelli, checkout, ordini e clienti sono esposti come endpoint REST. Qualsiasi frontend o sistema esterno può richiamarli, e con estensioni proprie si possono aggiungere endpoint personalizzati. Senza questo livello, il composable resterebbe una slide.

Composable Storefront. Lo storefront di SAP basato su Angular (in precedenza Spartacus) comunica con Commerce Cloud solo tramite OCC. Potete estenderlo oppure sostituirlo con React o Next.js senza toccare il motore commerce. SAP lo documenta nella guida al Composable Storefront su SAP Help. A settembre 2026 SAP ha inoltre annunciato una partnership con Vercel per storefront Next.js su Commerce Cloud; confrontiamo le opzioni frontend in Composable Storefront o React/Next.js.

Estensioni side-by-side su SAP BTP. Logiche proprie, come una regola di prezzo particolare o un servizio di raccomandazione, possono girare su SAP BTP ed essere richiamate da Commerce Cloud, invece di essere integrate nel nucleo.

Servizi specializzati ai margini. Ricerca (Solr integrato o un servizio esterno), gestione dei contenuti (SmartEdit o un CMS headless), pagamenti tramite integrazioni con gateway, SAP Engagement Cloud (ex SAP Emarsys) per l’automazione del marketing e SAP Customer Data Cloud per identità e consensi.

Ciò che Commerce Cloud non è: un insieme di microservizi distribuibili in modo indipendente. Carrello, calcolo dei prezzi, promozioni e ordini funzionano come un’unica piattaforma. Nel B2B è di solito un vantaggio, perché è proprio lì che si trovano prezzi contrattuali, gerarchie clienti e collegamento con l’ERP.

Quando il composable ha senso nel B2B?

Il composable ripaga in tre situazioni. Se nessuna vi riguarda, la complessità aggiuntiva difficilmente vale la pena.

Lo storefront fa parte del vostro marchio, non è solo un catalogo. Se gli acquirenti devono trovare un configuratore di prodotto, contenuti ricchi o una selezione guidata invece di un elenco con pulsante d’ordine, un frontend disaccoppiato offre a designer e sviluppatori uno spazio che i modelli predefiniti non danno.

Gestite più storefront. B2B e B2C, più marchi o paesi su un unico nucleo commerce: il disaccoppiamento permette a ogni esperienza di evolvere in autonomia, mentre prezzi, giacenze e ordini restano in un unico posto.

Rilasciate modifiche al frontend di continuo. Se il business richiede modifiche più volte alla settimana, cicli di rilascio separati eliminano l’attesa dei deployment del backend. Distrelec è il nostro riferimento: dopo che abbiamo disaccoppiato il suo frontend da SAP Commerce Cloud, il time-to-market delle modifiche frontend è sceso del 70%.

Quando il composable è la scelta sbagliata?

Nessuno sviluppatore frontend dedicato. Un frontend personalizzato è un’applicazione JavaScript che qualcuno deve sviluppare e mantenere. Se il team è composto soprattutto da sviluppatori SAP e backend, passerete più tempo sullo stack frontend che sulle funzioni commerce.

Una scadenza stretta. Scegliere i componenti, collegarli e costruire le pipeline richiede tempo prima che passi il primo ordine. Nelle nostre valutazioni si tratta di diverse settimane in più rispetto a un avvio integrato. Con una data di go-live fissa, partite con il Composable Storefront.

Un caso d’uso semplice. Un portale di riordino con funzioni B2B standard non ha bisogno di un frontend personalizzato. Il Composable Storefront lo copre, e il budget è investito meglio in prezzi corretti e in un’integrazione ERP che funziona.

Da dove iniziare

Non scomponete tutto in una volta. Partite dove il beneficio per gli acquirenti è maggiore e il rischio per il flusso degli ordini è minore.

Ordine	Componenti	Perché qui
Iniziare da qui	Ricerca, pagamenti, analisi commerce	Beneficio visibile, interfacce chiare, facile tornare indietro
In seguito	CMS headless accanto a SmartEdit, personalizzazione, automazione del marketing (ad es. SAP Engagement Cloud)	Richiede prima dati puliti e processi per i contenuti
Da valutare più avanti	Storefront completamente personalizzato, PIM proprio al posto dei contenuti di prodotto integrati, funzioni spostate in servizi BTP	Impegno massimo, tocca il flusso degli ordini

Nel frattempo mantenete stabile il nucleo commerce: carrello, checkout, calcolo dei prezzi, ordini e gestione dei prodotti restano in Commerce Cloud. Validate ogni nuova integrazione prima di aggiungere la successiva.

I rischi che nessuno mette nelle slide

Onere di integrazione. Ogni componente è un’interfaccia, un contratto e un ciclo di aggiornamento in più. Cinque servizi significano cinque fornitori e cinque possibili punti di guasto. Il codice di collegamento tra loro può costare più di qualsiasi singolo componente.

Esercizio. Monitorare una piattaforma è routine. Monitorarne dieci richiede tracciamento distribuito, allarmi tra fornitori diversi e un team capace di trovare il guasto quando un ordine si blocca tra due sistemi. È una competenza diversa dallo sviluppo commerce classico.

La dipendenza si sposta, non scompare. Non dipendete più da un solo fornitore, ma dal vostro livello di integrazione. Se il codice di collegamento è complesso, sostituire un componente è più difficile di quanto promettano le brochure.

I migliori componenti non fanno automaticamente il miglior insieme. La migliore ricerca, il miglior CMS e il miglior fornitore di pagamenti non producono da soli la migliore esperienza d’acquisto. Conta quanto bene funzionano insieme su un ordine reale.

Dopo la fine dell’on-premise: tre strade

La manutenzione ordinaria di SAP Commerce on-premise (ultima release 2205) è terminata il 31 luglio 2026; da allora è disponibile solo una manutenzione specifica per cliente (SAP Help). Per molti team è il momento di porsi la domanda sul composable. Le strade realistiche sono tre:

Strada	Cosa significa	La nostra stima di pianificazione	Adatta quando
SAP Commerce Cloud	Portare la logica esistente sulla piattaforma gestita da SAP	Circa 3-6 mesi	Le personalizzazioni sono legate ai modelli dati SAP, il team conosce SAP Commerce
Ibrida	Commerce Cloud come nucleo, frontend personalizzato disaccoppiato, servizi specializzati nel tempo	Circa 4-8 mesi	Volete libertà nel frontend senza reimplementare la logica commerce
Completamente composable	Sostituire la piattaforma con servizi separati per commerce, contenuti, ricerca e ordini	Spesso 9-15 mesi	Team interno forte, landscape API-first, requisiti insoliti

Questi intervalli derivano dalle nostre valutazioni e dipendono dal perimetro del progetto; non sono un’offerta. La piattaforma Franke mostra cosa si ottiene con un perimetro mirato: Spadoom ha messo in produzione la piattaforma SAP Commerce Cloud in 90 giorni, un dato che si riferisce a quel lancio commerce. Se siete ancora on-premise, i passi successivi sono descritti nel nostro articolo su cosa fare ora che il supporto on-premise è terminato.

Una ricostruzione completamente composable significa reimplementare anni di regole promozionali, calcolo dei prezzi e logica B2B che Commerce Cloud conserva. Questo da solo è spesso un progetto più grande dell’intero passaggio al cloud.

Come decidere?

Sei domande. Rispondete pensando al team che avete oggi, non a quello che sperate di avere.

1. Avete almeno due sviluppatori frontend dedicati? Se no, partite con un’architettura integrata.
2. Vi servono più storefront distinti? Se sì, il composable ha buoni argomenti.
3. Il go-live è a meno di sei mesi? Se sì, partite con un’architettura integrata.
4. Lo storefront distingue il vostro marchio o è uno strumento funzionale? Se distingue il marchio, disaccoppiatelo. Se è uno strumento, restate integrati.
5. I vostri sistemi ERP, PIM e logistici offrono già API pulite? Se i dati viaggiano ancora con file batch e fogli di calcolo, il composable aggiunge complessità senza il suo vantaggio principale.
6. Potete gestire per anni più rapporti con fornitori e un frontend personalizzato? Il composable non è un progetto una tantum.

Per la maggior parte dei progetti B2B su SAP Commerce Cloud la nostra raccomandazione è la stessa: partire integrati, disaccoppiare il frontend dove serve e modularizzare ulteriormente man mano che team e requisiti crescono. Le API OCC mantengono aperta questa opzione senza toccare il motore commerce. Qualunque strada scegliate, l’ordine deve arrivare correttamente nell’ERP. Per questo pianifichiamo storefront e integrazione ERP con un unico team, come descritto nell’articolo su un webshop B2B su SAP Commerce Cloud con S/4HANA Public Cloud. Se confrontate piattaforme oltre SAP, leggete il nostro confronto tra SAP, Salesforce e Adobe Commerce.

---

Volete capire quale approccio si adatta alla vostra situazione? Le nostre valutazioni architetturali considerano team, tempistiche, landscape ERP e requisiti. Parlate con i nostri architetti commerce oppure scoprite di più sui nostri servizi per SAP Commerce Cloud.

Domande frequenti

Qual è la differenza tra headless e composable commerce?

Headless separa lo storefront dal backend commerce, che comunicano solo tramite API. Composable va oltre: ricerca, contenuti, pagamenti o personalizzazione diventano servizi separati e sostituibili. Ogni architettura composable è headless, ma uno storefront headless su un unico motore commerce integrato non è composable. SAP Commerce Cloud supporta entrambi gli approcci tramite le API REST OCC.

SAP Commerce Cloud è headless o composable?

È headless per progettazione e composable ai margini. Le API OCC mettono prodotti, carrelli, checkout, ordini e clienti a disposizione di qualsiasi frontend, mentre ricerca, CMS, pagamenti o marketing possono essere servizi esterni. Il nucleo commerce (carrello, prezzi, promozioni, ordini) resta una piattaforma integrata, non un insieme di microservizi distribuiti in modo indipendente.

Possiamo partire con il Composable Storefront e passare più tardi a un’architettura completamente composable?

Sì, ed è ciò che raccomandiamo per la maggior parte dei progetti B2B. Il Composable Storefront usa le stesse API OCC di qualsiasi frontend personalizzato, quindi un passaggio successivo a React o Next.js lascia intatti configurazione commerce, modello dati e integrazione ERP. Sostituite un componente alla volta, iniziando da quello che crea più problemi.

Di quanti sviluppatori ha bisogno un’architettura composable?

Contate su due o tre sviluppatori frontend dedicati, uno o due sviluppatori commerce o di integrazione e una persona responsabile di DevOps e monitoraggio su più pipeline di rilascio. Un’architettura integrata con il Composable Storefront spesso funziona con un team più piccolo di sviluppatori SAP Commerce. Serve inoltre qualcuno che sia responsabile dell’architettura complessiva.

Il composable commerce costa più di un’architettura integrata?

All’inizio sì: selezione dei componenti, lavoro di integrazione e pipeline aggiuntive richiedono settimane e budget prima del primo ordine. Su tre-cinque anni può ripagarsi, se cambiate davvero componenti o gestite più storefront. Il principale fattore di costo non sono le licenze, ma integrazione ed esercizio: ogni servizio aggiunto porta un proprio contratto, un proprio ciclo di rilascio e proprie possibili anomalie.

Cosa è cambiato per i clienti on-premise dopo il 31 luglio 2026?

La manutenzione ordinaria (mainstream maintenance) di SAP Commerce on-premise, con ultima release 2205, è terminata il 31 luglio 2026; ora è disponibile solo una manutenzione specifica per cliente. Il passaggio a SAP Commerce Cloud conserva logica di business e modelli dati esistenti, mentre una ricostruzione completamente composable significa reimplementarli. Una via di mezzo frequente è Commerce Cloud come nucleo con un frontend disaccoppiato.