Va bene il cloud, va bene la virtualizzazione, vanno bene i nuovi modelli applicativi e di sviluppo che si stanno affermando in questi anni. Resta però il fatto che in tutto il mondo ci sono miriadi di applicazioni e servizi critici portati avanti da sistemi definiti - già da tempo - legacy ma che i loro utenti non hanno nessuna voglia di mandare in pensione. A volte però si pone quantomeno il problema dell'evoluzione di questi sistemi, di solito per soddisfare esigenze di business che la piattaforma in uso non riesce a supportare. A parte il mondo mainframe, che ha logiche sue proprie, il problema si pone per molti sistemi di fascia media: pensiamo ad esempio al "caso italiano" dell'AS/400 (ora System i).

Il tema è quello della modernizzazione, termine generico che indica la possibilità di portare a un sistema legacy funzioni e soprattutto modelli operativi più attuali. La modernizzazione ha molte declinazioni, dalla semplice rivisitazione grafica delle applicazioni sino a un vero e proprio salto evolutivo verso un modo diverso di concepire lo sviluppo e la gestione delle applicazioni critiche, in una rivisitazione della loro struttura e dei loro componenti. Considerato in quest'ottica un processo di modernizzazione è evidentemente complesso e deve essere affrontato con una strategia chiara.

Il primo passo è capire quali applicazioni e moduli del sistema legacy non sono più adeguati e per quali motivi. Il database magari non offre funzioni giudicate ora necessarie, l'interfaccia delle applicazioni potrebbe essere ancora il vecchio "green screen", il codice applicativo forse è diventato difficile da manutenere e persino comprendere. Questa fase di valutazione non è solo tecnologica: bisogna identificare anche quali processi di business e quali figure sono coinvolti dai moduli che si vogliono cambiare. La modernizzazione è infatti sempre un processo "pesante" che richiede una buona dose di change management.



Definito l'obiettivo della modernizzazione, come arrivarci? Le opzioni sono molte, a seconda della situazione specifica. Un approccio drastico è la sostituzione integrale - se possibile, il che non è scontato - dei componenti software giudicati inadeguati. C'è poi il rengineering, cioè trasformare la vecchia applicazione in una nuova che abbia le stesse funzionalità ma una concezione più moderna. O la strada più indolore del refactoring: ottimizzare il codice dell'applicazione riducendo al minimo (idealmente a zero) le modifiche viste dall'esterno. O un semplice refacing: aumentare l'usabilità dell'applicazione cambiando la sua interfaccia. Più spesso si capisce che serve una combinazione di questi approcci.

Qualsiasi strada si scelga, è essenziale tenere presente che gestire la modernizzazione come progetto monolitico è quasi sempre troppo rischioso. In fondo si interviene su applicazioni e sistemi che si sono sviluppati nel tempo per i processi critici dell'azienda. Molto meglio scomporre la modernizzazione in tanti piccoli sotto-progetti connessi fra loro, che si possono portare avanti più facilmente. E in una logica di sviluppo agile, anche se sembra poco in linea con il mondo legacy: scomponiamo il problema e affrontiamolo con rilasci frequenti di modifiche, da validare in base a metriche e obiettivi ben precisi.



Le grandi organizzazioni dovrebbero poi procedere non subito alla modernizzazione "finale" dell'applicazione ma passare prima per alcuni proof-of-concept. Questo perché non esiste una strada unica verso la modernizzazione e nemmeno un set limitato di strumenti per farlo: qualche esperimento permette di prendere la mano con le tecnologie a disposizione. È un lusso che le piccole realtà non possono quasi mai permettersi, meglio comunque tenerlo presente.

Proof-of-concept o meno, il passo successivo è dedicarsi alla modernizzazione vera e propria affrontando uno per volta i sotto-progetti che si sono identificati. E badando a costruire una sandbox in cui portarli avanti senza influire sul resto delle operazioni che il sistema quasi certamente starà eseguendo in parallelo. Una volta certi che un sotto-progetto si è completato come volevamo, estendiamo la modernizzazione al componente successivo.