1.1 Che cosa è un Legacy System

/
(*$&<
6
<67(0
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;
/
(*$&<
•
6
<67(0
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
6
<67(0
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
/
(*$&<
6
<67(0
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
6
<67(0
/
(*$&<
6
<67(0
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].
/
(*$&<
6
<67(0
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
/
(*$&<
6
<67(0
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
/
(*$&<
6
<67(0
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
/
(*$&<
6
<67(0
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:
/
(*$&<
•
6
<67(0
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, è
/
(*$&<
6
<67(0
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
/
(*$&<
6
<67(0
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.
/
(*$&<
6
<67(0
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;
/
(*$&<
•
6
<67(0
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
/
(*$&<
6
<67(0
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:
/
(*$&<
6
<67(0
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.
/
(*$&<
6
<67(0
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.
/
(*$&<
6
<67(0
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
/
(*$&<
6
<67(0
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
/
(*$&<
6
<67(0
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.
/
(*$&<
6
<67(0
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
/
(*$&<
6
<67(0
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:
/
(*$&<
6
<67(0
•
Fornire la gestione del protocollo di connessione a differenti livelli;
•
Ottenere la traduzione dei dati e processare le informazioni a differenti livelli;
•
Implementare una qualche sorta di meccanismo di "error recovery";
•
Gestire l'ambiente nativo del sistema legacy;
•
Implementare nuove interfacce che rientrino in una specifica più generale.
Nello sviluppare un wrapper, si possono assumere approcci differenti, che
chiaramente conducono a soluzioni e risultati piuttosto doversi (soprattutto per quel
che riguarda il livello d’astrazione ottenuto e l’efficacia dell'integrazione).
Un primo atteggiamento, è quello opportunistico di cercare di riusare il vecchio
sistema il più possibile ed in modo facile: è l'uso dell'applicazione che guida il
disegno del wrapper e l'obiettivo del wrapping è solamente quello di esportare
l'interfaccia dell'applicazione nel nuovo ambiente (tipicamente il Web). S’identifica
una transazione legacy particolarmente significativa, anche dal punto di vista
dell'utente finale, e si offre sul Web attraverso un semplice wrapper. Un componente
server accetta in input una stringa formattata secondo il tracciato record della
transazione e riporta l'output sempre come stringa. In pratica il componente non fa
altro che rendere accessibile il tracciato record della transazione nel nuovo ambiente,
ed il client deve occuparsi dello spacchettamento, non essendoci trasparenza
rispetto alla logica legacy. Non si vogliono aggiungere nuove funzionalità, ma
rendere disponibile la vecchia applicazione nel nuovo ambiente; il punto di partenza,
quindi rimane la specifica del vecchio sistema: si risponde alla domanda di come
riuscire ad esportare il sistema nel nuovo ambiente e non di come riuscire ad
integrarlo, che porta a vedere l’incapsulamento in un'ottica molto differente.
/
(*$&<
6
<67(0
Esportare, infatti, significa modificare il sistema senza realmente determinare come
contribuisce alle necessità complessive dell'organizzazione e che ruoli copre
nell'architettura informativa; ci si focalizza sulla correzione delle deficienze del
sistema e sul suo miglioramento rispondendo alle necessità di business a breve
tempo.
Integrare, invece, significa considerare il sistema ed i dati nel contesto del business e
dell'architettura informativa. Il principale difetto di questa strategia, che si potrebbe
definire di semplice accesso al legacy, è la stessa struttura del sistema legacy nel
nuovo sistema, in particolar modo nel caso in cui il nuovo sistema è distribuito: le
applicazioni legacy non sono state disegnate per essere blocchi componenti o per
funzionare in modo modulare con altre, quindi le interfacce che saranno esportate
non aderiscono ad una strategia di distribuzione. Un altro problema, è la necessità
del nuovo applicativo di conoscere il tracciato record della transazione: tale
condizione dovrebbe essere un pre-requisito da rimuovere nel modo più assoluto (in
linea di principio non dovrebbe essere sviluppato dagli stessi che hanno sviluppano il
legacy). Una strada alternativa più corretta, che si potrebbe definire integrazione
basata sugli oggetti, è quella che prima costruisce il nuovo dominio e poi determina
l'insieme delle funzioni dell'applicazione legacy che lo occuperà: così facendo,
probabilmente sarà sufficiente solo una piccola frazione di quanto il sistema legacy
può fare, perché non è necessario esportare ogni interfaccia (molte saranno
nascoste dietro al nuovo modello ad oggetti). La specifica degli oggetti è guidata
dalle nuove necessità dell'organizzazione, piuttosto che dai vincoli del legacy
compilati nelle proprie interfacce.
Questa strategia, invece di partire in modo bottom-up per cercare di recuperare il più
possibile, fa un'analisi come se dovesse costruire il nuovo sistema da zero (top-
/
(*$&<
6
<67(0
down) e solo dopo vede cosa si può "riciclare" dal legacy, minimizzando
l'esposizione delle sue limitazioni. Inizialmente si esegue un'analisi e si genera un
nuovo modello ad oggetti, identificando in particolare le interfacce dei vari
componenti; poi si popolano queste ultime incapsulando le specifiche funzionalità del
sistema legacy.
Nella realtà progettuale non si può procedere puramente top-down, ma è necessario
comunque inserire dei momenti bottom-up; comunque quello che caratterizza
quest'approccio non è tanto il processo, bensì il fatto che alla fine il risultato è un
modello ad oggetti che complessivamente incapsulano il legacy System; non si
riesce ad identificare dove sia effettivamente il wrapper di una specifica transazione
(non c'è più un mapping 1:1, perché le informazioni riportate da una specifica
transazione sono distribuite su differenti oggetti cooperanti) ma il wrapper è il
modello stesso (o meglio l'insieme degli strati software che complessivamente
espongono questo modello).
1.3.3.2 Le tecnologie di supporto
Le tecnologie di supporto all’effettiva costruzione dei wrapper, note anche come
tecnologie di mediazione, sono un gruppo di tecnologie che mascherano ai livelli
sovrastanti tutti i dettagli della tecnologia legacy. Esse possono essere raggruppate
in due grandi categorie:
•
Tecnologie d 'accesso, che forniscono la possibilità di connessione remota (un
esempio di tale tecnologia sono i gateway, cioè i convertitori di protocollo, che ad
esempio permettono di passare da socket TCP/IP a SNA LU6.2);
•
Tecnologie object/web based, che consentono di offrire una visione di più alto
livello, appoggiandosi su quelle precedenti e permettono di avere interfacce
/
(*$&<
6
<67(0
object oriented, ovvero d'integrare le risorse legacy direttamente in un ambiente
Web.
A seconda di dove queste tecnologie vanno ad collocarsi sul vecchio sistema, si
possono avere differenti paradigmi (che comunque devono trovare un corrispettivo
nella tipologia del sistema legacy, in termini di decomponibilità):
•
RDA (Remote Data Access): permette di accedere direttamente al servizio dati;
•
RFA (Remote Function Access): consente di richiamare direttamente le funzioni
legacy;
•
RPA (Remote Presentatioli Access): permette di richiamare i servizi di
presentazione del sistema legacy.
Un elenco di tecnologie d'accesso può allora comprendere:
•
Database Gateways: un database gateway fa apparire locale un database
remoto ed interrogabile in modo standard. Il paradigma è RDA;
•
Application Gateways: utilizzando il paradigma RFA un application gateway
permette di richiamare procedure legacy remote;
•
Screen Scraping: utilizza il paradigma RPA.
Esempi di tecnologie object/web based sono invece:
•
Prodotti proprietari che permettono lo sviluppo di componenti Web (C
GI o servlet Java) che accedono direttamente all'host;
•
Prodotti che permettono lo sviluppo di componenti che accedono all'host
presentando un'API O-O verso l'estemo.
/
(*$&<
6
<67(0
Indipendentemente dal modo usato per accedere al Legacy System, queste
tecnologie risolvono in modo abbastanza immediato solo il problema di costruire
wrapper d'accesso; per costruire un modello di wrapping ad oggetti, deve essere
sviluppato uno strato software (più o meno esteso, a seconda delle situazioni) che
offra all'esterno il modello ad oggetti ed utilizzi questi wrapper di più basso livello per
farlo. Quindi tutto lo strato che si estende, in pratica, dal punto di accesso al vecchio
sistema, fino al modello ad oggetti incluso, è quello che viene chiamato wrapper ad
oggetti.
1.3.4
L’esclusione
Quest’approccio non è praticabile nella realtà, se non quando il sistema legacy è
facente parte di una logica di business aziendale che deve essere abbandonata
entro poco tempo.
/
(*$&<
6
<67(0