Software legacy: meglio riscriverlo da zero o modernizzarlo?
Quando un software diventa "legacy"
Quando continua a funzionare ma nessuno ha più il coraggio di toccarlo. L'età c'entra poco. Conta il momento in cui ogni modifica fa paura e costa più del dovuto.
Quasi ogni azienda ne ha uno. Il gestionale scritto quindici anni fa da un fornitore che nel frattempo ha chiuso, l'applicativo interno che conosce una persona sola, il database a cui negli anni si sono attaccati fogli e script. E funziona. Proprio per questo rimandare sembra sempre la scelta più prudente.
I segnali che è arrivato il momento
Il segnale principale è che il software ha smesso di stare dietro all'azienda e ha cominciato a frenarla. Di solito lo si nota prima nelle persone che nel codice.
Una modifica piccola richiede settimane, perché nessuno sa cosa si rompe toccando una parte. La conoscenza sta nella testa di una persona, e quando quella persona è in ferie certe cose non si fanno. Intorno al sistema sono cresciuti i fogli Excel, perché non copre più i casi reali (ne abbiamo parlato in quando i fogli Excel sono diventati il tuo gestionale). Sistema operativo, database o linguaggio non ricevono più aggiornamenti di sicurezza. E ogni scambio con e-commerce, contabilità o fornitori passa da un'esportazione fatta a mano.
Uno di questi segnali da solo non basta. Se ne riconoscete tre o quattro, restare fermi vi sta già costando più che muovervi.
Le tre strade possibili
Si può tenerlo e costruirci intorno, modernizzarlo un pezzo alla volta oppure riscriverlo da zero. La terza è la più attraente, e quasi sempre anche la più rischiosa.
Tenerlo e costruirci intorno vuol dire lasciare il vecchio sistema al centro e "avvolgerlo". Gli si mette davanti un livello che espone i dati in modo moderno, e le funzionalità nuove nascono fuori, in applicazioni separate. Ha senso quando il nucleo funziona bene e i problemi stanno ai bordi, nelle integrazioni o nell'interfaccia.
Modernizzare un pezzo alla volta vuol dire scegliere un'area (gli ordini, il magazzino, la fatturazione), ricostruirla, metterla in produzione e solo dopo passare alla successiva. Per un periodo vecchio e nuovo convivono e si parlano. Sulla carta è più lento. In pratica ogni passo porta valore subito e ogni errore resta piccolo.
Riscrivere da zero vuol dire costruire un sistema nuovo in parallelo e a un certo punto fare il cambio. Lo consigliamo solo quando il vecchio è irrecuperabile, o quando l'azienda è cambiata così tanto che il modello dei dati non regge più.
Perché la grande riscrittura è rischiosa
Perché il vecchio software contiene regole che nessuno ha mai scritto da nessun'altra parte. Rifarlo da zero significa riscoprirle una per una, spesso nel modo peggiore, cioè in produzione.
La condizione particolare concessa a un cliente storico. L'arrotondamento fatto in un certo modo perché così lo voleva il commercialista. Il controllo aggiunto dopo un errore di anni fa. Sono dentro il codice, non nella documentazione e a volte nemmeno nella memoria di chi usa il sistema ogni giorno. Una riscrittura che non le recupera produce un software più pulito che sbaglia in modi nuovi.
Poi c'è il tempo. Mentre il sistema nuovo viene costruito, l'azienda continua a cambiare e il vecchio continua a ricevere modifiche urgenti. Il bersaglio si sposta, ed è per questo che i progetti di riscrittura totale tendono ad allungarsi.
Come cambiare senza fermare l'azienda
Lavorando per aree, facendo convivere vecchio e nuovo, e tirando fuori la conoscenza nascosta prima di sostituire qualcosa.
- Mappate cosa fa il sistema oggi, che spesso non coincide con quello che dovrebbe fare. Si parte dal codice, dai dati e dalle persone che lo usano.
- Scegliete la prima area in base a quanto fa male, non a quanto è facile. Quella che oggi costa più tempo o più errori.
- Fate convivere i due sistemi con un'integrazione chiara, così le persone passano al nuovo senza un giorno X in cui cambia tutto insieme.
- Migrate i dati per gradi e verificateli. Ne parliamo in come migrare i dati dal vecchio gestionale.
- Spegnete il vecchio solo quando nessuno lo apre più.
Noi lavoriamo con sprint di due settimane e una demo funzionante ogni 14 giorni, e in questi progetti aiuta molto. Chi usa il sistema vede ogni pezzo nuovo prima che vada in produzione, ed è lì che saltano fuori le regole dimenticate.
Un'ultima cosa, se il fornitore originale non c'è più. Serve l'accesso al codice sorgente e al database, e il fatto che spesso manchi è il motivo per cui nei contratti nuovi la proprietà del codice va scritta nero su bianco.
Domande frequenti
Quanto dura una modernizzazione?
Dipende da quante aree ci sono e da quanto sono intrecciate. Con un approccio per pezzi, però, il primo risultato in produzione arriva in poche settimane e non alla fine del progetto. Per questo la durata totale pesa meno del fatto che ogni fase sia già utile.
Si può modernizzare un software se il fornitore originale non c'è più?
Sì. Serve l'accesso al codice sorgente e al database. Se il codice non c'è si lavora partendo dai dati e dal comportamento del sistema, e l'analisi richiede più tempo.
È meglio sostituirlo con un software standard?
A volte sì, se i vostri processi somigliano a quelli di tutti. Se invece il vecchio sistema è sopravvissuto così a lungo perché fa cose specifiche vostre, un prodotto standard rischia di togliervi proprio quello che vi distingue.
