tempo di lettura: 8 minuti

Il composable esiste, ma non sempre viene chiamato così.

Nel confronto quotidiano sulla trasformazione digitale, il termine composable non è sempre il primo ad emergere. Si parla più spesso di integrazione, modernizzazione dei sistemi, efficienza operativa, qualità del dato, user experience, cloud, automazione o riduzione della complessità applicativa.

Sono temi diversi, ma rimandano ad una stessa esigenza: sistemi aziendali capaci di tenere il passo con l’evoluzione del business. Ogni cambiamento, oggi, rischia di richiedere più tempo e più sforzo di quanto dovrebbe.

Le aziende non partono necessariamente dal “composable”. Cercano sistemi in grado di evolvere senza generare ogni volta un progetto a sé, dati affidabili e accessibili nei contesti in cui servono, e la possibilità di intervenire su una parte del processo senza rimettere in discussione l’intero assetto applicativo.

Il composable può essere letto come una risposta progettuale a queste esigenze. Non un nuovo nome per vecchi problemi, ma un modo diverso di progettare le capability applicative, a partire dalla funzione operativa da abilitare, non dall’applicazione che la ospita.

In questo modo, ogni componente ha un confine riconoscibile, dialoga con i sistemi coinvolti e può evolvere con maggiore autonomia rispetto al resto dell’architettura. Pensiamo, ad esempio, ad un processo di gestione dell’ordine che coinvolge ERP, CRM e portale cliente. In un modello tradizionale, le informazioni e le regole operative possono restare distribuite tra più sistemi, rendendo ogni modifica dipendente da integrazioni specifiche e da interventi coordinati su più punti dell’architettura.

Un approccio composable porta invece a progettare la capability “gestione ordine” come un livello applicativo riconoscibile, integrato tramite API con i sistemi coinvolti e costruito attorno al processo da governare. L’obiettivo non è ridurre artificialmente il numero dei sistemi, ma ridurre la dipendenza tra le loro logiche operative, così che l’evoluzione di una parte del processo non richieda ogni volta di intervenire sull’intero sistema.

I segnali di mercato. Trasformazione continua, ma ancora frammentata

Questa esigenza trova riscontro anche nei dati di mercato. Una ricerca di Forrester Consulting commissionata da SAP, condotta su 1.007 decision maker senior coinvolti nella strategia e nell’esecuzione del cambiamento in grandi imprese, evidenzia che la trasformazione digitale è ormai una presenza costante nelle organizzazioni, ma non sempre viene governata come un percorso unitario. Spesso resta distribuita tra iniziative diverse, funzioni separate e priorità non pienamente allineate; secondo il report, infatti, il 72% delle organizzazioni conduce quattro o più iniziative di trasformazione all’anno, ma molte restano disconnesse e difficili da scalare:

“Transformation is continuous — but still fragmented. […] Nearly three-quarters (72%) of companies annually undertake four or more enterprisewide transformation initiatives. Almost one in five (18%) run six to nine initiatives, and 16% report 10 or more.” (The Capability Mindset: Turning Business Transformation Into A Repeatable Discipline)

La stessa ricerca mette in evidenza una distanza significativa tra intenzione e capacità esecutiva. Più dell’80% dei rispondenti esprime fiducia nella capacità della propria organizzazione di innovare, gestire il rischio e adattarsi al cambiamento. Tuttavia, solo il 24% dichiara di avere una governance board cross-funzionale capace di allineare priorità di business, processo e tecnologia, solo il 25% collega gli obiettivi di trasformazione ai KPI dei senior leader e solo il 26% mantiene una roadmap per la modernizzazione dei sistemi legacy.

Questa distanza non si spiega con la mancanza di visione o di investimento. La trasformazione si affievolisce perché la visione non viene tradotta in meccanismi operativi sufficientemente ripetibili: il disallineamento tra processi di business e IT è considerato molto o estremamente sfidante dal 51% dei rispondenti, a cui si aggiungono ownership dei processi in silos, mancanza di monitoraggio real time, qualità del dato insufficiente e debito tecnico.

