Composable Commerce dopo l'EoMM: È la scelta giusta per la vostra azienda?

La fine della Mainstream Maintenance per SAP Commerce on-prem costringe ogni cliente a una decisione sulla piattaforma. Per alcuni, la risposta è una migrazione diretta a SAP Commerce Cloud. Per altri, l’EoMM è il momento per ripensare tutto — ed è qui che entra in scena il composable commerce.

Ma il composable commerce non è una risposta universale. Risolve problemi specifici per organizzazioni specifiche. Questo articolo vi aiuta a capire se è il percorso giusto per la vostra azienda — o se SAP Commerce Cloud è la mossa più intelligente.

Cosa significa davvero composable commerce

Il composable commerce sostituisce una piattaforma commerce monolitica con un insieme di servizi best-of-breed indipendenti. Invece di un sistema che gestisce tutto, dal catalogo prodotti al checkout alla gestione ordini, selezionate strumenti specializzati per ogni funzione:

• Un headless CMS per i contenuti (Contentful, Storyblok, Strapi)
• Un PIM per i dati prodotto (Akeneo, Salsify, Pimcore)
• Un OMS per la gestione ordini (Fluent Commerce, commercetools Order API)
• Un motore di ricerca per la product discovery (Algolia, Typesense)
• Un framework frontend moderno (Next.js, Nuxt, Astro)

Questi servizi comunicano tramite API. Voi gestite il livello di orchestrazione che li tiene insieme.

La promessa è flessibilità. Potete sostituire qualsiasi componente senza ricostruire l’intera piattaforma. Potete scalare ogni servizio in modo indipendente. Potete usare lo strumento migliore per ogni compito.

La realtà è più sfumata.

Quando il composable ha senso

Il composable commerce funziona bene in situazioni specifiche:

Avete un team di sviluppo interno forte

Il composable commerce sposta la responsabilità dal vendor al vostro team. Non c’è un unico contratto di supporto. Nessuna console di amministrazione unificata. I vostri sviluppatori costruiscono e mantengono le integrazioni, il livello di orchestrazione e il frontend. Se il vostro team ha 5+ sviluppatori commerce esperti che comprendono architetture API e sistemi event-driven, il composable è fattibile.

Se dipendete da consulenti esterni per la maggior parte del lavoro di sviluppo, il composable sarà costoso da costruire e da mantenere.

Vi serve una flessibilità frontend che SAP Commerce Cloud non offre

SAP Commerce Cloud viene con Spartacus (ora Composable Storefront) come frontend di riferimento. È funzionale, ben integrato e stabile. Ma è opinionated. Se il vostro brand richiede un’esperienza di shopping altamente personalizzata — configuratori prodotto 3D interattivi, portali B2B self-service complessi o storefront multi-brand con UX completamente diverse — un approccio composable vi dà più libertà.

Operate con più brand con esigenze diverse

Un gruppo con cinque brand, ognuno con un’esperienza di shopping diversa, cataloghi prodotto diversi e flussi di checkout diversi, può beneficiare di un’architettura composable. Ogni brand può usare i servizi di cui ha bisogno senza essere vincolato da un monolite condiviso.

Il vostro panorama di integrazioni è già API-first

Se il vostro ERP, PIM, CRM e sistemi logistici espongono già API REST o GraphQL pulite, il composable commerce si inserisce naturalmente. State aggiungendo un altro set di API a un’architettura esistente, non ne state adattando una.

Quando SAP Commerce Cloud è la scelta migliore

Per molti clienti SAP Commerce on-prem, SAP Commerce Cloud è il percorso più veloce, economico e a minor rischio. Ecco quando ha più senso del composable:

Le vostre personalizzazioni sono profondamente legate ai modelli dati di SAP Commerce

Se avete speso anni a costruire logica di business intorno al type system, al motore di calcolo del carrello e al framework promozioni di SAP Commerce, migrare a Commerce Cloud preserva quell’investimento. Il composable significa riscrivere quella logica da zero — spesso uno sforzo di 6-12 mesi già solo per quello.

Dovete muovervi in fretta

La scadenza EoMM è luglio 2026. Una migrazione a Commerce Cloud si fa in 3-6 mesi. Quella di Franke l’abbiamo completata in 90 giorni. Un build composable — con selezione dei vendor, design architetturale, sviluppo delle integrazioni e costruzione del frontend — richiede tipicamente 9-15 mesi per un perimetro comparabile. Se il tempo è il vostro vincolo, Commerce Cloud vi porta fuori dall’on-prem più velocemente.

