Ogni azienda vorrebbe cambiare in modo incrementale: aprire un nuovo canale, integrare un partner, collegare meglio ERP e supply chain, portare un caso d'uso AI in produzione senza trasformare ogni intervento in un programma pluriennale. Il problema è che molti sistemi informativi non reagiscono così. Reagiscono come infrastrutture che hanno imparato a sopravvivere, non a evolvere: funzionano, ma appena tocchi un punto si accendono dipendenze, regressioni, passaggi approvativi e tempi di coordinamento che divorano il vantaggio atteso.
Il contesto rende questo attrito sempre meno sostenibile. Nel State of the API 2024 di Postman, oltre 5.600 sviluppatori e professionisti API hanno indicato che il 74% delle organizzazioni si definisce API-first e che il 63% dei team rilascia API in meno di una settimana. Nel CNCF Annual Survey 2024, basato sulle risposte di 750 membri della community cloud native, un quarto dei partecipanti dice che quasi tutto il proprio sviluppo e deployment usa tecniche cloud native. Non è una prova automatica a favore di qualsiasi architettura componibile. È un segnale più semplice: chi deve cambiare spesso non può più permettersi sistemi che assorbono ogni novità come un trauma.
Un'organizzazione si accorge di avere un problema quando ogni nuova iniziativa chiede troppe persone, troppe settimane e troppe verifiche incrociate rispetto al valore che dovrebbe generare.
Molti sistemi informativi sono cresciuti per strati successivi: un ERP esteso negli anni, applicazioni verticali aggiunte per urgenza, interfacce punto-punto nate per risolvere un caso locale e poi rimaste in produzione. Nessun elemento, preso da solo, spiega il blocco. Lo spiega l'insieme. Ogni personalizzazione aumenta il costo del cambiamento successivo, ogni integrazione rigida rende più fragile quella dopo.
Il risultato è che anche un progetto ragionevole - un nuovo configuratore, un portale partner, un workflow di approvazione più rapido - si trasforma in un intervento che tocca troppi nodi contemporaneamente. A quel punto la priorità di business smette di guidare il calendario: lo guida il livello di sinergia accumulato negli anni.
Il danno non sta solo nella lentezza. Sta nel fatto che ogni iniziativa lascia dietro di se altra complessità. Se per esporre un dato bisogna duplicarlo, se per integrare un servizio serve un'altra orchestrazione ad hoc, se ogni team difende il proprio pezzo senza un linguaggio comune, il sistema continua a funzionare ma peggiora a ogni modifica. Ecco perché tanti programmi di modernizzazione sembrano muoversi senza alleggerire davvero l'architettura: aggiungono elementi nuovi sopra dipendenze vecchie.
In questo scenario, composable architecture non vuol dire spezzare tutto in microservizi per principio. Vuol dire progettare capability che possano essere assemblate, sostituite ed evolute con un impatto circoscritto, senza riscrivere ogni volta la mappa intera dei sistemi.
La parola chiave è il confine, più che la frammentazione. Un'architettura è componibile quando funzioni, dati e responsabilità hanno limiti leggibili; quando le integrazioni passano per contratti espliciti; quando API, eventi e servizi non sono solo tecnologia di collegamento, ma il modo con cui l'organizzazione decide dove un dominio inizia e dove finisce.
Per questo la composability non coincide con l'adozione di un singolo pattern. In alcuni casi il perno è un set di API ben governate. In altri conta di più un modello event-driven o una piattaforma applicativa che renda riusabili servizi e dati. La logica del Break Monolith into Microservices di Martin Fowler resta utile proprio qui: il valore non nasce dal numero dei componenti, ma dal fatto che una business capability possa cambiare senza trascinare con se' l'intero stack.
Molte aziende si fermano a metà. Sostituiscono un monolite con una costellazione di servizi, ma senza ownership chiare, versioning, osservabilità, regole di sicurezza o governo delle dipendenze. In quel caso non ottengono una struttura più adattabile. Ottengono un sistema distribuito più difficile da leggere.
Una composable architecture funziona solo se riduce l'attrito del cambiamento. Se invece moltiplica coordinamenti, chiamate sincrone, eccezioni locali e data model incoerenti, sta ricreando i silos con strumenti più moderni.
Quando l'impostazione regge, i benefici non sono astratti. Si vedono nella capacità di introdurre variazioni senza spostare ogni volta il problema sull'intera organizzazione IT.
Il vantaggio più immediato è la velocità. Un nuovo canale, un'integrazione con un partner o un servizio interno da esporre richiedono meno coordinamento trasversale e meno regressioni ad ampio raggio. La modularità ben governata non accelera per magia; accelera perchè restringe il perimetro di ciò che va toccato e verificato.
Conta molto anche sul versante dati e AI. Se i domini sono leggibili, le API sono affidabili e gli eventi hanno un significato stabile, diventa più semplice collegare analytics, automazione decisionale o agenti software ai processi reali. Altrimenti l'AI resta un esercizio laterale: interessante in laboratorio, poco integrabile dove servirebbe davvero.
Un altro vantaggio è che non obbliga al big bang. Una buona architettura componibile consente di isolare per primi i punti dove il costo del cambiamento è più alto: integrazioni lente, workflow troppo accoppiati, servizi esposti in modo incoerente, dati replicati con significati diversi. Da lì si può procedere per sostituzioni progressive, seguendo la logica dello Strangler Fig di Martin Fowler.
Questo approccio ha un effetto spesso sottovalutato. Rende praticabile la personalizzazione dove serve davvero, senza trasformarla in un debito ingestibile. Le applicazioni su misura smettono di essere eccezioni da difendere per anni e tornano a essere componenti che possono evolvere con il business.
Qui si decide se la composable architecture resterà una promessa o diventerà una leva operativa. Senza prerequisiti seri, il rischio non è fallire la modernizzazione: è rifare i silos con nomi più eleganti.
La governance è la prima condizione. Servono standard di integrazione chiari, criteri per il versioning, ownership nette dei domini, cataloghi di API e di eventi che non vivano solo nei repository dei team. Serve anche osservabilità: sapere chi usa cosa, dove si rompe una dipendenza, quali servizi stanno rallentando gli altri.
In pratica, la composability chiede una disciplina che molte organizzazioni rinviano. Eppure è proprio questa disciplina a evitare il ritorno dei silos. Se ogni dominio espone interfacce diverse, se i master data non hanno un governo comune, se le eccezioni applicative diventano la regola, la modularità smette di aiutare.
Conta anche il disegno della piattaforma. Best of breed non significa collezionare prodotti eccellenti e sperare che si parlino. Significa scegliere componenti forti sapendo qual è il livello che li deve orchestrare, quali dati devono restare coerenti, quali flussi vanno standardizzati e quali, invece, meritano una personalizzazione mirata.
Per questo le piattaforme digitali tailor made hanno un ruolo preciso: non aggiungere un altro strato opaco, ma costruire il tessuto connettivo che permette a sistemi diversi di collaborare senza annullare le loro specializzazioni. Se manca questo livello di regia, il best of breed degenera facilmente in best of chaos.
La domanda utile, quindi, non è se passare o no a una composable architecture, ma da dove iniziare per togliere attrito al cambiamento senza bloccare l'operatività.
Conviene partire dai colli di bottiglia che pesano di più sul business: un processo che richiede troppi passaggi manuali, un'integrazione che rallenta ogni rilascio, un'applicazione che concentra troppa logica eterogenea, un dominio dati che genera riconciliazioni continue. La priorità non la decide il fascino della tecnologia. La decide il punto in cui rigidità tecnica e frizione operativa si incontrano.
Una roadmap pragmatica lavora per sequenze brevi ma cumulative: assessment iniziale, scelta dei domini da isolare, definizione dei contratti di integrazione, primi casi ad alto valore, verifica dei benefici e solo dopo estensione. E' una traiettoria meno spettacolare di una riscrittura totale, ma molto più credibile.
Quando funziona, la composable architecture non si nota perchè è di moda. Si nota perché' smette di far pesare ogni cambiamento come una trattativa con il passato. E, per chi oggi deve far convivere evoluzione dei processi, qualità del dato e nuovi use case AI, questa differenza vale piu' di qualsiasi slogan architetturale.