Mainframe re-hosting: scelta tattica in chiave strategica

Trasferire facilmente le applicazioni da qualsiasi piattaforma hardware storica, indipendentemente dal linguaggio con il quale sono state sviluppate e senza perdere le proprie caratteristiche funzionali, non è solo una soluzione tattica guidata dall’esigenza del risparmio dei costi. È, piuttosto, il primo step di una più ampia strategia di modernizzazione dei sistemi in chiave “service oriented”.

Pubblicato il 01 Dic 2010

Sinonimo di solidità, affidabilità, elevate prestazioni e sicurezza, il mainframe è l’ambiente ancora oggi installato in un numero consistente di aziende il cui costo di gestione (Tco), però, fa i conti con sistemi più economici che, quanto a prestazioni, non hanno nulla da invidiare al mainframe (Unix e Linux in primis).
Esistono poi problemi legati, nello specifico, alle tecnologie legacy quali l’obsolescenza, la carenza di skill e la difficoltà di integrazione con le nuove tecnologie, oltre che di natura più business, ossia legati alla necessità di continuare a soddisfare le esigenze dell’azienda, preservando il know-how accumulato nel parco applicativo e il livello di servizio offerto.
Motivi per cui negli ultimi cinque anni sono molte le aziende che hanno preso in considerazione la migrazione del proprio parco applicativo da mainframe ad ambienti standard che garantiscono una significativa riduzione dei costi operativi con lo stesso livello di servizio dei sistemi proprietari basati su mainframe e, oggi, anche le performance elaborative e l’alta affidabilità dei sistemi.
La migrazione del parco applicativo può avvenire in due differenti modi: la riscrittura delle applicazioni (ridefinizione del codice; per esempio, passando da Cobol a Java) o il re-hosting (nessun intervento sul linguaggio; il Cobol rimane Cobol, l’applicazione viene semplicemente trasferita).
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.
Il re-hosting, di fatto, sfrutta 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.

Da un punto di vista strategico, la riscrittura delle applicazioni avrebbe la priorità laddove come unico must ci fosse la revisione in chiave “business service oriented” del parco applicativo; dato però che scenari simili sono piuttosto rari e a incidere maggiormente sono esigenze di riduzione dei costi con scelte che abbiano il minor impatto possibile e con un Roi tangibile in poco tempo, il re-hosting diventa una soluzione tattica i cui effetti positivi si ripercuotono su: costi (bassi rispetto alla riscrittura delle applicazioni), tempi (mesi per il re-hosting; anni per la riscrittura), impatto sull’esistente (medio per il re-hosting; alto per la riscrittura), Roi (mesi per il re-hosting; anni per la riscrittura).
Ma non è solo una questione tattica, il re-hosting ha una sua chiave di lettura strategica dato che rappresenta il primo passo possibile per l’ammodernamento del parco applicativo e per l’apertura a sistemi più flessibili e agili. In altre parole, il re-hosting è uno dei primi step per l’evoluzione dei sistemi verso i nuovi paradigmi architetturali dell’It (Soa, Web Services, Cloud).

Dalla teoria alla pratica
Le perplessità però non mancano e il processo evolutivo da mettere in pratica non è così lineare come nella teoria. Il primo ostacolo è dato dalla mancanza di prevedibilità, o meglio, dalla difficoltà di delineare un preciso percorso che traghetti il sistema It su una nuova piattaforma tecnologica, potendone valutare tempi, spese e rischi. Analizzare le singole problematiche non è un problema; la complessità si ha nella definizione di un piano chiaro, che riesca a identificare la via più corretta ed equilibrata tra esigenze di innovazione, mantenimento della qualità e riduzione dei costi.
La questione non è “se” abbandonare il mainframe ma “come” poterlo fare.
Nella maggior parte dei casi, come abbiamo sopra delineato, la risposta più opportuna è il re-hosting inteso come spostamento “as is” delle applicazioni su nuove piattaforme, cambiandone il meno possibile struttura e codifica e lasciandone inalterate funzionalità e interfacce.
Il re-hosting, di fatto, risulta la scelta pratica ideale laddove le applicazioni sono ancora performanti e in linea con le necessità aziendali, sposando perfettamente esigenze altrettanto pratiche come il contenimento di costi e rischi, la tutela del know-how e del livello di servizio.
Oggi è 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. Con gli appositi strumenti, si possono trasformare le applicazioni in modo evolutivo e con bassi rischi, massimizzando il riuso delle applicazioni esistenti. Le principali funzionalità dei tool in commercio, solitamente, includono:
– la ricompilazione delle applicazioni Cobol per porle in esecuzione su qualsiasi sistema operativo;
– la disponibilità di server di emulazione del Cics (Customer Information Control System: monitor di gestione transazioni che opera sui sistemi mainframe) per eseguire in ambienti distribuiti applicazioni inizialmente concepite per operare sui mainframe;
– le componenti per esporre e riutilizzare la logica applicativa nelle architetture orientate ai servizi;
– la possibilità di integrare componenti Cobol con i Framework .NET e J2EE;
– i tool per aggiungere interfacce grafiche basate su Web ai sistemi esistenti.

Perché il re-hosting
Con il re-hosting si può beneficiare fin da subito di un forte abbattimento dei costi di gestione dei sistemi (escludendo i costi di manutenzione applicativa i risparmi possono arrivare fino all’80%); i tempi di elaborazione si riducono notevolmente (in alcuni casi anche del 90%) e si sfruttano fin da subito i vantaggi degli ambienti più moderni che garantiscono eccellenti funzionalità di supporto e rendono disponibili, con maggiore efficienza, tutte le funzionalità di servizio precedentemente presenti su mainframe (il tutto senza che l’utente si accorga di nulla).
C’è poi tutta una serie di vantaggi indotti come quelli derivanti dalla maggior efficienza degli ambienti di sviluppo e test, una miglior facilità di integrazione tra tecnologie, nonché quelli legati alla minor complessità di gestione dei sistemi: il re-hosting, di fatto, riduce o annulla i tempi di ri-addestramento del personale It e degli utenti che, in genere, non si accorgono del passaggio dato che interfacce e funzionalità rimangono le stesse.

Valuta la qualità di questo articolo

La tua opinione è importante per noi!

Articoli correlati