Framework per la migrazione completa di un sistema informatico

Framework per la migrazione completa di un sistema informatico

La migrazione completa di un sistema informatico è un’operazione molto vasta che richiede un notevole impegno di risorse; ne segue che ogni sforzo deve essere opportunamente calibrato.

Framework per la migrazione completa di un sistema informatico
Framework per la migrazione completa di un sistema informatico

Come prima cosa, nel disegno di un progetto di migrazione completa, va effettuata una riduzione delle funzioni e dei dati da trasferire nel sistema target: molte funzionalità e dati ormai vecchi, potrebbero non essere, o essere solo parzialmente, necessari per il nuovo sistema informativo. Poiché il costo di una migrazione si può considerare esponenziale rispetto alla dimensione del sistema, è essenziale contenere le spese ed i rischi riducendo il materiale non critico per le esigenze aziendali. Queste considerazioni e la semplificazione del sistema vanno ripetute per ogni passo incrementale della migrazione.

La progettazione globale deve essere effettuata senza alcun tipo di vincolo e in un certo numero di passi: è impensabile che si possa progettare efficacemente in dettaglio una migrazione che si realizzerà in anni di lavoro; qualsiasi cosa va realizzata incrementalmente, anche il disegno.

Per guidare la migrazione, va comunque delineato un progetto generale, che non deve scendere nei particolari per non diventare anacronistico rispetto alle esigenze informative nel momento in cui si passa alla realizzazione; è ogni singolo incremento che deve essere accuratamente disegnato. Il disegno dell’ambiente del target deve essere il più possibile aperto e flessibile, per far sì che si possa, in futuro, cambiare qualsiasi cosa senza che si abbia un impatto negativo sul sistema: è una esigenza che nasce dall’osservazione dei continui cambiamenti del business. Ad ogni passo non viene completato il disegno complessivo del sistema, ma piuttosto viene risviluppato un disegno di alto livello sulla migrazione, che tiene conto dei nuovi aspetti emersi; si crea quindi un disegno  di dettaglio dell’incremento da migrare. Ad esempio verrà progettato uno schema dati globale, fino al livello di repository (data server, contenitori generici) o se necessario a livello di macroentità e qualche relazione fondamentale.

Un aspetto importante del disegno globale è quello che riguarda la progettazione del framework della migrazione: il source, il target ed il sistema composito, con la convivenza delle componenti legacy e non. Vengono mappate in questa fase i vecchi moduli in nuovi, dal punto di vista dell’ambiente, delle interfacce esterne, delle applicazioni e dei servizi database.

Framework metodologico per la migrazione completa

Una proposta metodologica per gestire tutte queste problematiche è dovuta a Brodie e Stonebraker. Il loro framework metodologico consta di undici passi che comportano piccole migrazioni locali nella direzione prefissata e gestite con un aspetto specifico: più indipendenti sono questi passi, maggiore è la flessibilità del metodo rispetto alle particolari esigenze informative e tecnologiche.

I gateway sono uno degli strumenti fondamentali della migrazione, poiché incapsulano componenti che devono essere cambiati dietro interfacce standard (non da modificare). Inoltre i passi non devono procedere necessariamente in sequenza: la loro successione può cambiare, alcuni possono essere parallelizzati, altri possono essere fusi in un unico, dipendendo dalle particolarità del sistema da migrare. Il framework è cioè estremamente flessibile ed adattabile alle necessità dell’organizzazione.

La riduzione dei rischi è uno degli obiettivi fondamentali della metodologia: da una parte la si cerca fornendo un punto di ritorno sicuro per ogni passo, che non metta in pericolo tutto il progetto, dall’altra il rischio stesso di ogni singolo passo va dimensionato opportunamente.

