Ogni organizzazione ne ha uno: il sistema che nessuno vuole toccare, da cui tutto dipende, che la direzione periodicamente decide di "sistemare una volta per tutte". La conversazione che segue salta di solito all’opzione più drammatica — la sostituzione — e poi si blocca, perché il prezzo è impensabile e il rischio è peggio.
Perché "sostituiamolo e basta" continua a fallire
Modernizzare, incapsulare e sostituire non sono ideologie in competizione; sono strumenti con criteri di selezione misurabili. La risposta giusta per un dato sistema esce da cinque fattori — e per la maggior parte dei patrimoni critici è una combinazione, sequenziata nel tempo, più che un verdetto unico.
I grandi programmi di riscrittura falliscono spesso attraverso un insieme ricorrente di rischi. Lo scope viene definito come "tutto ciò che fa il vecchio sistema" — una specifica che in realtà nessuno possiede, perché decenni di comportamento vivono nel codice, nei workaround e nella testa di chi lo opera. Il vecchio sistema continua a cambiare mentre si costruisce il nuovo, quindi il bersaglio si muove. E il business case presupponeva una data di switch-over, quindi ogni ritardo è visibile e politico.
Niente di tutto questo significa che sostituire sia sempre sbagliato. Significa che la sostituzione è un problema di architettura di migrazione, non una decisione di procurement — e che il fallimento comincia nel momento in cui la domanda viene posta come "vecchio o nuovo?" invece che "cosa deve cambiare, con quale rischio, in quale ordine?"
I cinque fattori, valutati con evidenze
Cinque proprietà del sistema decidono quali modalità sono persino disponibili:
- Criticità di business — cosa succede nell’ora in cui il sistema si comporta male? Più alto il costo, più la risposta deve preservare la continuità di produzione.
- Frequenza di cambiamento — quanto spesso il business ha bisogno che questo sistema cambi? Un sistema stabile sotto bassa pressione di cambiamento merita un trattamento diverso da uno che blocca una roadmap.
- Accoppiamento — quanti altri sistemi ci mettono le mani, e quanto in profondità? L’accoppiamento determina se un confine possa essere tracciato senza un progetto di archeologia.
- Rischio operativo — quanto è compreso? Monitoraggio, test, documentazione, e se le persone che lo conoscono sono ancora in azienda.
- Costo di migrazione — il totale onesto: engineering, migrazione dei dati, esercizio in parallelo, formazione, e il costo opportunità del team che consuma.
Valutate questi fattori con evidenze — mappatura delle dipendenze, log dei cambiamenti, storico degli incidenti — non con impressioni. L’esercizio stesso corregge regolarmente le assunzioni della stanza: il sistema che "tutti" cambiano continuamente risulta cambiare due volte l’anno; quello "ben compreso" non ha test e ha un solo esperto rimasto.
Modernizzare: evoluzione sul posto
Modernizzare significa migliorare il sistema dove sta: ridurre l’accoppiamento, aggiungere test e observability, modularizzare gli interni, aggiornare la piattaforma sottostante. Si adatta a sistemi altamente critici e profondamente accoppiati — dove ogni confine è costoso — ma la cui funzionalità è fondamentalmente giusta.
La sua virtù è che ogni passo è sicuro per la produzione e ha valore autonomo. Il suo limite è che non può cambiare ciò che il sistema fondamentalmente è; se il modello dati o le assunzioni di fondo sono sbagliati per il business, il lavoro sul posto lucida la cosa sbagliata.
Incapsulare: stabilizzare il confine, comprare tempo
Incapsulare significa mettere un’interfaccia deliberata — un livello API, uno stream di eventi, un confine anti-corruzione — tra il sistema legacy e tutto il resto. Gli interni riposano; il patrimonio intorno ottiene un contratto pulito su cui costruire.
L’incapsulamento si adatta quando le nuove capacità sono urgenti ma il nucleo non può ancora essere toccato in sicurezza. È anche la prima mossa naturale di una sostituzione per fasi: una volta che i consumatori parlano con il confine invece che con gli interni, ciò che sta dietro il confine può cambiare senza che se ne accorgano. Il suo pericolo è la permanenza — un wrapper installato come "fase uno" tende a diventare l’architettura. Una decisione di incapsulamento dovrebbe portare una data in cui viene rivista.
Sostituire: giustificato, e sequenziato
La sostituzione è giustificata quando i cinque fattori si allineano: funzionalità fondamentalmente sbagliata per il business, alta pressione di cambiamento, e un costo di migrazione che — totalizzato per intero — batte anni di lotta con il vecchio sistema. Anche allora, la versione credibile è incrementale: scorporare una capacità alla volta dietro il confine, instradare il traffico verso la nuova implementazione, provarla in produzione, ritirare il vecchio percorso, ripetere. Il pattern strangler non è prudenza fine a sé stessa — converte un rischio a cui non si sopravvive in una serie di rischi a cui si sopravvive, ognuno con un rollback.
La versione da rifiutare è il big bang: anni di costruzione in parallelo, un eroico weekend di cut-over, e uno scope definito come parità di funzionalità con un sistema che nessuno conosce per intero.
Combinare le modalità in un unico patrimonio
I patrimoni reali raramente ricevono un solo verdetto. Una forma comune: incapsulare subito il sistema centrale per sbloccare la roadmap; modernizzare i componenti che restano (test, observability, disaccoppiamento); sostituire i due moduli dove il modello dati è davvero sbagliato — attraverso il confine, uno alla volta. La decisione è per capacità, non per sistema, e la sequenza è scelta in base a rischio e impatto sul business.
Una matrice all’opera
Per ogni capacità del sistema, valutate i cinque fattori e ponete tre domande in ordine: la funzionalità è fondamentalmente giusta? Se sì — modernizzare sul posto. Il confine è tracciabile a un costo accettabile? Se sì — incapsulare, e rivalutare da dietro il confine. Il costo onesto di migrazione batte il costo di tenerlo? Solo se sì — sostituire, in modo incrementale, dietro il confine.
Messa per iscritto, la matrice fa qualcosa di prezioso oltre la decisione stessa: trasforma "dovremmo finalmente sistemare il sistema legacy" in una roadmap ingegneristica sequenziata che sopravvive alla revisione di budget — perché ogni passo si giustifica da solo.
Il test delle tre domande
- La funzionalità è fondamentalmente giusta per il business?
- Il confine è tracciabile a un costo accettabile?
- Il costo onesto di migrazione batte il costo di tenerlo?