Logo ImpresaCity.it

Legacy ma non troppo: affrontare la modernizzazione IT

Milioni di applicazioni critiche si basano su sistemi legacy che sembrano immutabili. Eppure anche questi possono evolvere verso nuovi modelli IT.

Redazione Impresacity

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.

datacenter texas

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.

ibm legacy 702

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.
Pubblicato il: 12/01/2018

Speciali

speciali

Veeam On Forum 2018, il futuro iper-disponibile corre veloce

speciali

Phishing, Ransomware e Truffe E-Mail: è allarme per Office 365 e il cloud