Differenza tra Migrazione parziale e Migrazione completa

Migrazione

In informatica, una migrazione ha luogo tra un sistema esistente o sistema legacy (source) ed uno nuovo (target), dove il primo è un Legacy System ed il secondo è un sistema sviluppato secondo i nuovi paradigmi e tecnologie. Esempi tipici consistono nel migrare da un sistema MVS-IMS-COBOL ad ambienti  UNIX-C++-RDBMS  o WindowsNT-SQLServer, ovvero addirittura ad architetture client/server object oriented (DOC).

La migrazione (migrazione sistema legacy) è un processo altamente rischioso; molti progetti di migrazione in grosse organizzazioni (tipicamente statunitensi) iniziarono nel biennio 1992/93 e nel 1995 quasi l’80% erano fallite, nel senso che erano state ridimensionate, posposte od addirittura completamente cancellate. La scelta di migrare deve quindi essere attentamente valutata considerando che il nuovo sistema target costituirà il perno di tutta la futura strategia aziendale a medio termine; solo con un commitment così forte lo sforzo di migrazione può avere possibilità di successo; infatti spesso uno dei motivi del fallimento è il poco supporto da parte del management, supporto che svanisce alle prime ed inevitabili difficoltà.

Per condurre una migrazione di un sistema legacy ci sono possibili differenti strategie:

1. Migrazione parziale
2. Migrazione completa

Migrazione sistema legacy parziale

Nella migrazione parziale solo una parte del sistema viene trasformata, tipicamente quella che dà i maggiori problemi (alti costi di manutenzione, scarsa flessibilità, ecc.); questa è una soluzione fattibile con rischi contenuti soprattutto per quei sistemi legacy che si sono definiti amichevoli o trattabili; si agisce principalmente sulle interfacce utente o sui dati.

Migrazione delle interfacce utente

Spesso il sistema ha bisogno solamente di presentarsi con un’interfaccia utente migliore: non più quella a caratteri tipica dei terminali 3270, ma una GUI o meglio ancora un’interfaccia Web accessibile da un browser. In molti casi infatti basta “mettere il sistema su Internet” per ottenere già un notevole miglioramento per il business dell’organizzazione (vantaggi economici in quanto si raggiungono nuovi clienti, se l’organizzazione è un’azienda privata, ovvero maggiore offerta di servizi al cittadino se  si parla di PA). La tecnologia offre allora una serie di strumenti di middleware (spesso proprietari) con cui diventa quasi immediato offrire con una nuova veste la vecchia interfaccia sul Web; si tratta degli screen scraper e dei linguaggi di scripting.

Bisogna specificare che:

• Lo screen scraping è un’estensione dell’emulazione di terminale: esso permette alle applicazioni client di simulare la pressione dei tasti e la lettura/scrittura di posizioni specifiche dello schermo, fornendo delle API per tali funzionalità. Allora il browser Web (attraverso CGI) od il nuovo programma GUI chiamano lo screen scraper che a sua volta invoca l’interfaccia utente del vecchio sistema.
• I linguaggi di scripting, utilizzando l’emulazione di terminale, generalmente riescono ad ottenere una certa flessibilità: inviano stringhe di comandi o testo, attendono la risposta e si diramano a seconda dell’output restituito sullo schermo. I comandi del linguaggio di scripting vengono interpretati in fase di run-time anzichè essere precompilati, e questo garantisce la flessibilità, in quanto così l’applicazione client (e non l’utente) riesce a guidare l’interfaccia d’emulazione. Due esempi di linguaggi di scripting sono HLLAPI (High Level Language Application Programming Interface) ed IBM REXX.

Queste tecnologie non richiedono alcun intervento sul Legacy System (e quindi sono applicabili a tutti i tipi di sistemi, anche quelli monolitici), ma soffrono di problemi di prestazioni.

Chiaramente una scelta migliore è quella di sostituire l’interfaccia utente, riscrivendola, ma questo è possibile solo nel caso di sistemi altamente decomponibili o program decomponibili. Esistono comunque dei tool che, partendo dal codice sorgente della vecchia interfaccia, aiutano nel processo di Reverse Engineering e di riscrittura della nuova GUI.

Nella pratica, si adotta un approccio misto, per cui inizialmente, con lo screen scraping, si offre subito la nuova interfaccia (verificandone anche l’accettabilità da parte dell’utente – si fa cioè un prototipo) e nel contempo si comincia la riscrittura.

Alla fine del processo la vecchia interfaccia e lo screen scraper (che quindi si configura come software “usa e getta” per il periodo della migrazione) verranno ritirate.

Migrazione dei dati

La migrazione dei dati consiste nel trasferire i dati da un formato/piattaforma ad un altro. Essa implica la soluzione di molti problemi:

