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.