Il vostro team è SAP-centrico

Se i vostri sviluppatori conoscono SAP Commerce a menadito ma hanno poca esperienza con ecosistemi Node.js, architetture headless e pattern event-driven, un approccio composable comporta una curva di apprendimento ripida. Commerce Cloud permette al vostro team di lavorare in un ambiente familiare con strumenti migliorati.

Volete un unico vendor per il supporto

SAP Commerce Cloud vi dà un contratto di supporto, un SLA, un percorso di escalation. Il composable commerce significa gestire 5-10 relazioni con vendor, ognuna con condizioni di supporto diverse, cicli di rilascio diversi e modelli di pricing diversi. Questo overhead operativo viene spesso sottovalutato.

L’approccio ibrido

Esiste una via di mezzo che funziona per alcune organizzazioni: partire con SAP Commerce Cloud e adottare gradualmente elementi composable.

SAP Commerce Cloud supporta il commercio headless attraverso le sue API OCC (Omni Commerce Connect). Potete sostituire il Composable Storefront predefinito con un frontend personalizzato mantenendo SAP Commerce Cloud come backend per catalogo, carrello, checkout e gestione ordini.

Questo approccio vi offre:

• Migrazione rapida dall’on-prem (3-6 mesi)
• Libertà sul frontend attraverso l’architettura headless
• Stabilità del backend dalla piattaforma gestita da SAP
• Decomposizione graduale — sostituire componenti SAP con servizi best-of-breed nel tempo, man mano che il vostro team sviluppa le competenze

Abbiamo visto che funziona bene per le aziende che vogliono la flessibilità del composable ma non possono permettersi la timeline o il rischio di una decomposizione completa adesso.

Il framework decisionale onesto

Ponetevi queste cinque domande:

1. Quanti sviluppatori commerce avete internamente? Se meno di 5, il composable commerce metterà sotto pressione il team. Commerce Cloud è più sicuro.

2. Potete permettervi una timeline di 12-15 mesi? Se dovete uscire dall’on-prem entro luglio 2026 e non avete ancora iniziato, il composable è troppo lento. Commerce Cloud è realistico.

3. Il vostro frontend deve essere fondamentalmente diverso da Composable Storefront? Se le esigenze sono B2C o B2B standard, Composable Storefront è sufficiente. Non vi serve il composable solo per differenze minori di UI.

4. Il vostro panorama di integrazioni è già API-first? Se il vostro ERP funziona ancora con file batch e il vostro PIM è un foglio Excel, il composable aggiunge complessità senza offrire il suo vantaggio principale.

5. Siete pronti a gestire molteplici relazioni con vendor? Ticket di supporto presso 5-10 fornitori, conflitti di versione e scaricabarile quando qualcosa si rompe — se sembra estenuante, lo è. Commerce Cloud vi dà un unico interlocutore.

Cosa raccomandiamo

Non siamo ideologici su questo tema. Abbiamo costruito su SAP Commerce Cloud e abbiamo lavorato con stack composable. La risposta giusta dipende dal vostro business.

Per la maggior parte dei clienti SAP Commerce on-prem che affrontano l’EoMM, SAP Commerce Cloud è la scelta pragmatica. È più veloce, a minor rischio e preserva l’investimento esistente. La migrazione Franke — 90 giorni, SAP Quality Award — è la prova di ciò che è possibile.

Per le aziende con team di engineering maturi, complessità multi-brand e un orizzonte di 12+ mesi, il composable commerce può offrire vantaggi significativi a lungo termine. Ma entrateci con gli occhi aperti: costa di più all’inizio, richiede più tempo e richiede un investimento continuo in engineering.

E per chi sta nel mezzo? L’approccio ibrido — backend Commerce Cloud con frontend personalizzato — spesso è il punto di equilibrio ideale.

Troviamo il vostro percorso

Ogni situazione è diversa. Partiamo con un assessment architetturale: la vostra piattaforma attuale, le competenze del team, il panorama delle integrazioni e la vostra timeline. Da lì, raccomandiamo l’approccio che si adatta — non quello che suona più emozionante.

Parlateci — vi aiuteremo a prendere la decisione giusta sulla piattaforma prima che l’EoMM ne imponga una affrettata.