• conversione (ad esempio da database non relazionale a relazionale);
• trasformazione (ad esempio creazione di viste o dati di sommario);
• spostamento (ad esempio da database su mainframe ad uno su UNIX);
• alllocazione (ad esempio da un database centralizzato a più database distribuiti).

La migrazione dei dati in genere è più semplice di quella dell’applicazione, per cui spesso i dati vengono migrati su un database server di cui la vecchia applicazione su mainframe diventa “client”. Inoltre spesso tale database server viene utilizzato anche per il DataWarehousing, nel caso che l’organizzazione abbia in progetto un intervento di questo tipo.

Esistono varie tecnologie di supporto alla migrazione dei dati, di complessità, potenza e disponibilità differenti:

• Database Unload/Reload Utilities: forniscono la possibilità di scaricare i dati in un formato piatto (come un file sequenziale) che possa poi essere ricaricato dal database target. Tutti i DBMS, compresi quelli legacy, offrono questa possibilità, ma i rispettivi formati di fatto sono incompatibili tra fornitori differenti, o non funzionano bene nel caso in cui il paradigma dei dati sia differente (gerarchico sul source e relazionale sul target), per cui spesso è necessario scrivere codice di supporto ad
• Tools di Conversione Automatica: tentano di automatizzare la conversione dei dati da un formato ad un altro. Grandi sforzi, sia della ricerca che del mondo commerciale, si sono orientati nella conversione dal modello IMS a quello relazionale, per cui esistono tool per la migrazione da database IMS a Se è necessario scrivere del codice, esistono dei generatori di programmi che partendo dalle specifiche sul modello dei dati, sull’ambiente source e target, ecc. (fornite tipicamente attraverso programmi GUI su workstation) producono i programmi necessari in C o COBOL per molte tipologie di archivi. Questi tool sono molto utilizzati anche nel campo del DataWarehousing, da cui nascono come idea.
• Data Propagators, Replication Servers e Gateways: considerato che la migrazione è graduale nel tempo, forniscono dei servizi necessari durante il periodo di transizione: trasparenza per le applicazioni su dove sia effettivamente allocato il dato (sul source o sul target), sincronizzazione tra i due ambienti, trasparenza di distribuzione nel caso che il database target sia distribuito, ecc. L’effettiva disponibilità sul mercato è limitata e le funzionalità offerte spesso sono parziali, per cui può essere necessario un pesante lavoro di sviluppo in proprio.

Comunque la problematica della migrazione dei dati non interessa solo il contesto del trattamento dei Legacy System, ma abbraccia molti altri settori, primo fra tutti quello del DataWarehousing e la disciplina delle Basi di Dati in generale.

Migrazione sistema legacy completa

La migrazione completa consiste nell’approccio Mainframe unplug (ritiro).

Quest’ultimo approccio è valido per molte piccole e medie organizzazioni, che decidono di passare da un mainframe di medie dimensioni a piattaforme basate su AS/400 o server Unix. In questi casi sostanzialmente si prende il sistema (cioè le applicazioni che lo costituiscono) e lo si ricompila con  piccole modifiche nel nuovo ambiente (questo processo è chiamato sliding o rehosting); esistono buoni tool che supportano questo processo (ad esempio per passare da codice MVS-CICS allo stesso codice per Unix-AIX). Chiaramente questo approccio è conveniente se il sistema è già ben progettato (presenta livelli software con interfacce ben definite) e l’obiettivo è quello di ottenere maggiori economie passando ad un hardware  meno costoso e sul quale sia poi più facile un intervento d’integrazione con le tecnologie DOC.

Bisogna dire inoltre che, una migrazione completa del Legacy System è un processo che può richiedere anni e presentare rischi notevoli; proprio per questo l’approccio graduale mantiene costantemente operativo il vecchio sistema e nel contempo sviluppa, con piccoli passi incrementali, le varie porzioni del nuovo fino a che la sostituzione globale (obiettivo pianificato a lungo termine) non venga raggiunta. Ogni passo richiede un impiego di risorse relativamente basso (pochi anni-uomo e poco tempo): si produce così un piccolo risultato nella direzione dell’obiettivo (un incremento) ed un controllo del rischio, in quanto se un passo dell’approccio graduale fallisce, deve essere ripetuto solo quello, con spese decisamente più contenute e benefici per tutti i passi successivi ad esso correlati, che non vanno rivisti, ma direttamente progettati in base ad una versione già corretta. L’aspetto fondamentale per una migrazione graduale di successo è l’individuazione della dimensione e indipendenza degli incrementi, la loro sequenzializzazione e correlazione.

A tal proposito è utile continuare con la lettura del prossimo articolo circa le Tipologie di migrazione nei sistemi Legacy.