Gli 11 passi del framework metodologico sono qui di seguito descritti:

  1. Analisi incrementale del sistema Legacy: è importante che si comprenda il sistema in un giusto livello di dettaglio e si compiano progressi nell’approfondimento dei requisiti lungo una specifica direzione prestabilita: procedere senza un obiettivo preciso può paralizzare l’analisi. Spesso i requisiti iniziali sono ormai inesistenti o non attuali, ed è necessario il più delle volte operare un reverse engineering per ricostruirli, dopodiché in realtà si finisce per sviluppare le specifiche del vecchio e del nuovo sistema informativo.
  2. Decomposizione incrementale dell’architettura del sistema Legacy: si effettuano modifiche al sistema per assicurarsi che sia decomponibile; vengono quindi rimosse le dipendenze tra i moduli, come le chiamate di procedura, e si ispeziona l’esistenza di interfacce ben definite tra moduli e servizi database. Il costo di questo passo dipende dalla struttura del vecchio sistema, e se non è possibile ristrutturarlo possono comunque essere adottate e studiate varianti del metodo.
  3. Disegno incrementale delle interfacce esterne del Target System: si effettua il disegno e la specifica delle interfacce esterne (utente ed applicative) del nuovo sistema con una effettiva pianificazione della migrazione delle stesse. Tipicamente le interfacce esterne saranno eseguite sulle macchine client del nuovo ambiente
  4. Disegno incrementale delle applicazioni del Target System: le applicazioni che vanno sviluppate per il nuovo sistema vanno progettate in base ai processi dell’organizzazione ed a volte tagliate sulle vecchie applicazioni dopo una fase di reengineering.
  5. Disegno incrementale del database del Target System: si disegna lo schema entità- relazioni del nuovo sistema basandosi sui risultati delle fasi precedenti e sulla comprensione dei sistemi target e legacy. A meno che non si tratti di requisiti insoliti, è bene poi mapparlo su un RDBMS basato sull’SQL. Questo passo può essere anche molto comp lesso per via del codice legacy o dei requisiti delle applicazioni: può essere difficile derivare la struttura dei dati legacy, tipicamente distribuita su tutta l’applicazione.
  6. Installazione incrementale dell’ambiente del Target System: si identificano i requisiti dell’ambiente target sulla base dei requisiti globali, quindi si seleziona l’ambiente stesso ed lo si testa in modo approssimativo per ricavarne informazioni sulle performance ed altro. Dopodiché viene installato, possibilmente in un ambiente distribuito, il che dovrebbe facilitare la costruzione di programmi GUI e l’alleggerimento del codice distribuendolo opportunamente tra server e client.
  7. Creazione e installazione incrementale dei gateway necessari: vengono sviluppati e installati i gateway in base alle esigenze delle applicazioni (è probabile che si renda necessaria la costruzione di più gateway) e tenendo conto delle funzionalità, della posizione architetturale e dei requisiti non funzionali. A questo punto si presenta l’alternativa del make or buy, dato che esistono diversi prodotti commerciali che offrono alcune di queste funzionalità.
  8. Migrazione incrementale del database del sistema Legacy: viene implementato lo schema disegnato al passo 5 ed effettuata la migrazione del legacy database con l’ausilio del gateway per supportare le chiamate delle applicazioni legacy. Questa operazione comporta una notevole quantità di lavoro, che può essere affrontato anch’esso incrementalmente, complicando le funzionalità del gateway.
  9. Migrazione incrementale delle applicazioni del sistema Legacy: vengono selezionati e fatti migrare uno o più moduli, secondo criteri tecnici ed organizzativi (semplicità, costi, priorità), sviluppandoli in modo tale che possano interagire direttamente con il nuovo DBMS.
  10. Migrazione incrementale delle interfacce esterne del sistema Legacy: vengono selezionate e fatte migrare una o più interfacce esterne. Se viene utilizzato un  4GL per supportare lo sviluppo di interfacce utente ed applicazioni, la  relativa migrazione può essere coordinata e le interfacce esterne del Target System  gireranno direttamente su un ambiente 4GL/GUI, mentre le altre rimanenti continuano a convivere con esse.
  11. Distacco incrementale verso il Target System: il distacco (cutover) consiste nel processo di switch dalle componenti del sistema Legacy alle corrispondenti del Target System; spesso è accompagnato da problemi di gestione della configurazione e controllo della versione. In pratica, Il processo di migrazione richiede il controllo delle versioni più avanzate  e  la  gestione della configurazione del sistema composito, il che è evidentemente più complesso rispetto al caso della realizzazione di un sistema ex novo: man mano che la configurazione si evolve dal suo “stato” legacy a quello target, la gestione deve adeguarsi abbandonando la concezione legata al vecchio sistema per affrontare quella del nuovo con la continuità necessaria a gestire il transitorio. E’ fondamentale che durante il processo di migrazione la gestione della configurazione produca due essenziali risultati:
    • il controllo delle versioni di codice più avanzate sviluppate su piattaforme multiple, considerando tutto il codice (dalle applicazioni, alle interfacce, al linguaggio di definizione dei dati, a quello di manipolazione, ecc.).
    • la produzione di documentazione di supporto per il sistema composito, intendendo con questo che mentre i vari componenti evolvono separatamente la documentazione per l’utente deve evolversi incrementalmente di pari passo.

Bisogna dire inoltre che un grande fattore di rischio per l’approccio del taglio netto è che il momento in cui entra in funzione il nuovo sistema, può essere drammatico se il sistema in realtà si presenta non all’altezza della situazione. Nel caso dell’approccio graduale, invece, il cutover viene attuato in modo incrementale, seguendo le singole esigenze locali del sistema. In realtà ognuno dei passi descritti potrebbe avere una sua fase di distacco, ma la dimensione e la complessità del sistema Legacy spesso giustificano un passo a parte completamente dedicato alla coordinazione necessaria per il complesso lavoro di sostituzione delle componenti che coinvolge, per grandi organizzazioni, centinaia di siti, centinaia di utenti, centinaia di moduli legacy e target riguardanti i database, le applicazioni e le interfacce esterne. Si può pensare quindi ad una fase di distacco separata dalle altre, realizzata essa stessa in modo incrementale, come pure può essere una ottima scelta quella di procedere in parallelo tra la fase di distacco di alcune componenti e quella di sviluppo di altre.

 

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *