Nell’estate del 2020, mentre eravamo tutti concentrati su altro, un gruppo di vendor — commercetools, Contentstack, EPAM, Valtech — ha fondato la MACH Alliance. Da allora la parola composable commerce è diventata il termine che sento ripetere più spesso nelle conversazioni con chi vende online. A qualche mese di distanza, mi sembra il momento giusto per fare il punto, senza entusiasmi da comunicato stampa e senza liquidare tutto come l’ennesima moda.
Parto da una posizione netta, così sappiamo subito da che parte sto: il composable commerce è una risposta seria a un problema reale, ma per la maggior parte del mid-market oggi è una risposta a una domanda che non si è ancora posto.
Cosa vuol dire davvero MACH
MACH è un acronimo: Microservices, API-first, Cloud-native, Headless. Tradotto in pratica, invece di comprare una piattaforma unica che fa tutto — catalogo, checkout, pricing, promozioni, CMS, ricerca — assembli il tuo commerce mettendo insieme tanti servizi specializzati, ognuno il migliore nella sua categoria, tenuti insieme da API. Il commerce engine da una parte, il search da un altro vendor, il CMS da un terzo, il PIM da un quarto.
L’idea di fondo la condivido: il monolite tradizionale ti obbliga a subire i tempi e le scelte di un unico fornitore anche quando un pezzo del sistema non ti serve o non ti convince. Con l’approccio composable, in teoria, cambi il componente search senza toccare il checkout. È la promessa del best-of-breed, e sulla carta è difficile darle torto.
Dove il composable ha senso davvero
Ci sono contesti in cui questo modello non è hype, è la scelta giusta. Li ho visti da vicino:
- Aziende con più touchpoint eterogenei — web, app, chioschi in negozio, marketplace, magari IoT — dove un unico frontend monolitico è oggettivamente scomodo. Qui headless e API-first pagano.
- Organizzazioni con un team tecnico interno robusto, capace di gestire l’integrazione e il ciclo di vita di sei o sette servizi diversi, ciascuno con la sua roadmap, il suo SLA, il suo modello di pricing.
- Cataloghi o modelli di business fuori standard, dove la piattaforma pronta ti sta stretta e la personalizzazione profonda è un requisito, non un vezzo.
In tutti questi casi la composabilità è governance: ti prendi la libertà di scegliere ogni pezzo, e insieme la responsabilità di farli parlare tra loro. Se hai le competenze per gestirla, è un vantaggio competitivo concreto.
Dove invece resta una moda da enterprise
Il problema è che gran parte del racconto sul composable è scritto pensando a merchant enterprise, e viene poi rivenduto al mid-market come se fosse la stessa cosa. Non lo è.
Un merchant da 10-20 milioni di GMV che oggi vende su un monolite ben tenuto, di solito, non ha il problema che il composable risolve. Ha il problema opposto: un team piccolo, poche persone che devono coprire tutto, e una necessità di time-to-market che mal si sposa con l’idea di orchestrare sette vendor. Ho visto progetti in cui la promessa di “cambio il search quando voglio” si è trasformata, nella realtà quotidiana, in “ora devo gestire sette contratti, sette fatturazioni, sette punti di rottura e nessuno che risponde quando qualcosa si incastra tra due sistemi”.
La libertà del best-of-breed ha un costo che sui deck non compare mai: l’integrazione è un lavoro che non finisce. Ogni API che aggiorni, ogni versione che cambia, è manutenzione. Nel monolite quella manutenzione la fa — bene o male — un solo fornitore. Nel composable la fai tu. Per un enterprise con venti sviluppatori è un dettaglio. Per un mid-market con due o tre persone è un rischio operativo serio.
C’è poi una cosa che dico spesso e che ripeto anche qui: il TCO del composable per il mid-market oggi è quasi sempre sottostimato. Non perché i singoli servizi costino tanto, ma perché il costo vero è la persona — o l’agenzia — che tiene insieme il tutto nel tempo.
E Magento / Adobe Commerce in tutto questo?
Qui devo togliermi il cappello da tifoso e mettermi quello dell’onestà, perché lavoro su Magento dal 2011 e potrei essere di parte. La lettura più diffusa è che il monolite sia il vecchio mondo e il composable il nuovo. È una semplificazione che non regge alla prova dei fatti.
Magento / Adobe Commerce, oggi, non è più il monolite chiuso che l’etichetta lascerebbe pensare. Ha un layer GraphQL maturo e ha PWA Studio per costruire frontend headless disaccoppiati dal backend. In altre parole: puoi già fare headless restando su Magento. Puoi già esporre il catalogo via API, montarci sopra un frontend moderno, e integrare i servizi esterni che ti servono davvero — un search, un PIM, un CMS — senza dover ricostruire da zero tutto lo stack.
La mia tesi è questa: per il mid-market la strada giusta oggi non è “monolite o composable”, ma un monolite solido usato in modo componibile dove serve. Tieni il commerce engine che ti dà catalogo, checkout, pricing e promozioni collaudati — la parte dove un errore ti costa fatturato — e componi all’esterno solo i pezzi dove il best-of-breed ti dà un vantaggio misurabile. È un approccio pragmatico, meno fotogenico di un’architettura full-MACH, ma che ti fa dormire la notte.
Il rischio che vedo è culturale più che tecnico: comprare il composable per paura di restare indietro. È FOMO architetturale, e l’ho vista costare cara. La domanda giusta non è “sono ancora su un monolite?”, ma “quale problema di business sto cercando di risolvere, e questa architettura lo risolve o me ne crea di nuovi?”.
Il punto, a mente fredda
La MACH Alliance sta facendo una cosa utile: sta dando un vocabolario e uno standard a un movimento che prima era frammentato. Questo è sostanza. Ma la narrazione che ne è seguita — composable per tutti, subito — è, per il mid-market, ancora più hype che sostanza.
Se hai un team tecnico forte, touchpoint multipli e un modello di business fuori standard, guarda seriamente al composable: è maturo abbastanza. Se sei un merchant mid-market con un team snello e un monolite che funziona, la mossa più intelligente probabilmente non è rifare tutto, ma rendere componibile ciò che hai già — con GraphQL, con un frontend PWA, con integrazioni mirate. Il resto, per ora, è una gara di architetture a cui non sei obbligato a partecipare.
Mini-FAQ
Cos’è il composable commerce?
È un approccio all’e-commerce in cui la piattaforma non è un unico software che fa tutto, ma un insieme di servizi specializzati (commerce engine, search, CMS, PIM) integrati tramite API. Si fonda sui principi MACH: Microservices, API-first, Cloud-native, Headless.
Il composable conviene al mid-market?
Non nella maggior parte dei casi, oggi. Il costo vero non sono i singoli servizi ma l’integrazione e la manutenzione continua, che richiedono un team tecnico che il mid-market raramente ha. Il vantaggio best-of-breed spesso non compensa l’aumento di complessità operativa.
Magento / Adobe Commerce è un monolite superato?
No. Con GraphQL e PWA Studio consente già architetture headless e integrazioni via API, mantenendo collaudati i processi critici come checkout, pricing e promozioni. Permette un approccio componibile senza smontare l’intero stack.
Cosa dovrebbe fare un merchant mid-market oggi?
Partire dal problema di business, non dall’architettura. Nella maggior parte dei casi conviene rendere componibile il monolite esistente — frontend PWA, API, integrazioni mirate — invece di migrare a un’architettura full-composable per timore di restare indietro.
Chi sono — Mi occupo di Magento e Adobe Commerce dal 2011, come progettista e responsabile di soluzioni e-commerce per merchant mid-market. Sono tra i primi in Italia ad aver ottenuto la certificazione Adobe Commerce. Su questo blog racconto, da insider, dove sta andando l’e-commerce e cosa farne — senza vendere nulla.