Modernizzazione Software Legacy: AS400, VB6 e .NET Framework

Un software legacy non è semplicemente un software vecchio: è un software che funziona ancora, che regge processi importanti e che però nessuno può più modificare senza rischio. Nelle PMI manifatturiere e logistiche dell'Emilia-Romagna questo si presenta quasi sempre nella stessa forma: un gestionale su AS400/iSeries che gira da vent'anni, un programma di reparto scritto in Visual Basic 6, un applicativo su una vecchia versione di .NET Framework che gira solo su un server che nessuno osa spegnere.

I sintomi che rendono urgente l'intervento sono ricorrenti: una sola persona sa mettere le mani sul codice, il sistema non parla con nulla di quello che è stato aggiunto dopo — e-commerce, app per gli agenti, portali per i clienti — le versioni di sistema operativo e di database sono fuori supporto, e ogni piccola modifica richiede settimane. A quel punto il costo di non intervenire smette di essere teorico: si paga in ore di lavoro manuale, in occasioni commerciali perse e in rischio di fermo.

La modernizzazione, però, non coincide con la riscrittura. Riscrivere tutto è la scelta più costosa e più rischiosa, e spesso non è necessaria: in molti casi il sistema esistente è solido nel suo perimetro e il vero problema è che resta isolato. Per questo il primo passo è sempre capire cosa si ha davanti, non decidere in anticipo dove si vuole arrivare. Il nostro metodo di sviluppo software parte dall'osservazione dei processi reali, e su un progetto legacy questo conta ancora di più, perché una parte delle regole di business non è scritta da nessuna parte se non nel codice.

strategia

Wrapping API

Il wrapping consiste nell'esporre le funzioni del sistema legacy attraverso API moderne, lasciando il sistema esattamente dov'è. Il gestionale continua a lavorare come ha sempre fatto, ma smette di essere un'isola: da quel momento un'app mobile per gli agenti, un e-commerce o un portale clienti possono leggere le giacenze e scrivere gli ordini senza che nessuno ricopi nulla a mano. È l'intervento più rapido e meno invasivo, e ha senso quando il sistema è stabile e copre bene il suo perimetro: il problema da risolvere è l'isolamento, non la logica applicativa. Il limite va detto con chiarezza: il wrapping non riduce il debito tecnico sottostante e non risolve il rischio di avere una sola persona in grado di manutenere quel codice. Risolve il problema di integrazione, che spesso è quello che blocca il business nell'immediato, e compra tempo per pianificare il resto con calma.

strategia

Strangler fig

Lo strangler fig è la strategia che proponiamo più spesso sui sistemi in esercizio. L'idea è sostituire il legacy un modulo alla volta invece che in blocco: si sceglie una funzione, la si riscrive su stack moderno, la si manda in produzione affiancata alla vecchia e si sposta il traffico solo quando ha dimostrato di funzionare. Ripetendo il ciclo, il perimetro del sistema vecchio si restringe progressivamente fino a esaurirsi. Il vantaggio non è tecnico ma di rischio: ogni passo è piccolo, misurabile e reversibile, e il valore arriva fin dal primo modulo invece che alla fine di un progetto lungo. In cambio richiede disciplina — per un certo periodo due sistemi convivono e vanno tenuti sincronizzati — e una scelta accorta dell'ordine dei moduli, che decidiamo insieme all'azienda partendo da dove il dolore operativo è maggiore.

strategia

Rewrite completo

Il rewrite riscrive l'applicazione da zero su tecnologie attuali. È la strada che dà il massimo margine di manovra — modello dei dati ripensato, nessun vincolo ereditato, debito tecnico azzerato — ma concentra tutto il rischio in un unico passaggio: finché il nuovo sistema non è completo non produce valore, e il confronto con il vecchio avviene tutto in una volta. Per questo lo proponiamo quando le alternative incrementali non reggono davvero: quando la tecnologia di base non è più supportata né ospitabile, quando il modello dei dati impedisce qualsiasi evoluzione, o quando i processi che il software supporta sono cambiati al punto che replicarli non avrebbe senso. In quei casi la riscrittura è la scelta onesta, e va affrontata con una migrazione dei dati progettata e riconciliata, non improvvisata alla fine.

Nessuna delle tre strategie viene scelta a priori. Il percorso è sempre lo stesso e la decisione arriva alla fine della seconda fase, quando ci sono elementi concreti per prenderla:

1. Assessment del parco applicativo: leggiamo il codice e la banca dati, mappiamo le integrazioni esistenti e osserviamo come le persone usano davvero il sistema. Serve a distinguere i moduli vivi da quelli che nessuno apre da anni e a far emergere le regole di business che esistono solo nel codice.
2. Scelta della strategia, modulo per modulo: la decisione non è unica per tutto il sistema. Su uno stesso gestionale capita spesso di esporre via API la parte anagrafica, riscrivere in modo incrementale il ciclo ordini e lasciare intatto un modulo contabile che funziona bene.
3. Messa in sicurezza della base dati: prima di spostare qualsiasi funzione, i dati vengono analizzati, normalizzati dove serve e dotati di procedure di migrazione ripetibili, provate su copie reali finché i totali riconciliano.
4. Migrazione incrementale con doppio binario: le nuove funzioni entrano in produzione affiancate alle vecchie e i due sistemi restano allineati tramite connettori, così ogni passaggio è reversibile sul singolo modulo.
5. Affiancamento e dismissione: gli utenti passano al nuovo sistema per gradi, con formazione sul campo; il legacy viene spento solo quando il suo perimetro residuo è vuoto, non prima.

Su cosa incide il costo di un progetto di questo tipo e come si struttura un preventivo lo abbiamo spiegato nella pagina quanto costa un software su misura. A valle della modernizzazione, il sistema entra nel percorso di manutenzione software evolutiva, perché il debito tecnico si riforma se nessuno lo tiene sotto controllo.

La parte che determina la riuscita di una modernizzazione incrementale non è la riscrittura: è il collegamento tra il vecchio e il nuovo mentre convivono. Sviluppiamo connettori e middleware verso AS400/iSeries, SAP e i gestionali di mercato già in uso, così che anagrafiche, giacenze e ordini restino allineati durante tutta la transizione, senza doppia digitazione e senza disallineamenti tra magazzino e ordini. Il lavoro si appoggia sulle API web custom e sulle stesse pratiche di software testing e QA che usiamo sui progetti nuovi.

Dove invece il gestionale va davvero sostituito, il punto di arrivo è un software gestionale ERP custom modellato sull'operatività esistente, affiancato dove serve dal CRM su misura e dalla digitalizzazione dei processi aziendali per i flussi che oggi vivono fuori dal sistema, tra Excel e email.