Definizione di Sistema Legacy (Legacy System)

Secondo il Webster si definisce legacy “something of value received from an ancestor or predecessor or from the past” (“qualcosa di valore ricevuto da un antenato o predecessore o dal passato”). Quindi si assumerà la seguente definizione: un sistema (applicazione) legacy è un sistema informativo (applicazione) di valore ereditato dal passato. I concetti fondamentali sono appunto di valore (cioè critico per il business dell’organizzazione) e ereditato dal passato (generalmente 5 anni o più, comunque già operativo nel momento in cui lo si prende in considerazione).

I Legacy System o sistemi Legacy sono anche definiti come “grandi sistemi software con cui non si vorrebbe avere a che fare ma che sono vitali per l’organizzazione” [Bennet], “ogni applicazione in produzione” [Schick] e “ogni sistema informativo che resiste alle modifiche ed evoluzioni necessarie per tener dietro ai nuovi e mutevoli requisisti di business dell’organizzazione” [Brodie].

Le caratteristiche fondamentali di un Sistema Legacy sono:

• È un sistema fondamentale per l’operatività dell’organizzazione; inoltre spesso è pesantemente utilizzato (migliaia di transazioni al giorno) essendo mission-critical e dovendo quindi rimanere operativo al 100% e 24 ore su 25.
• Su di esso l’organizzazione ha pesantemente investito nel corso degli anni, e quindi non può essere semplicemente accantonato così com’è.
• E’ enorme (centinaia di migliaia o milioni di linee di codice, distribuite su migliaia di programmi).
• Spesso il suo primo nucleo risale ad oltre un decennio fa ed è quindi progettato secondo vecchie
• È scritto in linguaggio di vecchia generazione (COBOL, PL1 ed assembler).
• E’ supportato da un DBMS obsoleto (ad es. database IMS – Information Management System – di IBM), sempre che esista un DBMS e non si faccia ricorso al file system (file VSAM – Virtual Sequential Access Method).
• Le interfacce utente sono quelle a caratteri (terminali 3270 o 5250) e non GUI.
• Le applicazioni che lo compongono sono prevalentemente stand-alone, ognuna è stato progettata e realizzata indipendentemente dal resto e quindi il sistema presenta un’integrazione prevalentemente verticale e monolitica. Strutturalmente tale  software applicativo è tipicamente suddiviso in transazioni (una funzione utente scritta in COBOL) usabili contemporaneamente da più utenti.
• Non è ben documentato ed è difficile da comprendere, in quanto, quasi sempre, la documentazione non è aggiornata con le modifiche che sono state via via apportate al software.
• Il sistema può essere considerato come un repository di anni di esperienza e pratiche aziendali non esplicitamente documentate, ma presenti “immerse” nel codice stesso del legay.

Bisogna notare che la contemporaneità degli utenti è dovuta al fatto che la struttura tipica di una transazione in ambiente gestionale prevede:

• Gestione dei dati di I/O a video (mappe): trasferimento in aree di memoria, controlli di congruenza, ecc.
• Elaborazione dei dati: calcoli, preparazione degli output, ecc.
• Gestione dei dati su memoria di massa: preparazione delle aree per l’I/O, operazioni d’accesso, ecc.

Mentre, la struttura del programma è fortemente influenzata dalle esigenze del TP Monitor usato:

• devono essere presenti precise dichiarazioni riguardanti i dati in memoria, sia per la gestione dell’I/O da terminale che per quella dei dati negli archivi;
• devono essere presenti le istruzioni di attivazione del TP Monitor e delle sue singole operazioni;
• per l’I/O non sono usate le istruzioni native del linguaggio di programmazione.

Questa struttura tipicamente è monolitica (operazioni concettualmente diverse non sono collocate in parti diverse del programma) ed è scritta in un linguaggio ibrido (Es. COBOL/CICS  od assembler/IMS).

Molte applicazioni sviluppate negli anni ’70 e ’80 possono essere senz’altro considerate esempi di Legacy System. Si tenga presente, tuttavia, che le caratteristiche sopra menzionate possono, in larga parte, essere manifestate anche da applicazioni di recente realizzazione (in alcuni ambienti non sono rare affermazioni “estreme” del tipo “ogni applicazione non Java è legacy” oppure “qualsiasi cosa che non usa l’OO od il Web è legacy”).

Problematiche dei sistemi Legacy

Per dare una sensazione di quanto la problematica dei sistemi Legacy sia complessa, e vada spesso ben al di là di semplici considerazioni tecnologiche, si consideri un esempio ricavato da una esperienza nella Pubblica Amministrazione (PA). Il contesto è quello di un Ente in cui il sistema informativo prevede un pool di tre mainframe con circa 30 ambienti CICS perfettamente funzionanti e che attualmente sembrano soddisfare le necessità informative dell’Ente: si tratta di classiche elaborazioni transazionali originate dai terminali 3270 dislocati presso sedi distribuite sul territorio italiano. Il numero dei terminali è estremamente elevato e la operatività di questi deve essere preservata da qualsiasi intervento sul sistema informativo/informatico. Contemporaneamente l’Ente ha partecipato ad un progetto sperimentale mirato a rendere accessibili alcune informazioni attraverso il paradigma DOC (Distributed Object Computing). Al di là dello specifico progetto, è emerso che:

• Il Legacy System non è certo costituito dalla sola macchina mainframe con le applicazioni, ma anche tutta la rete di migliaia di terminali, sparsi su aree geografiche spesso assai vaste, che devono continuare a funzionare (altrimenti il servizio al cittadino sarebbe interrotto con conseguenze gravissime) e verso i quali è necessario garantire la compatibilità applicativa dei nuovi sviluppi. Se di colpo tutte le applicazioni venissero sviluppate solo sui server e con le tecnologie più nuove, i terminali non avrebbero modo di utilizzarle. Invece realizzando l’applicazione su mainframe e contemporaneamente integrandola con le nuove tecnologie si riesce, durante l’inevitabile periodo di transizione dal vecchio al nuovo, a far funzionare entrambi.
• Quasi l’80 % del personale ICT continua a progettare e produrre sulla vecchia architettura mainframe, in quanto il sistema rappresenta un investimento così cospicuo che la sua dismissione (anche se fosse tecnicamente possibile) non sarebbe economicamente giustificabile dal management dell’Ente. Questo significa che qualsiasi nuova applicazione sia necessario sviluppare, essa viene realizzata tramite un programma COBOL/transazione su mainframe, e solo successivamente essa viene offerta attraverso un paradigma più moderno come la DOC. Le motivazioni principali di ciò sono:
  • i mainframe sono considerati ancora più robusti dei server (d’altronde per sostituire un mainframe attualmente sarebbero richiesti pool di macchine/server di fascia alta, ed i rispettivi sistemi operativi ancora non sono così “sicuri” come quelli su mainframe);
  • sul totale del personale ICT (all’incirca 400 persone) solo una piccola percentuale è esperta nelle nuove tecnologie e metodologie (Object Oriented OO, decomposizione dell’applicazione su tre livelli software, client/server, piattaforma ed ambienti di sviluppo Windows, CORBA, DCOM, ecc.), mentre il restante personale è costituito da sistemisti MVS/CICS e programmatori COBOL o assembler.

Questo per ribadire che quando si parla di Legacy System non bisogna pensare ad un “dinosauro” morente, bensì ad un “dinosauro” vivo e vegeto, che per di più spesso trova nella struttura organizzativa stessa nuova linfa per la propria sopravvivenza.

Ed è appunto per queste ragioni che in questo contesto vengono esposti i principi chiave per il reengineering di ogni sistema/applicazione esistente.