Il Rehosting – episodio 2

Riprendo l’argomento trattato durante il primo episodio sul tema Rehosting. Eravamo rimasti al punto di definire quali possano essere le fasi progettuali di un tipico progetto di rehosting. Vediamole qui di seguito:

DESIGN – Una volta terminato l’assessment, viene sottoposta al cliente una stima economica che ha un buon livello di accuratezza. Il cliente a questo punto dovrà assumere la decisione se procedere col progetto di rehosting e, in tal caso, si inizia con la fase di Design. Tale fase viene avviata attraverso incontri tra i nostri architetti e il personale tecnico / architetturale del cliente, al quale vengono sottoposte soluzioni anche sotto forma di eventuali alternative da scegliere sulla piattaforma target. L’output della fase di design è una serie di deliverable contenente tutti i dettagli tecnici implementativi del progetto. Questi deliverable saranno in continua evoluzione, essendo possibile incontrare problematiche specifiche di minore impatto, che non sono state rilevate durante la fase di assessment.

POC – La fase successiva, opzionale, è quella della POC. Opzionale in quanto molti dei nostri clienti accettano di bypassarla perché la tecnologia oggi disponibile per i progetti di rehosting è altamente affidabile e può contare su molte referenze di successo. In ogni caso, la POC viene normalmente richiesta nel caso di situazioni particolari dove prima di intraprendere l’intero progetto il cliente ha necessità di verificare qualità della migrazione e performance della piattaforma target.

TRASFORMATION – L’altra fase, sempre opzionale, ma spesso necessaria, è quella di trasformazione. La trasformazione è un processo critico in un progetto di rehosting, dati i numeri in gioco. È per questo che GFT, negli anni, si è dotata di una serie di strumenti di trasformazione che permettono l’implementazione automatica di regole di conversione, garantendo velocità (economicità), uniformità e qualità del codice prodotto. Per parlare dei vantaggi della conversione automatica, una volta riscontrata una casistica di errore è possibile agire sui convertitori e rigenerare tutto nuovamente. In questo caso, tutti gli errori della stessa tipologia saranno automaticamente corretti. Non male, no? Durante questa fase il software oggetto di migrazione viene reso disponibile sulla piattaforma target pronto per essere eseguito. Una prima fase di test viene effettuata per verificare la correttezza del setup dell’ambiente di esecuzione.

TESTING – Si prosegue con quella che considero la fase più importante del progetto, il testing. Qui parliamo di una metodologia di test estremamente collaudata, che permette di raggiungere livelli di affidabilità pressoché totali. Si introduce il concetto di test comparativo tra i risultati del sistema origine con i risultati del sistema di destinazione. Comparazione effettuata mediante strumenti di mercato o che ci siamo costruiti durante i progetti di rehosting. Per citare un esempio, abbiamo dovuto correre ai ripari sul test comparativo di tabelle di un database relazionale in quanto lo strumento che avevamo acquisito restituiva i risultati dopo 2 giorni, vista la mole di dati in gioco. Abbiamo quindi deciso di sviluppare un sistema basato su big data che restituiva gli stessi risultati in 15 minuti e abbiamo potuto terminare il progetto nei tempi concordati. La fase di testing vede un coinvolgimento delle risorse applicative del cliente che ovviamente detengono la conoscenza del funzionamento del software da testare. Tratteremo in modo approfondito il tema testing in una sezione specifica dell’ultimo episodio.

ROLL-OUT – Una volta effettuati i test e riallineato il software con le ultime change fatte nel frattempo dal cliente, passiamo al go-live. Naturalmente anche il go-live viene provato e riprovato. Di solito mettiamo in piano almeno tre test di go-live, dove vengono trasferiti i dati mediante script che dovranno diventare completamente automatici, e dove misuriamo i tempi di esecuzione del trasferimento – caricamento, per trovare soluzioni nel caso in cui i tempi fossero incompatibili con le esigenze di business.

SUPPORT – Subito dopo il go-live iniziamo con il supporto dedicato – una volta era on-site ora è remoto causa forza maggiore – dove lo stesso personale che si è occupato del progetto di rehosting è a disposizione nel caso in cui fosse necessario intervenire per qualsiasi ragione. Normalmente questo supporto dedicato dura un mese, al quale seguono 5 mesi di supporto on-call per un totale di sei mesi di garanzia.

Mi fermo qui ma spero di incontrarvi nuovamente quando parlerò delle varie tipologie di roll-out e di approfondimenti sul tema testing oltre ad altre cose nel terzo e ultimo episodio… A presto!