MAINFRAME MIGRATION: INDRODUZIONE

I sistemi di informazione sono stati adottati dalle imprese alcuni decenni fa e da allora sono sempre stati utilizzati.

Di conseguenza, dal punto di vista operativo, la maggior parte delle aziende si affida a sistemi obsoleti e non aggiornati. Questi sistemi sono noti come sistemi legacy. Esempi ben noti sono i sistemi COBOL con oltre 200 miliardi di linee operative ancora in funzione in tutto il mondo. Inoltre, poiché gli obiettivi e il contesto delle imprese variano, nel tempo questi sistemi hanno subito delle modifiche che richiedono un adattamento per le imprese. Ad esempio, al giorno d'oggi è impossibile concepire una banca che non offra servizi di Home Banking, ma la maggior parte dei sistemi bancari sono stati originariamente scritti in COBOL. Pertanto, è comune trovare una tecnologia vecchia di 50 anni, come COBOL, che affianca le più moderne tecnologie, come .Net, AJAX o JEE, nella stessa impresa.

Come risultato di questa situazione, le imprese devono affrontare costi elevati per il mantenimento dei loro sistemi. Questo è principalmente dovuto al fatto che questi sistemi di solito funzionano su mainframe che devono essere affittati. Inoltre, vi è la necessità di assumere sviluppatori specializzati in vecchie tecnologie per aggiornare le funzionalità del sistema, che è sia costoso che piuttosto difficile.

Prendendo in considerazione questi fatti, molte aziende optano per la modernizzazione dei propri sistemi legacy utilizzando una tecnologia più recente. Questo processo è chiamato migrazione.

Attualmente, uno dei paradigmi di riferimento più comune per migrare i sistemi legacy è SOA (Service-Oriented Architecture). In SOA, i sistemi sono costruiti utilizzando funzionalità indipendenti chiamate servizi che possono essere richiamati in remoto. I servizi sono offerti come funzionalità indipendenti dalla piattaforma che possono essere utilizzati dal sistema al di fuori dell'organizzazione. Per garantire l'indipendenza dalla piattaforma, le tecnologie dei servizi Web sono il modo più comune di implementare i sistemi SOA poiché il primo si basa su noti protocolli Internet, come SOAP e HTTP. Pertanto, la migrazione dei sistemi legacy alle tecnologie dei servizi Web è una pratica abbastanza comune. Tuttavia, non esiste una ricetta standard per migrare efficacemente i sistemi legacy in SOA.

La letteratura recente propone che un sistema legacy possa essere migrato seguendo due approcci.

Il primo approccio, chiamato migrazione diretta, consiste nel disporre un sistema legacy con un livello software che espone i programmi di sistema originali come servizi Web. Questo approccio è noto per essere economico e veloce, ma ha lo svantaggio che il sistema legacy non viene sostituito da uno nuovo. Invece, l'azienda ottiene due sistemi per mantenere: un sistema legacy e il suo strato SOA appena costruito.

D'altra parte, l'approccio chiamato migrazione indiretta si basa sulla re-implementazione del sistema legacy utilizzando una piattaforma moderna. Questo approccio è costoso e richiede tempo poiché non solo il sistema dovrebbe essere re-implementato e ri-testato, ma anche in alcuni casi la logica aziendale incorporata nel sistema legacy dovrebbe essere decodificata. Ciò accade perché la documentazione di sistema potrebbe essere stata persa o non aggiornata. L'analisi della migrazione indiretta non è in nessun caso una versione migliore del sistema, ma anche una documentazione aggiornata per riferimento futuro.

Dal punto di vista SOA, un'importante differenza tra migrazione diretta e migrazione indiretta è la qualità della frontiera SOA che è l'insieme di servizi Web esposti ai potenziali consumatori a seguito della migrazione di un sistema legacy. La qualità di frontiera della SOA è un fattore molto importante per il successo di un sistema SOA perché, come illustrato nella Figura 1, la frontiera SOA viene utilizzata sia per i registri dei servizi che per i consumatori. I registri dei servizi utilizzano la frontiera SOA per i servizi di indicizzazione e, quindi, consentono agli utenti del servizio di cercarli. Al contrario, i consumatori di servizi hanno bisogno della frontiera SOA per comprendere e invocare i servizi. E un successo del sistema SOA può essere misurato dal numero di utenti del servizio che ha. Ciò è tuttavia ignorato dalla maggior parte delle imprese poiché la migrazione diretta è per natura il modo meno costoso e più veloce di derivare una frontiera SOA da un sistema legacy, ma tale frontiera SOA è comunemente una semplice rappresentazione "Internet-ready" di interfacce di programma di sistema originali, che non sono state progettate con le migliori pratiche di progettazione SOA o addirittura concepite per essere utilizzate da terze parti come essenzialmente i servizi Web.

 

fig1 art1 mainframe

Invece, un progetto di frontiera SOA è comunemente avvantaggiato dalla nuova implementazione dei programmi di sistema originali durante la migrazione indiretta.

Per ottenere un migliore compromesso tra costi e qualità di frontiera SOA, abbiamo sviluppato un nuovo approccio di migrazione con qualità simile a quello ottenuto con la migrazione indiretta, ma basato su una migrazione indiretta.

Il nostro approccio, denominato migrazione assistita, esegue quest'ultima da un sistema legacy mediante migrazione diretta, analizzando poi delle possibili azioni di refactoring per aumentare la qualità della frontiera SOA. Sebbene questo approccio non rimuova il sistema legacy, riteniamo che la frontiera SOA ottenuta possa essere utilizzata come punto di partenza per la sua re-implementazione. Pertanto, una tale frontiera SOA attenua la sostituzione del sistema perché non cambia quando il sistema legacy viene sostituito da quello nuovo.

Per valutare la fattibilità della migrazione assistita, abbiamo utilizzato uno studio di caso che coinvolge un sistema COBOL in cui sono state applicate la migrazione diretta e la migrazione indiretta. Questo sistema è di proprietà della più grande agenzia governativa argentina e gestisce i dati relativi a quasi tutta la popolazione argentina.

Il sistema è stato migrato in primo luogo utilizzando l'approccio di migrazione indiretta a causa di linee guida decise. Dal momento che la  qualità della frontiera della migrazione principale non era idonea per gli sviluppi, la società ha deciso di eseguire una seconda migrazione. In questo caso, l'approccio di migrazione indiretta è stato utilizzato per migliorare la qualità della frontiera SOA. Avendo questi due tentativi di migrazione, abbiamo applicato l'approccio alla migrazione assistita alimentandolo con la versione di migrazione diretta del sistema originale. Quindi, abbiamo confrontato le tre frontiere SOA ottenute in termini di costi, tempi e qualità.

Secondo questa analisi, il nostro approccio produce una frontiera SOA quasi equivalente a quella della migrazione indiretta, ma a un costo simile a quello della migrazione diretta.