Dai progetti ai processi applicativi

L’attenzione, quindi, si sposta dal numero di iniziative avviate alla capacità dell’organizzazione di assorbirle nei propri processi operativi. La trasformazione diventa più governabile quando non resta confinata a singoli progetti, ma trova una traduzione applicativa coerente nel modo in cui dati, attività, responsabilità e sistemi vengono collegati tra loro.

Questa difficoltà emerge con particolare evidenza nei modelli fortemente application-centric, dove attività che appartengono allo stesso flusso di business vengono distribuite tra applicazioni diverse, ciascuna con le proprie interfacce, regole e modalità operative. L’utente deve così ricomporre manualmente ciò che il sistema non restituisce come esperienza unitaria. Ne deriva una complessità operativa che può rallentare anche l’evoluzione successiva del processo.

È qui che la componibilità assume un significato concreto. Il composable non consiste nell’aggiungere nuove applicazioni al sistema informativo, ma nel progettare componenti a partire dal processo da sostenere, non dal singolo perimetro applicativo.

Una lettura simile emerge anche nel dibattito intorno alle architetture enterprise. Gartner, in un reference architecture brief del 2025, collega le applicazioni composable ad un’architettura basata su applicazioni, API e servizi, capace di abilitare agilità, flessibilità, integrazione e modularità. Anche SAP utilizza oggi il linguaggio della componibilità, associandolo alle composable applications e al composable business: un segnale del fatto che modularità, adattabilità e integrazione sono ormai entrate nel lessico della trasformazione enterprise.

Questa logica progettuale non è esclusiva del mondo gestionale. La si ritrova nelle architetture MACH (Microservizi, API-first, Cloud-native, Headless) un approccio nato prevalentemente in ambito e-commerce che condivide la stessa intuizione di fondo. Contesti diversi, quindi, ma una stessa direzione progettuale che mira a superare sistemi rigidi e isolati a favore di architetture più modulari, integrabili e adattabili all’evoluzione dei processi.

Dal processo alla capability

Questa logica è vicina ai principi del Domain-Driven Design, perché porta a progettare le soluzioni a partire dal dominio di business, dalle sue regole e dalle “capability”, intese come capacità operative necessarie a far evolvere il processo nel tempo.

La modularità, quindi, non coincide con la semplice scomposizione tecnica del software, assume valore quando ogni componente rappresenta una funzione di business riconoscibile, integrabile con altri sistemi e riutilizzabile in più contesti applicativi.

Composable significa anche testabilità, riuso e sostenibilità evolutiva

Per rendere la componibilità sostenibile nel tempo, non basta progettare componenti modulari. Ogni componente deve poter essere testato, mantenuto e fatto evolvere senza compromettere ciò che è già stato costruito.

In una logica composable, un’applicazione non è un blocco unico, ma un insieme di livelli che possono essere validati separatamente e poi verificati nella loro composizione. Nel caso di applicazioni integrate con sistemi ERP, per esempio, questo significa controllare le logiche backend, i servizi API che rendono disponibili funzionalità e dati, e i moduli frontend che costruiscono l’esperienza utente.

Il riuso, in questa prospettiva, non riguarda solo la possibilità di impiegare lo stesso componente in più applicazioni, riguarda la costruzione progressiva di un patrimonio applicativo più affidabile, conosciuto e mantenibile nel tempo.

È questa maturità a rendere la componibilità rilevante oltre la fase di sviluppo, riducendo il rischio che ogni nuova esigenza diventi un nuovo sviluppo isolato. 

Dare metodo alla modularità

La trasformazione digitale non si misura dalle iniziative avviate, ma dalla capacità di non ricominciare da capo ogni volta. Il composable non è una risposta architetturale astratta, ma un modo per evitare che ogni evoluzione aggiunga nuova complessità. Serve per costruire un patrimonio applicativo che possa essere mantenuto, esteso e riutilizzato. Non è un punto di arrivo, è un modo di lavorare. 

E forse è per questo che il mercato non lo chiama ancora per nome, ma lo cerca ogni giorno.