IL Rehosting

Correva l’anno 1997. Vengo chiamato per un’opportunità in una grossa multinazionale dell’Oil & Gas con sede a Firenze, si tratta di migrare un’applicazione da una macchina Perkin Elmer a una macchina Unix. Come scalare l’Everest.

Piano piano la matassa si dipana, arriva il Cobol su Unix e un piccolo gruppo di esperti a venirmi in aiuto. Mi ricordo di moltissimi fine settimana e notti attaccati ai sistemi nel tentativo di far funzionare qualcosa. E alla fine qualcosa funzionava, ma erano i numeri a preoccuparmi. Migliaia di tutto! Vabbè, alla fine siamo andati in produzione, dovevamo farlo a tutti i costi entro quella data. I primi giorni di supporto ricordo di averli fatti senza sosta insieme a una decina di colleghi votati alla causa. Ma alla fine ce l’abbiamo fatta. Ed era soltanto l’inizio! Terminato il primo progetto ne sono arrivati altri 5 molto simili, grazie ai quali abbiamo recuperato i costi del primo progetto. E poi ancora progetti, progetti…

Ma parliamo del rehosting: di cosa si tratta? Ha molti sinonimi tipo downsizing, migration, offloading ecc. Si tratta in pratica di spostare le applicazioni da una piattaforma legacy costosa dal punto di vista operativo, tipicamente il mainframe, a una open assai più economica, mantenendo lo stesso livello di performance e sicurezza. Ma vediamo un attimo quali sono i vantaggi nell’affrontare un progetto di rehosting.

Il vantaggio principale è quello della riduzione dei costi operativi. In casi, ad esempio, di rehosting da mainframe si riesce ad arrivare a risparmi consistenti, tra il 60 e l’80% dei costi operativi. Questo permette di avere dei ritorni di investimento estremamente rapidi che sono importanti per ottenere le approvazioni da parte dell’executive management dell’azienda all’avvio del progetto.

Le prestazioni sono garantite dalla scalabilità della piattaforma target, che garantisce la massima flessibilità soprattutto nel caso in cui si adottasse una soluzione in cloud.

Un altro vantaggio non da poco è la facilità con cui si accede a specifiche tipologie di dati, quelle proprietarie della piattaforma legacy, nel caso si optasse per una trasformazione verso database relazionali.

Il Rehosting di GFT

Cosa caratterizza un progetto di rehosting fatto da GFT? Vediamo a seguito:

• Uso di strumenti di automazione nella trasformazione del codice, che garantiscono qualità e uniformità di intervento
• Strategia di test consolidata con l’uso dei dati reali delle applicazioni
• Facilità di manutenzione applicativa attraverso l’uso di strumenti di produttività esempio Eclipse
• Facilità di integrazione con altri sistemi che magari si trovano già essi stessi su piattaforma open
• Innovazione tecnologica senza impatto sugli utenti finali che non dovranno essere oggetto di formazione
• Ma soprattutto, il mantenimento del valore dei sistemi informativi correnti costruiti con fatica negli anni e che sono cuciti in modo fedele sui processi aziendali.

Rehosting totale/parziale

Il rehosting può essere totale, significa migrare l’intero sistema informativo presente su di un sistema legacy verso piattaforma open.

Oppure può essere parziale, cioè migrarne una parte seguendo uno o più dei seguenti criteri:

• Selezionare all’interno del sistema informativo quali sono le transazioni e i programmi batch che consumano più MIPS e procedere con la loro migrazione. Un esempio può essere rappresentato dalle transazioni più gettonate come lista movimenti o posizione globale in un sistema core bancario
• Anche i motori di calcolo sono possibili obiettivi per un rehosting parziale dato l’elevato consumo di risorse
• Applicazioni autoconsistenti, nel senso che non necessitano di particolare impegno nella realizzazione di interfacce con le applicazioni che magari restano sul sistema legacy
• Un’altra opzione molto gradita è quella di migrare i sistemi di sviluppo e testing, che nel caso di grosse organizzazioni contribuiscono ad un consumo consistente di MIPS. In questo caso deve essere garantito il single source, in modo che sugli ambienti di sviluppo e sugli ambienti operativi non ci sia differenza di codice applicativo
• Ultima delle principali opzioni è quella della consultazione dei dati storici. Questa opzione è estremamente valida quando si migra verso un nuovo applicativo. Il fatto di poter consultare dati storici sul un ambiente rehostato permette di disattivare il sistema legacy e allo stesso tempo di non popolare i nuovi sistemi con tonnellate di dati statici che ne potrebbero pregiudicare le performance

Come inizia per GFT un progetto di Rehosting

Considerate che spesso succede che siamo chiamati a valutare un rehosting senza sapere niente del sistema informativo da migrare. Quindi per noi è fondamentale acquisire il massimo delle informazioni possibili, per poter effettuare una stima realistica di tempi e costi da sottoporre al cliente. Iniziamo quindi un’attività di assessment che normalmente facciamo insieme al fornitore della tecnologia della piattaforma target, attraverso una metodologia consolidata chiamata “Rapid Assessment”. L’output dell’assessment viene analizzato dai nostri esperti che saranno quindi in grado di produrre un business case che comprende, tra l’altro, le seguenti informazioni:

• una pianificazione di alto livello
• Il perimetro del progetto
• I costi del progetto
• Il risparmio ottenuto nei costi operativi
• Il ritorno di investimento e il breakeven espresso in mesi

Questi elementi aiutano il cliente a prendere la decisione di proseguire, o meno, con il progetto di rehosting.

Per ora mi fermo qui, ma spero di aver stuzzicato il vostro appetito… nel prossimo articolo entreremo nel dettaglio delle 6 fasi di un progetto di rehosting. A presto!