Application Modernization (AM) significa modernizzazione delle applicazioni che risiedono sui sistemi legacy. L’argomento non è banale: considerando come a fare la differenza del business siano l’intelligenza e l’elasticità del software, è oggi un tema centrale della governance. Le nuove regole dello sviluppo consentono addirittura di ottimizzare l’infrastruttura hardware, arrivando in molti casi a bypassare i limiti delle architetture e delle memorie. Ma cosa succede se le applicazioni in uso sono scritte in linguaggio diventati obsoleti? Possono essere riscritte? Possono essere semplicemente migrate alle loro versioni aggiornate? Possono essere sostituite da altre applicazioni di ultima generazione?
Application Modernization: qual è il ruolo nella catena del valore
La prima cosa da sapere di un progetto di application modernization è perché farlo. L’obiettivo, infatti, è creare nuovo valore aziendale dalle applicazioni esistenti. Il punto di partenza è l’analisi. Dal momento che un’applicazione è un programma progettato per eseguire una funzione specifica a supporto di uno o più utenti (o a supporto di un altro programma applicativo), bisogna capire se è più opportuno mantenere le applicazioni legacy nel medio e nel lungo termine oppure no. Farlo ha senso, perché gli utenti si sono abituati a gestire i programmi in modalità fluida ma il cambiamento comporta rallentamenti e curve di apprendimento che possono impattare nell’immediato sul business. Questo è il motivo per cui si tende a tergiversare. Ma nell’era 4.0 anche i mainframe devono essere in grado di fregiarsi del titolo 4.0. Allora l’Application Modernization diventa necessaria, specialmente quando il software diventa così obsoleto da diventare incompatibile con le versioni più recenti del sistema operativo (SO) sottostante o dell’hardware di sistema utilizzato dall’organizzazione. Per quanto comprensibile, il processo può risultare dispendioso in termini di tempo e risorse, considerando anche il fatto che in molte applicazioni legacy il flusso di lavoro dei processi aziendali è codificato e strettamente associato ad altri aspetti del codice legacy.
Come fare Application Modernization
Trasferire facilmente le applicazioni da qualsiasi piattaforma hardware storica, indipendentemente dal linguaggio con il quale sono stati sviluppati i programmi e senza perdere le loro caratteristiche funzionali è il primo step di una più ampia strategia di modernizzazione dei sistemi in chiave service oriented. La questione è l’infrastruttura di partenza: il mainframe, infatti, ancora oggi è l’ambiente di riferimento per un numero consistente di aziende. Sinonimo di solidità, affidabilità, elevate prestazioni e sicurezza, il mainframe ha però un limite nei suoi costi di gestione (Tco) che sono superiori a sistemi più economici che, quanto a prestazioni, non hanno nulla da invidiare al mainframe (Unix e Linux in primis). Le alternative, dunque sono due: riscrivere il codice oppure fare re-hosting.
1) Riscrittura del codice
I metodi tradizionali per l’Application Modernization includono la riscrittura del codice dell’applicazione esistente (tradizionalmente scritta in COBOL) in un linguaggio di programmazione più moderno e compatibile con il Web di nuova generazione(come Java e le sue derivazioni) , o lo sviluppo di un’interfaccia Web che si integra a un’applicazione obsoleta, andando a recuperare parti dell’applicazione legacy che potrebbero ancora avere un valore.
2) Re-hosting
Un secondo metodo per fare Application Modernization è il cosiddetto re-hosting, che permette di non intervenire sul linguaggio perché il Cobol rimane Cobol, mentre l’applicazione viene semplicemente trasferita ai nuovi ambienti. Il re-hosting, tecnicamente, è il porting di una o più applicazioni legacy, fino all’intero sistema, verso ambienti open e standard (Microsoft, Unix, Linux) senza che vi siano riconversioni o riscritture dei codici sorgenti e, soprattutto, senza che le applicazioni mission critical subiscano modifiche funzionali. In sintesi, è possibile sfruttare la capacità del linguaggio Cobol (ancora oggi presente nell’80% delle applicazioni mission critical delle aziende) di evolversi ed essere portato da un sistema a un altro con grande flessibilità e adattabilità, evitando interventi di riscrittura delle applicazioni (limitati a casi eccezionali in cui è necessaria una significativa revisione funzionale dell’applicazione con passaggio in toto, per esempio, da Cobol a Java).
Perché il re-hosting è una scelta tattica e strategica
Il re-hosting non è solo una scelta tattica. In una chiave di lettura strategica va visto come il primo passo da compiere per reingegnerizzare il parco applicativo non solo spianando la strada a sistemi e metodi più flessibili e più agili ma abilitando gli ambienti mainframe al mondo delle Service Oriented Architecture (SOA), dei Web Services e del Cloud. La buona notizia per chi si occupa di governance aziendale è che è possibile attuare il re-hosting in tempi limitati, migrando le applicazioni senza modifiche strutturali del codice, senza cambiarne le funzionalità e il front-end verso l’utente. Per poterlo fare in modo veloce e, soprattutto, automatico, la tecnologia offre validi tool che consentono di trasferire facilmente le applicazioni da qualsiasi piattaforma hardware storica, indipendentemente dal linguaggio con il quale sono state sviluppate, dai database e dagli Oltp in uso.
Esistono diversi provider che offrono attività di re-hosting. Le aziende devono ascoltare bene la tipologia dell’offerta e del servizio. Gli esperti suggeriscono di orientare le proprie scelte a chi fornisce strumenti che consentono ai team preposti di poter riutilizzare, aggiungere o modernizzare facilmente le applicazioni mainframe senza rischi, nella garanzia di mantenere la continuità operativa del business e senza costi aggiuntivi legati alla necessità di dover effettuare successive modifiche.
