Perché le riscritture integrali vanno male
Una riscrittura completa significa costruire una seconda versione del sistema mentre la prima continua a cambiare. Il nuovo sistema non porta valore finché non è finito, i requisiti sono sepolti in un codice che nessuno conosce fino in fondo e il passaggio avviene tutto in una volta, con tutti i rischi concentrati in un solo giorno. Molte riscritture vengono abbandonate a metà strada, dopo aver consumato il budget, mentre il vecchio sistema ha continuato a evolvere senza di loro.
Esiste una strada più sicura, che sostituisce il sistema un pezzo alla volta mentre l'azienda continua a lavorare.
Il pattern strangler fig
Il nome, coniato da Martin Fowler, viene da un fico tropicale che cresce attorno a un albero ospite finché non riesce a reggersi da solo. Applicata al software, l'idea è semplice:
- Si mette uno strato di instradamento davanti al sistema legacy: un proxy, un API gateway o una facciata nell'interfaccia utente. All'inizio inoltra tutto al vecchio sistema.
- Si costruisce una funzionalità nel nuovo sistema, ad esempio la ricerca clienti o la generazione di un certo documento.
- Si instrada quella funzionalità verso il nuovo sistema. Tutto il resto continua ad andare al vecchio.
- Si ripete, funzionalità dopo funzionalità, finché il vecchio sistema non gestisce più nulla e può essere spento.
Ogni passo è piccolo, porta valore appena è in produzione e si può annullare cambiando una regola di instradamento.
Che cosa spostare per primo
Un buon primo tassello unisce valore visibile e rischio contenuto:
- Una funzionalità con confini chiari, con poche dipendenze dal resto del sistema.
- Un problema reale: lenta, soggetta a errori o impossibile da modificare nel sistema attuale.
- Un risultato misurabile: utenti, tempi di risposta, tassi di errore o tempi di lavorazione confrontabili prima e dopo.
Evitate di partire dal cuore transazionale. Si parte dai bordi, si impara come si comporta davvero il vecchio sistema e si procede verso l'interno.
Le tecniche di supporto
Lo strato anti-corruzione
Il nuovo sistema non deve ereditare il modello dati e le stranezze del vecchio. Uno strato anti-corruzione traduce tra i due, così il nuovo codice è progettato attorno ai concetti di business di oggi e non attorno a tabelle battezzate nel 2005.
I dati, la parte più difficile
Finché entrambi i sistemi sono attivi, spesso hanno bisogno degli stessi dati. Le opzioni, dalla più semplice alla più robusta:
- il nuovo componente legge direttamente il database legacy, temporaneamente e in sola lettura;
- i dati vengono sincronizzati tra i due, con change data capture o eventi;
- la titolarità di un insieme di dati passa al nuovo sistema, e il vecchio legge da lì.
Decidete esplicitamente quale sistema è titolare di ogni dato in ogni fase. Due sistemi che scrivono gli stessi record sono l'origine della maggior parte degli incidenti.
Esecuzione in parallelo e feature flag
Per i calcoli critici si fanno girare vecchio e nuovo fianco a fianco sugli stessi input e si confrontano i risultati prima di passare. I feature flag permettono di instradare sul nuovo percorso prima una parte degli utenti o una sola unità di business, e di tornare indietro senza un nuovo rilascio.
Test che fotografano il comportamento attuale
Prima di cambiare qualsiasi cosa si scrivono test di caratterizzazione: test che registrano che cosa fa oggi il sistema legacy, compresi i comportamenti che sembrano strani. Proteggono dal rischio di eliminare una regola che poi si rivela importante. Una pipeline CI/CD affidabile li esegue a ogni modifica.
L'integrazione è metà del lavoro
I sistemi legacy raramente sono isolati: scambiano file con la contabilità, ricevono ordini dall'e-commerce, alimentano report. Ognuno di questi flussi va mantenuto o reindirizzato man mano che le funzionalità si spostano. Sostituire durante la modernizzazione i trasferimenti di file punto a punto con API documentate ripaga due volte: ne parliamo nelle note sulla system integration.
E il cloud?
Modernizzazione e migrazione in cloud vanno spesso insieme: il sistema legacy viene prima spostato così com'è, poi "strangolato" in cloud, con i nuovi componenti costruiti su servizi gestiti. L'ordine dipende da che cosa è più urgente: lasciare un data center o sbloccare le modifiche all'applicazione.
Nel frattempo, il vecchio sistema va tenuto in salute
Per un sistema grande, un percorso di questo tipo può durare mesi o anni. Nel frattempo l'applicazione legacy continua a mandare avanti l'azienda e va mantenuta: patch di sicurezza, piccole correzioni, adeguamenti normativi. Pianificare questa manutenzione insieme alla modernizzazione, invece di congelare il vecchio sistema, evita che cresca la pressione per un passaggio affrettato.
Da dove partire
Mappate le funzionalità del sistema e le loro dipendenze, scegliete un primo tassello ai bordi e mettete in piedi lo strato di instradamento. Il nostro servizio di application management tiene in esercizio il sistema esistente mentre lo modernizziamo passo dopo passo, con un solo team responsabile di entrambi.