LEGACY SYSTEM 1.1 Che cosa è un Legacy System Nella letteratura sono state proposte diverse definizioni di legacy system; dall analisi del termine legacy ( qualcosa di valore ricevuto dal passato ), si può considerare la seguente definizione: Un sistema (o applicazione) legacy è un sistema (o applicazione) informativo esistente da anni, che è di valore per il business da esso supportato, e che è stato ereditato dall'ambiente elaborativo attuale. In questa definizione, bisogna approfondire il significato dei termini valore e ereditato dal passato. Il primo è il riferimento alla logica di business dell organizzazione: quanto più la logica è insostituibile, tanto più il valore del sistema aumenta. Il secondo termine vuole indicare generalmente che il sistema che si prende in considerazione è già operativo, da almeno cinque anni. Le caratteristiche fondamentali di un legacy system sono: È un sistema mission-critical, cioè è fondamentale per l operatività dell organizzazione ed è costantemente utilizzato; Su di esso l organizzazione ha pesantemente investito nel corso degli anni, e quindi non può essere semplicemente accantonato così com è; È di grosse dimensioni, centinaia di migliaia di linee di codice, distribuite su migliaia di programmi;
Il suo nucleo risale ad un decennio fa ed è quindi progettato secondo vecchie concezioni; Può essere scritto in linguaggi di vecchia generazione, supportare DBMS obsoleti ed avere un interfaccia utente non grafica; Non è ben documentato ed è difficile da comprendere, poiché la documentazione non è aggiornata con le modifiche che via via sono state apportate; Il sistema è considerato come il repository di funzionalità aziendali non esplicitamente documentate. Molte applicazioni sviluppate negli anni 70 e 80 possono essere senz altro considerare esempi di Legacy System. Si tenga presente, che le caratteristiche sopra menzionate, possono essere caratteristiche anche d applicazioni di recente realizzazione. Un esempio estremo di sistema legacy è data da un espressione del tipo ogni applicazione che non sia sviluppata con tecnologie attuali è legacy. Questo per ribadire che quando si parla di Legacy System non bisogna pensare ad un dinosauro morente. 1.2 Tipologie di Legacy System I sistemi e le applicazioni legacy, dalla prospettiva del trattamento, possono essere classificati come:
1) Altamente Decomponibili: sono ben strutturati e presentano alcune caratteristiche fondamentali: a) I componenti applicativi sono separabili in logica di presentazione, logica applicativa e logica d accesso ai dati, cioè il software è composto di tre livelli logici; b) I moduli applicativi sono indipendenti tra loro; c) I moduli applicativi hanno interfacce ben definite con i servizi di database, quelli di presentazione e le altre applicazioni; 2) Data decomponibili: sono i cosiddetti semistrutturati con le seguenti caratteristiche fondamentali: a) I componenti applicativi sono separabili in due livelli: i servizi d accesso ai dati e quelli di presentazione e logica applicativa fusi in un solo blocco; b) I moduli applicativi hanno interfacce ben definite verso le altre applicazioni. In questi sistemi è possibile accedere direttamente ai dati, ma non alla logica applicativa. 3) Program decomponibili: sono anch essi semistrutturati con le seguenti caratteristiche fondamentali: a) I componenti sono separabili in due livelli: i servizi di presentazione e quelli di accesso ai dati e logica applicativa fusi in un unico blocco; b) I moduli applicativi hanno interfacce ben definite verso le altre applicazioni.in questi sistemi non è possibile accedere direttamente ai dati, ma necessario
invocare delle funzioni predefinite (tipicamente una transazione).in questa categoria rientrano la maggior parte delle applicazioni legacy; 4) Monolitici (non strutturati): sono i sistemi in cui tutti i componenti appaiono come un unico blocco in cui tutti i livelli logici fusi insieme.generalmente a questi sistemi si può accedere solo attraverso l invocazione da interfaccia grafica. Molte applicazioni in realtà hanno un architettura che è una combinazione di queste quattro. Dal punto di vista della facilità di trattamento, i Legacy System possono essere distinti in: Ostili: sono quelli che non permettono la possibilità d interfacciamento con l esterno; Trattabili: l interfacciamento con altri sistemi è possibile con un certo sforzo di programmazione e tecnologie a hoc; Amichevoli: l interfacciamento con altri sistemi è facilmente fattibile. Risulta evidente che i sistemi del primo tipo sono amichevoli, quelli data/program decomponibili sono trattabili, mentre quelli dell ultimo tipo sono ostili.
Fig. 0-1 Tipologie di Legacy System
1.3 Trattamento dei Legacy System Fino a qualche tempo fa l unica attività operativa legata in particolar modo ad un sistema Legacy era la manutenzione, sia evolutiva, sia correttiva. L elevato costo della manutenzione per questi sistemi, ha però portato, negli ultimi tempi, alla valutazione di possibili alternative per il trattamento dei sistemi Legacy: Esclusione: si esclude il sistema da ogni successivo sviluppo. È una soluzione non praticabile se il sistema contiene un alto valore Sostituzione Netta: si riscrive il sistema completamente da zero. Può essere valida se il sistema non è mission-critical. Migrazione graduale: si opera una trasformazione del sistema in maniera graduale. Integrazione: si consolida il sistema nelle sue funzionalità e si effettua il wrapping [cfr. par. 1.3.3.1] con tecnologie ad hoc. Tra queste si può fare una prima distinzione a seconda se l obiettivo sia la sostituzione con un nuovo sistema, o il mantenimento di gran parte del sistema opportunamente adattato con nuovi servizi e nuove tecnologie. Questo, ovviamente dipende dal valore che l azienda attribuisce al sistema, in termini di servizi forniti e criticità. Ultimamente si sta diffondendo una procedura differente, che può essere in parte considerata come un evoluzione dell approccio di sostituzione incrementale: l integrazione dei Legacy System basato sulle tecnologie abilitanti della Distributed Object Computing [cfr. Cap 2].
Fig. 0-2 Trattamento dei Legacy System Nella pratica, anche se si cerca di mantenere uno o l altro approccio di trattamento, spesso non si ha una netta distinzione applicativa; l utilizzo di approcci validi per il raggiungimento dello scopo, può contenere metodologie dell uno o dell altro approccio. 1.3.1 Sostituzione Netta: Approccio Cold Turkey Per sostituzione netta s intende la riscrittura dell intero sistema legacy, utilizzando metodologie, tecniche e tecnologie moderne. Quest approccio comporta però dei grossi rischi: Le esigenze dell organizzazione non stanno ad aspettare: lo sviluppo di un sistema richiede anni, e nel frattempo emergono nuovi bisogni informativi per l organizzazione ed in base a loro il legacy viene modificato; è evidente che deve modificato anche il nuovo sistema. Il rischio è in questa continua modifica durante lo sviluppo. Esistono raramente delle specifiche: talvolta la sola documentazione per il sistema è il codice stesso ed inoltre spesso tale codice è altamente specifico ( per motivi di prestazioni) per una macchina su cui è o era destinato a girare; ne
consegue che è molto difficile ricostruire le specifiche. Inoltre c è il problema delle dipendenze non documentate: inevitabilmente nel corso degli anni varie applicazioni, critiche o meno, si sono appoggiate alò sistema per informazioni o servizi; se questo va riscritto sarebbe auspicabile trovare queste informazioni da qualche parte, per non far saltare l operatività di tante applicazioni di contorno; spesso non c è una chiara consapevolezza di ciò e l individuazione è assai difficile. Il sistema legacy può essere troppo grande perché interrompa il suo accesso ai dati: molti sistemi devono essere operativi al 100% del tempo, mentre il travaso dei dati dal vecchio al nuovo sistema richiede settimane per essere attuato: spesso i dati, non solo devono essere travasati, ma anche ripuliti, controllati nella loro qualità e convertiti per aderire al nuovo sistema; inoltre, se il legacy dataserver non fornisce funzioni di download e l accesso ai dati avviene attraverso il sistema stesso, aumenta ancora di più il tempo di scaricamento degli stessi. In ogni caso si tratta di tempi che non sono compatibili con le esigenze dell organizzazione. La gestione di grandi progetti è rischiosa: il vecchio sistema ha un adimensione tale che costruire l equivalente dal nulla, corrisponde ad un progetto di grandissime dimensioni. Progetti di tali dimensioni hanno altissime probabilità di fallimento: sono generalmente sottostimati molti fattori, quali la complessità di ripartizione del lavoro, di formazione del personale di sviluppo e di gestione, etc. Tutto ciò non fa che aumentare le paure e le incertezze legate a quest approccio; se a questo si aggiunge la naturale indisposizione del management dell organizzazione a reinvestire tutto quello che ha gia investito per decenni, per avere un sistema con
le stesse funzionalità, ma con nuove tecnologie, si arriva all impraticabilità del processo, tanto che le organizzazioni preferiscono il tranquillo dinosauro legacy. 1.3.2 La Migrazione Una migrazione avviene tra un sistema esistente, detto souce, ed uno nuovo, detto target, dove il souce è tipicamente un sistema legacy ed il target è un sistema sviluppato secondo nuovi paradigmi e tecnologie. Per condurre una migrazione sono possibili differenti strategie: Migrazione parziale. Migrazione completa. 1.3.2.1 Migrazione parziale. Solo una parte del sistema viene trasformata, tipicamente quella che da maggiori problemi (alti costi di manutenzione, scarsa flessibilità, etc.); questa è una soluzione fattibile con rischi contenuti soprattutto per quei sistemi legacy del tipo amichevole o trattabile. Si agisce principalmente sulle interfacce utenti o sui dati. 1.3.2.1.1 Migrazione delle interfacce utenti 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. Si parla in questo caso di revamping, vale a dire effettuare un operazione di ripulitura della parte esterna del sistema, e quindi l interfaccia utente, lasciando il più possibile inalterato il cuore del sistema. In molti casi, infatti, basta mettere il sistema su internet per ottenere già un notevole miglioramento per il business dell organizzazione, in quanto si offrirebbe lo stesso servizio, ma raggiungibile più facilmente da molti utenti. La tecnologia offre allora una serie di strumenti midleware con cui diventa quasi immediato offrire con
una nuova veste la vecchia interfaccia sul Web; si tratta degli screen scraper, emulatori di terminali, con cui si permettono alle applicazioni client di simulare la pressione dei tasti e la lettura/scrittura di posizioni specifiche dello schermo fornendo delle interfacce per le funzionalità. Questa tecnologia non richiede alcun intervento sul sistema legacy, 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. Nella pratica si adotta un approccio misto, quindi inizialmente, con lo screen scraping, si offre subito la nuova interfaccia e nello stesso tempo si comincia la riscrittura delle nuove interfacce. Al termine della scrittura di queste ultime, le vecchie interfacce e quelle intermedie ottenute dallo screen scraping, sono eliminate. 1.3.2.1.2 Migrazione dei dati La migrazione dei dati consiste nel trasferire i dati da una piattaforma ad un altra. Quest operazione, implica la soluzione di molti problemi: Conversione: ad esempio si passa da un database non relazionale a relazionale; Trasformazione: ad esempio creazione di nuove viste; Spostamento: ad esempio da un database su mainframe ad uno su UNIX; Allocazione: ad esempio da un database centralizzato ad uno distribuito. Esistono varie tecnologie di supporto alla migrazione dei dati, di complessità, potenza e disponibilità differenti:
Database Unload/Reload Utilities: sono utilità offerte dai DBMS, anche quelli legacy, che permettono di scaricare i dati in un formato piatto, come un file sequenziale, che è ricaricato dai DBMS target. I problemi nascono solo dal formato del file o del paradigma differente (ad esempio da DMBS source gerarchico a DBMS target relazionale); sono facilmente superabili con apposite routine scritte ad hoc. Tools di conversione automatica: tentano di risolvere i problemi di tipo generale, quale la conversione da un formato gerarchico ad uno relazionale. Possono includere editor per eventuali programmi d integrazione per risolvere quei problemi tipici del singolo caso. Data Propagators, Replication Servers e Gateway: forniscono strumenti per la migrazione graduale, nel periodo di transizione. L effettiva disponibilità sul mercato è limitata dalle funzionalità che offrono; anche in questo caso risulta necessario un pesante lavoro di sviluppo per programmi ad hoc. 1.3.2.2 Migrazione completa Una migrazione completa del sistema legacy è un processo che può richiedere anni e presentare rischi notevoli; proprio per questo l approccio graduale mantiene costantemente operativo il vecchio sistema e allo stesso tempo sviluppa, con piccoli passi incrementali, le varie porzioni del nuovo fino a che la sostituzione non sia totale (obiettivo di lungo termine). Ogni passo richiede un impiego di risorse relativamente basso, in termini di impiego di risorse e di tempo: riproduce così un piccolo risultato nella direzione dell obiettivo ed un controllo del rischio, in quanto se un passo fallisce, deve essere ripetuto solo quello, con riduzione di spese e di tempo contenute. L aspetto fondamentale per una migrazione graduale di successo, è
l individuazione della dimensione e indipendenza degli incrementi, la loro sequenza e correlazione. 1.3.2.3 Uno strumento: i gateway La migrazione graduale seleziona e sostituisce parti del vecchio sistema per diventare parti del sistema target incrementalmente costruito. Durante questo processo i due sistemi formano un sistema composito, che complessivamente implementa le funzionalità mission-critical. Nel sistema composito, souce e target sono connessi da un gateway, cioè da un modulo software introdotto tra i vari componenti operativi, per mediare tra loro. I ruoli fondamentali di un gateway sono: Isolare determinati componenti dagli effetti dei cambiamenti sugli altri: un gateway mantiene l interfaccia che il souce si aspetta da un determinato componente, che è stato sostituito o modificato, oppure isola un componente che non è stato ancora modificato dal resto del sistema target; Traduttore di richieste e dati: un gateway traduce richieste in un formato standard per servire sia moduli legacy sia target; Coordinatore tra i componenti per mantenere la consistenza nelle interrogazioni e degli aggiornamenti: è possibile che i dati o le funzioni che implementano l interrogazione o l aggiornamento, siano stati parzialmente o completamente decomposti in componenti del source e migrati in componenti target; inoltre ci possono essere copie replicate di dati e funzioni. Il gateway deve allora decomporre correttamente la forma di accesso nelle sue sottoforme da presentare alla funzione o ai dati opportuni e poi raccoglierne ed integrarne gli effetti con coerenza e consistenza; il compito più difficile dal punto di vista della
coordinazione riguarda gli aggiornamenti e può essere dominato solo con tecnologie database avanzate. Una volta individuato il problema nella specifica situazione, poiché esistono pochi gateway commercialmente disponibili validi, l unica soluzione è sviluppare applicazioni dedicate. Il posizionamento di un gateway è un fattore critico per la complessità di una migrazione: Database gateway: il gateway può essere messo tra i moduli applicativi ed i servizi database, incapsulando l intero database rispetto alle applicazioni; Fig. 0-3 Posizionamento Gateway : DataBase Gateway Application gateway: il gateway può essere messo tra lo strato di presentazione e il resto del sistema; System gateway: il gateway può incapsulare l intero sistema.
Fig. 0-4 Posizionamento Gateway: Application Gateway Fig. 0-5 Posizionamento Gateway: System Gateway In genere, più in alto è posizionato il gateway, più funzionalità deve incapsulare e più risulta complesso. Da un punto di vista strutturale, un gateway ha due componenti fondamentali utili durante la migrazione: Forward gateway permettono alle applicazioni legacy di accedere ai dati nella parte target del sistema;
Riverse gateway permettono alle applicazioni target di accedere ai dati nell ambiente legacy. 1.3.2.4 Architetture per la migrazione I sistemi altamente decomponibili sono i più facili da migrare: ogni componente ha interfacce ben definite e quindi può gradualmente essere sostituito durante il processo di migrazione. Questo può procedere secondo due direzioni od un misto delle due: Migrare il database legacy per primo, e successivamente migrare la logica applicativa e quella di presentazione. Le tecnologie e le tecniche sono quelle utilizzate nel caso della migrazione parziale dei soli dati; il gateway in questo caso è un "forward database gateway". Migrare il database legacy per ultimo, dopo che si è migrato la logica di presentazione e quell'applicativa. Questo è particolarmente valido quando la necessità fondamentale è quella di offrire un'interfaccia più moderna e nuove funzionalità di business, oppure quando il database è troppo grande per essere migrato all'inizio. Il gateway è di tipo "reverse database gataway". Nella pratica sono utilizzati contemporaneamente entrambe le strategie, per cui il gateway presenta sia funzionalità di forward che reverse. Le stesse strategie possono essere utilizzate anche nel caso di sistemi data decomponibili, anche se il passo di migrazione delle logiche applicative e di presentazione è più complesso. Per i sistemi program decomponibili (e questa è la stragrande maggioranza dei casi concreti), il gateway deve incapsulare tutta la logica sottostante rispetto a quella di presentazione, e si presenta come un application gateway. Per questo tipo di sistemi
possiamo o migrare prima la logica di presentazione (reverse gateway) o migrare prima il resto del sistema (forward gateway). Nel caso di sistemi monolitici, il gateway diventa un sistema un system gateway, attraverso cui devono passare tutte le richieste d'accesso al sistema (sia richieste di utenti che di altri sistemi), ed esso le smista al nuovo o vecchio sistema. Chiaramente questo tipo di gateway è abbastanza complesso da costruire ed il caso più difficile e rischioso da affrontare. 1.3.2.5 Una metodologia: l'approccio Chicken Little L'approccio Chicken Little è una metodologia di migrazione incrementale che si basa sulla migrazione per piccoli passi successivi finché non è raggiunto l'obiettivo finale. Ogni passo di migrazione può essere agevolmente dimensionato alle risorse di cui l'organizzazione dispone per la sua esecuzione. Piccoli passi di migrazione producono risultati specifici e non stravolgono l'ambiente di lavoro; sia il management aziendale, sia gli utenti del sistema legacy sono più disposti a collaborare per il successo del singolo passo di migrazione. Inoltre, si può controllare il rischio scegliendo la dimensione del passo di migrazione; minore è l'incremento di migrazione, minore è il rischio d'insuccesso, ma minore è anche il vantaggio che se ne può trarre. Nell'approccio, ogni passo di migrazione deve riguarda un aspetto specifico della migrazione. Si può avanzare, contemporaneamente, con più passi purché questi riguardino aspetti indipendenti del sistema legacy. In caso di insuccesso di un passo di migrazione, solo quest'ultimo è ripetuto. Ci sono quattro principali fasi iniziali di un progetto di migrazione secondo l'approccio Chicken Little:
1. Ridurre la quantità di dati e funzioni del sistema legacy. Molti dati possono essere duplicati, nei files o nei databases del sistema legacy, e molte porzioni di codice possono essere ripetute nei vari moduli applicativi. I moderni DBMS relazionali risolvono il problema della ridondanza dei dati, così anche alcune funzioni che li elaborano possono essere, di conseguenza, inutili: minori sono i dati utili non dupicati, minore è lo sforzo delle loro gestione e maggiore è l'efficienza della loro elaborazione. 2. E' impossibile dettagliare tutte le fasi del progetto se, fin dall'inizio, si sa che il completamento del progetto richiederà alcuni anni. Le ragioni di tale impossibilità sono almeno due: Il sistema legacy è troppo grande e/o convoluto per poterlo analizzare nei dettagli per intero; alcuni di questi saranno scoperti solo quando il sistema legacy è già parzialmente migrato. Uno o più cambiamenti dei requisiti commerciali possono richiedere l'introduzione di nuove funzionalità nel sistema legacy. Pertanto si sviluppa un progetto di alto livello relativo all'intera migrazione e poi, su richiesta dell'organizzazione, si sviluppa un progetto dettagliato del singolo passo di migrazione. 3. Si progetta l'ambiente target usufruendo delle nuove tecnologie HW e SW. L'ambiente target deve essere flessibile, cioè portabile, per rendere il sistema target adattabile alle modifiche che il progresso tecnologico e i cambiamenti dei requisiti aziendali impongono per rimanere competivi.
4. Si progetta il "framework" di migrazione includendo il sistema legacy, il sistema target e il sistema composito (tipicamente dei gateway). In questa fase devono essere presi in considerazioni le interfacce, le funzioni e i dati. Anche in questo caso si dettaglia una porzione del progetto d'alto livello solo quando l'organizzazione è pronta ad affrontarlo. I passi di migrazione dell'approccio Chicken Little sono i seguenti: 1. Analisi incrementale del sistema legacy. 2. Decomposizione incrementale della struttura del sistema legacy. 3. Progetto incrementale delle interfacce target. 4. Progetto incrementale delle applicazioni target. 5. Progetto incrementale del DB target. 6. Installazione incrementale dell'ambiente target. 7. Creazione ed installazione incrementale dei gateway necessari. 8. Migrazione incrementale del DB legacy. 9. Migrazione incrementale delle applicazioni legacy. 10. Migrazione incrementale delle interfacce legacy. 11. "Cut - Over" incrementale al sistema target.
Fig. 0-6 Passi di una migrazione Chicken Little Dalla figura 6 risulta chiaro che esiste la possibilità di far avanzare parallelamente alcuni passi di migrazione in ogni incremento. Specificamente i passi etichettati con 1, 3, 4, 5, 6 possono compiersi contemporaneamente. Il passo 2 (decomposizione del sistema legacy), presuppone che sia già completo il passo 1 (analisi del sistema legacy relativamente al corrente incremento di migrazione). Il passo 7 può procedere parallelamente ai.passi 8, 9 e 10 solo dopo aver concluso i passi da 1 a 6. Solo al termine dei 10 passi si effettua il passo finale 11. 1.3.2.5.1 Descrizione dei passi dell'approccio Chicken Little Descriviamo i passi dell'approccio: 1. Analisi incrementale del sistema legacy. Il primo passo per la migrazione di un sistema legacy è capire quali sono le sue funzioni, come sono realizzate, quali
legami esistono fra loro, quali sono quelle critiche, etc. Nella maggioranza dei casi non esiste documentazione d'alcun genere relativa alle fasi alte di progetto del sistema e, se esiste, non è aggiornata. Quindi il sistema legacy deve essere sottoposto ad un processo di reverse engineering per avere delle rappresentazioni del sistema ad un livello d'astrazione più alto. Poiché è impossibile raggiungere una dettagliata conoscenza del sistema, occorre focalizzarsi soltanto su alcuni aspetti del sistema e rimandare l'approfondimento degli altri incrementi ai successivi incrementi di migrazione. 2. Decomposizione incrementale della struttura del sistema legacy: si effettuano modifiche al sistema per assicurarsi che sia decomponibile; individuate le dipendenze tra le interfacce, le applicazioni ed i dati, si eliminano. Queste modifiche sono necessarie, possono però incidere negativamente sulla prestazione del sistema stesso. E' bene non dedicare troppe energie per le suddette modifiche perché i "moduli legacy" saranno sostituiti. 3. Progetto incrementale delle interfacce target. Premettendo che le interfacce, sia di sistema sia utente, sono tanto importanti in un sistema quanto lo sono le applicazioni ed i servizi di gestione dei dati, occorre effettuare il progetto e la pianificazione della strategia di migrazione delle interfacce e decidere se usare un gateway. 4. Progetto incrementale delle applicazioni target. Premesso che le applicazioni saranno in esecuzione sulla piattaforma target, devono essere progettate secondo le business rules che l'ambiente target deve supportare. Le applicazioni target o sono derivate da un reengineering del sistema legacy o sono fornite da prodotti SW commerciali che dimostrano di soddisfare, in modo congruo, gli
stessi requisiti soddisfatti dalle applicazioni legacy. I rischi di questo passo sono aumentati dalla quasi immancabile richiesta che nuovi requisiti siano soddisfatti. 5. Progetto incrementale del DB target. Il nuovo sistema avrà un DBMS relazionale (molto probabilmente distribuito oppure object oriented) per elaborare e memorizzare i dati. Innanzi tutto si deve scegliere tra i vari prodotti commerciali simili e, quando il DBMS è stato scelto, progettare lo schema relazionale soddisfacente i requisiti dei dati coinvolti nell'incremento di migrazione. Il punto cruciale di questo passo di migrazione è che le applicazioni legacy racchiudono le definizioni dei dati; solitamente, esse sono distribuite in tutto il codice dell'applicazione legacy. La ricerca delle definizioni dei dati è complicata dal probabile aliasing e quella del significato e dell'utilità dalle cattive pratiche di naming. Attualmente esiste la tendenza, accentuata dal paradigma di programmazione object oriented, a racchiudere la definizione dei dati e I'implementazione delle funzioni che li manipolano in specifici moduli SW. 6. Installazione incrementale dell'ambiente target. I requisiti che il nuovo sistema deve soddisfare, determinano i requisiti dell'ambiente target. In effetti, è meglio identificare l'ambiente target indipendentemente dai requisiti per evitare di ottenere una soluzione troppo specifica alla realtà organizzativa dell'impresa. La vera intenzione è di avere un sistema target flessibile, in primo luogo, che debba soddisfare i nuovi requisiti. 7. Creazione ed installazione incrementale dei gateway necessari. Questo è il passo in cui si avvertono maggiormente le sfide poste dalla migrazione. Il tipo di gateway che deve essere realizzato (o comprato, se si trova in commercio quello che soddisfa i requisiti) dipende dall'architettura del sistema legacy.
8. Migrazione incrementale del DB legacy. La quantità di dati e le funzionalità operative del sistema legacy impediscono la migrazione complessiva di tutti i dati. Dopo aver installato il DB scelto nel passo 5 e prima di memorizzare i dati dal DB legacy, i dati devono essere vagliati per eliminare quelli inutili (tra questi quelli ridondanti). Questo passo è effettuato con l'ausilio di gateway per supportare le chiamate delle applicazioni legacy. Data l'enormità di dati, se si scegli un approccio incrementale, si complicano le funzionalità del gateway. 9. Migrazione incrementale delle applicazioni legacy. Sono 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 legacy. Usando criteri analoghi a quelli del passo precedente, sono selezionate e migrate nel nuovo ambiente una o più interfacce legacy. La selezione avviene in coordinazione con quella delle applicazioni. Per il resto valgono le considerazioni del punto precedente. 11."Cut-Over" incrementale al sistema target. Il termine "cut-over" indica il processo con cui si passa da uno stato, nel quale le operazioni sono fatte ancora dal sistema legacy, a quello in cui sono fatte direttamente dal sistema target. Poiché i moduli target possono essere pronti mesi e, forse anche, anni prima che il sistema target sostituisca del tutto il legacy, si possono avere problemi di gestione di configurazione e controllo della versione. I singoli passi di questo processo possono essere incrementali, riducendo ulteriormente i rischi di un eventuale taglio netto del singolo passo. Quando nessun
elemento del sistema legacy è più operativo, il sistema e il suo ambiente saranno eliminati. 1.3.3 Integrazione Integrare significa usare il sistema e i dati legacy nel più ampio contesto del business e della sua architettura informativa. L'obiettivo principale è ottenere la logica di business, i processi e le informazioni del sistema legacy, senza l'importare da questo le tecnologie e metodologie del passato. L'integrazione nasconde (incapsula) il sistema legacy dietro interfacce consistenti, che si riferiscono ai processi di business, nascondendo i dettagli implementati e facendo cooperare il sistema con gli altri sistemi dell'organizzazione, soprattutto con quelli d'ultima generazione. Per ottenere questo, si decompone il sistema in componenti detti "sevices based" e si partizionano i processi di business in domini distinti ma cooperanti. Per ripartire il sistema legacy, è necessario capirne il contenuto e quindi implementare delle interfacce astratte che rendono i domini e i processi disponibili agli altri. 1.3.3.1 I wrapper Il concetto di wrapper è semplice: si tratta di un livello di software che nasconde l'implementazione effettiva delle funzionalità del legacy e le presenta attraverso uninterfaccia ben definita; quest'ultima è tipicamente ad oggetti, in modo che all'esterno il sistema legacy appaia con una veste nuova di più oggetti, simili ad altri oggetti (nuovi) e operanti nello stesso ambiente, accettando e rispondendo con gli stessi messaggi degli altri oggetti come se fossero nuovi. In questo modo, poiché le applicazioni legacy implementano i processi fondamentali di business, il wrapper ad oggetti alza il livello d'astrazione al livello d'oggetti di business, permettendo una facile integrazione con il resto del nuovo sistema. I requisiti di un buon wrapper sono: