Come ridurre i rischi della migrazione del mainframe: l'analisi preliminare indispensabile.

Le migrazioni da mainframe falliscono per un motivo prevedibile. Non perché l'architettura cloud di destinazione sia errata. Non perché gli strumenti di conversione da COBOL a Java siano insufficienti. Non perché al team manchino le giuste intenzioni o il budget necessario. Falliscono perché il team inizia a spostare le cose prima di sapere cosa siano, prima di poter rispondere con prove concrete, anziché con supposizioni, a cosa faccia ogni programma, quali programmi dipendano da quali altri, come fluiscano i dati attraverso il sistema e cosa si romperà quando qualcosa cambierà. La modalità di fallimento è quasi sempre la stessa: una dipendenza scoperta a metà migrazione di cui nessuno era a conoscenza, una regola aziendale nascosta in un manuale incluso in 400 programmi, un job batch che alimenta dodici sistemi a valle attraverso un file che nessuno si è preoccupato di documentare.

Il processo di migrazione da mainframe richiede un'attenta pianificazione ed esecuzione per minimizzare i rischi e garantire la continuità operativa. Questa affermazione è vera, ma incompleta. La pianificazione accurata che conta non è la roadmap, la selezione del fornitore o la tempistica a fasi. È l'analisi strutturale che precede qualsiasi decisione, l'analisi che rivela cosa contiene effettivamente il sistema e come funziona realmente, in contrapposizione a ciò che la documentazione afferma che contenga e a come è stato originariamente progettato. Queste due descrizioni divergono in ogni ambiente mainframe di grandi dimensioni, spesso con un margine che determina il successo o il fallimento della migrazione.

Perché le migrazioni ai mainframe falliscono: il divario analitico

Le migrazioni da mainframe non falliscono perché il codice è obsoleto, ma perché nessuno sa davvero cosa faccia quel codice finché non è troppo tardi. Logica nascosta. Casi limite non documentati. Flussi dimenticati. Questi non sono rischi teorici, ma ostacoli concreti che bloccano i progetti, causano problemi in produzione e minano silenziosamente la fiducia nel piano di migrazione.

Il divario di analisi ha una struttura specifica. Le organizzazioni che hanno gestito sistemi mainframe per venti o trent'anni hanno accumulato modifiche che non sono mai state riflesse nella documentazione, dipendenze che si sono formate organicamente man mano che i programmi venivano accoppiati tramite file condivisi anziché interfacce esplicite, e logiche di business che esistono solo nella mente degli sviluppatori ormai in pensione. I team che trattano i dati mainframe come file standard scoprono spiacevoli sorprese durante la migrazione, quando si rendono conto che i "dati" includono decenni di logica di business sparsa tra istruzioni condizionali e nomi di condizioni a 88 livelli.

Esistono quattro lacune di conoscenza specifiche che possono ostacolare le migrazioni. Ognuna di esse richiede una tecnica di analisi per essere colmata. Nessuna di esse può essere risolta unicamente con la revisione della documentazione o con i colloqui con gli sviluppatori.

Gap 1: Inventario di programmi sconosciuto. Le organizzazioni scoprono regolarmente che il numero effettivo di programmi è significativamente superiore al numero di programmi documentati. Programmi scritti per esigenze aziendali specifiche, programmi di test diventati programmi di produzione, programmi di utilità che nessuno ricorda di aver creato: tutti questi programmi sono presenti nella libreria di caricamento e possono essere richiamati da job JCL che compaiono nei programmi di produzione.

Gap 2: Dipendenze non documentate. I mainframe alimentano decine di sistemi attraverso complesse reti di middleware come WebSphere, CICS Transaction Gateway, Enterprise Service Bus, oltre a utility condivise, scheduler e processi aziendali. L'errore consiste nell'attendere troppo a lungo prima di mappare tutte queste connessioni, in particolare i flussi di dati a valle e i modelli di consumo.

Gap 3: Logica aziendale incorporata. I programmi COBOL accumulano regole aziendali nel corso dei decenni. Un calcolo che era semplice nel 1985 è stato modificato da dodici sviluppatori da allora, ognuno dei quali ha aggiunto una logica condizionale che riflette una modifica della regola aziendale mai documentata altrove. Spostare il programma senza comprenderne la logica produce un sistema migrato che calcola risultati diversi dall'originale, correttamente dal punto di vista del codice, ma in modo errato dal punto di vista aziendale.

Gap 4: Accoppiamento tra formato dati e schema. I programmi che condividono dati tramite file anziché API sono accoppiati tramite contratti di formato dati che esistono solo nelle loro istruzioni FD e COPY. Una modifica al layout dei record di un file condiviso compromette ogni programma che lo legge, inclusi potenzialmente i programmi interessati dalla migrazione e quelli che rimarranno sul mainframe, creando un errore di integrazione silenzioso.

Le otto analisi che devono avvenire prima della migrazione

Le seguenti analisi devono essere completate prima di finalizzare qualsiasi decisione di migrazione e prima di apportare qualsiasi modifica al codice. Non si tratta di passaggi preliminari da eseguire frettolosamente, bensì delle fondamenta su cui si basa ogni decisione successiva.

1. Completare l'inventario del programma

La prima analisi consiste in un censimento: quali programmi, flussi di lavoro, copybook, procedure e definizioni di dati esistono effettivamente nell'ambiente. Non si tratta di una revisione della documentazione, bensì di un'analisi approfondita delle librerie di caricamento, delle librerie sorgente e delle librerie di procedure per produrre un inventario autorevole.

L'inventario deve includere: ogni programma sorgente con il relativo linguaggio e la dimensione approssimativa; ogni copybook e i programmi che lo includono; ogni procedura catalogata e i job che la richiamano; ogni dataset presente nelle istruzioni DD e i programmi che lo producono o lo utilizzano; ogni tabella, vista e stored procedure DB2 a cui si fa riferimento nell'SQL incorporato.

Nella maggior parte dei grandi ambienti mainframe, questo inventario rivela programmi sconosciuti al team di pianificazione della migrazione, a volte con una differenza del 20-30% rispetto al totale. I piani di migrazione basati su inventari incompleti comportano sforamenti di budget quando i programmi mancanti vengono scoperti a metà progetto.

2. Mappatura delle dipendenze tra tutti i linguaggi

Una volta creato l'inventario, la mappatura delle dipendenze traccia come ogni componente si connette a ogni altro componente. La mappatura delle dipendenze è l'analisi preliminare alla migrazione più critica perché definisce la portata di ogni successiva modifica.

Una mappa completa delle dipendenze comprende:

• Chiamate da programma a programma: CALL, PERFORM, LINK, ATTACH e chiamate dinamiche che si risolvono in fase di esecuzione
• Invocazioni da JCL a programma: ogni istruzione EXEC PGM= in ogni flusso di lavoro JCL, comprese le invocazioni PROC con sostituzione simbolica dei parametri risolta
• catene di inclusione del quaderno: quali programmi includono quali copybook, inclusi i copybook annidati inclusi da altri copybook
• Relazioni produttore-consumatore del set di dati: quali programmi scrivono su quali dataset, quali programmi leggono da tali dataset e le dipendenze sequenziali della catena di processi che questo crea
• Riferimenti allo schema DB2: quali programmi leggono o scrivono su quali tabelle, quali tabelle condividono lo schema con quali altre tabelle

Il risultato è un grafo orientato. Qualsiasi modifica proposta a un nodo di tale grafo può essere analizzata per valutarne l'impatto, percorrendo gli archi per enumerare tutti gli altri nodi che dipendono da esso. Senza questo grafo, l'analisi d'impatto si baserebbe su mere congetture.

Prima di modificare qualsiasi codice, è fondamentale avere una visibilità completa. Affidarsi a documentazione obsoleta è un errore fatale; gli strumenti automatizzati devono mappare automaticamente lo stato attuale, analizzando JCL, COBOL e PL/I, e mappando tutte le applicazioni, i flussi di dati, le dipendenze e i processi nascosti.

3. Estrazione e documentazione della logica aziendale

I programmi COBOL contengono una logica di business che non esiste in nessun altro punto dell'organizzazione. Questa è l'analisi più trascurata nella pianificazione della migrazione e quella che causa i fallimenti post-migrazione più costosi.

L'estrazione della logica di business produce la documentazione di: le regole decisionali codificate nelle strutture IF/THEN/ELSE e EVALUATE; le formule di calcolo nelle istruzioni COMPUTE; le regole di convalida dei dati nei paragrafi PROCEDURE DIVISION; i percorsi di gestione degli errori e il loro significato aziendale; e la logica dipendente dalla sequenza in cui l'ordine delle operazioni è importante per la correttezza dell'output.

Questa analisi non richiede la lettura manuale di ogni riga di ogni programma. Gli strumenti di analisi statica che comprendono COBOL possono identificare le strutture decisionali, estrarre la logica condizionale e produrre una documentazione strutturata delle regole che codificano. Questo output ha un duplice scopo: fornisce al team di migrazione le specifiche necessarie per verificare che il sistema migrato produca risultati corretti e offre all'azienda la prima documentazione sistematica delle regole aziendali che potrebbero essere esistite solo nel codice per decenni.

4. Identificazione del codice morto

Non tutto ciò che si trova nel mainframe deve essere migrato. Programmi che non vengono mai richiamati da alcun flusso di lavoro, paragrafi che non vengono mai eseguiti da alcun percorso di chiamata, membri del copybook che non vengono mai referenziati: tutti questi elementi rappresentano uno sforzo di migrazione che non produce alcun valore aziendale.

L'identificazione del codice inutilizzato analizza il grafo delle dipendenze per individuare i componenti che non ricevono riferimenti in entrata da alcun flusso di lavoro di produzione. Questi componenti possono essere esclusi dall'ambito della migrazione, riducendo i costi senza compromettere la funzionalità. In ambienti legacy di grandi dimensioni, il codice inutilizzato rappresenta in genere il 10-25% dell'inventario totale, una riduzione significativa dell'ambito di intervento se identificato sistematicamente anziché scoperto accidentalmente.

L'analisi deve distinguere tra codice effettivamente inutilizzato (mai raggiungibile da alcun percorso di esecuzione in produzione) e codice eseguito raramente (raggiungibile ma raramente attivato). Il codice eseguito raramente, come le routine di elaborazione di fine anno, i programmi di reporting normativo o le procedure di ripristino di emergenza, può essere critico nonostante la sua infrequenza di esecuzione. Escluderlo dalla migrazione produce un sistema che funziona correttamente il 99% delle volte e fallisce proprio quando è più necessario.

5. Complessità e classificazione del rischio

Una volta creati l'inventario dei programmi e la mappa delle dipendenze, ogni programma può essere classificato in base alla complessità e al rischio di migrazione. La classificazione determina la sequenza di migrazione: i programmi a bassa complessità e con poche dipendenze vengono migrati per primi; i programmi ad alta complessità e con molte dipendenze vengono migrati per ultimi, con la copertura di test più completa.

Metriche di complessità per la valutazione del rischio di migrazione COBOL:

Fattore di complessità	Cosa misurare	Soglia di alto rischio
Complessità ciclomatica	Numero di rami decisionali per programma	Oltre 50 per programma
Conteggio delle dipendenze del quaderno	Numero di quaderni inclusi	Oltre 20 quaderni
Conteggio chiamato	Numero di programmi che chiamano questo programma	Oltre 15 chiamanti
Riferimenti al dataset	Numero di set di dati letti o scritti	Oltre 30 set di dati
SQL incorporato	Numero di istruzioni SQL	Oltre 100 dichiarazioni
chiamate EXEC CICS	accoppiamento del server delle transazioni	Qualsiasi dipendenza da CICS
CHIAMATE dinamiche	Le chiamate vengono risolte in fase di esecuzione.	Qualsiasi chiamata dinamica
Invocazioni dell'assembler	Logica incorporata non COBOL	Qualsiasi chiamata dell'assemblatore

I programmi che ottengono punteggi elevati su più fattori rappresentano le componenti di migrazione a più alto rischio. Richiedono l'analisi più approfondita, gli ingegneri di migrazione più esperti e la copertura di test più completa.

6. Analisi delle dipendenze tra finestra di batch e pianificazione

I processi batch del mainframe vengono eseguiti in finestre temporali programmate con complesse catene di dipendenze: il processo B non può iniziare finché il processo A non viene completato con successo; il processo C viene eseguito solo l'ultimo giorno lavorativo del mese; il processo D ha un vincolo di tempo di esecuzione massimo che influisce sull'orario di avvio del processo E. Queste dipendenze di pianificazione fanno parte del comportamento operativo del sistema e devono essere replicate nell'ambiente di destinazione.

I documenti di analisi della finestra batch includono: la catena di esecuzione completa per ogni esecuzione batch di produzione; i vincoli temporali per ogni passaggio; la logica di esecuzione condizionale (cosa accade quando un passaggio fallisce o produce un codice di ritorno diverso da zero); i set di dati che fluiscono tra i passaggi; e i trigger e le notifiche esterne generate dal sistema batch.

Nei target cloud-native, ciò si traduce in: la configurazione equivalente della pipeline CI/CD o dell'orchestrazione del flusso di lavoro; la configurazione della gestione degli errori e degli avvisi; la configurazione del monitoraggio e degli SLA; e l'integrazione con i sistemi a valle che ricevono gli output batch.

7. Valutazione della qualità e del formato dei dati

I sistemi legacy spesso includono migliaia di righe di codice scritte in COBOL, PL/I o assembly, gran parte delle quali può essere scarsamente documentata o strettamente interconnessa. Utilizza strumenti di analisi statica per individuare il debito tecnico, il codice ridondante e i moduli che possono essere modularizzati o dismessi.

La valutazione della qualità dei dati esamina i dati effettivi nei dataset di produzione confrontandoli con le definizioni di formato contenute nel COBOL FD e nel copybook. Le discrepanze sono comuni: campi decimali compressi che contengono sequenze di bit non valide per determinati tipi di record, campi a lunghezza variabile in cui l'indicatore di lunghezza è fuori intervallo per un sottoinsieme di record, campi di caratteri EBCDIC che contengono valori non visualizzabili in posizioni specifiche.

Queste discrepanze devono essere identificate e risolte prima della migrazione, non scoperte durante i test di migrazione. Una migrazione di dati che sposta 500 milioni di record e poi scopre che lo 0.1% di essi ha formati non validi presenta un difetto che influisce sulla produzione, presente nei dati di origine e sconosciuto fino alla fase di validazione.

8. Integrazione e mappatura dei sistemi esterni

La tracciabilità dei dati deve includere ogni sistema che utilizza dati provenienti dal mainframe, dagli strumenti di reporting alle integrazioni con i partner, perché i progetti di modernizzazione non possono essere implementati se i team scoprono, in fase avanzata di sviluppo, che la conservazione di questi flussi di dati era essenziale ma non prevista.

La mappatura dell'integrazione identifica ogni sistema esterno al mainframe che riceve dati da esso o invia dati ad esso: applicazioni a valle che elaborano output batch tramite trasferimento di file; interfacce in tempo reale tramite chiamate MQ, CICS o API; integrazioni con partner che si basano su formati di file e pianificazioni di trasmissione specifici; sistemi di reporting che interrogano direttamente le tabelle DB2; e feed di data warehouse che acquisiscono dati mainframe trasformati.

Ogni punto di integrazione rappresenta un potenziale rischio di transizione: un sistema migrato che produce dati in un formato non previsto da un sistema a valle genererà un errore silenzioso che potrebbe non essere rilevato fino a quando un utente a valle non segnala un'anomalia. La mappatura dell'integrazione è l'analisi che rende la pianificazione della transizione completa anziché ottimistica.

Scelta di una strategia di migrazione basata sui risultati dell'analisi

L'analisi preliminare alla migrazione non si limita a ridurre i rischi, ma determina anche la strategia di migrazione più appropriata per ciascun componente. I team migrano i carichi di lavoro mainframe in modi diversi, a seconda della quantità di modifiche che possono gestire. I risultati dell'analisi forniscono informazioni dirette a tale decisione.

Risultato dell'analisi	Strategia consigliata	Fondamento logico
Bassa complessità, poche dipendenze, nessuna chiamata dinamica	Rehosting (lift-and-shift)	Rischio minimo; equivalenza comportamentale raggiungibile rapidamente
Complessità moderata, logica aziendale ben documentata.	Ripiattaforma	Sono ammesse alcune modifiche; la logica è comprensibile.
Grafico di dipendenza denso e ad alta complessità	Fico strangolatore a fasi	Estrazione incrementale; mantenere il mainframe per il nucleo centrale mentre si modernizza l'infrastruttura circostante.
Programma condiviso di fondamentale importanza, oltre 100 partecipanti	Incapsulamento API	Esporre come servizio; migrare i consumatori senza toccare il programma
Programmi con dati non validi o problemi di formato	prima la correzione dei dati	La migrazione non può avere successo finché i dati non sono puliti.
Codice morto confermato dall'analisi	Andare in pensione	Non è necessaria alcuna migrazione; rimuovere dall'ambito
Logica aziendale non documentata, nessun esperto disponibile	È necessaria un'analisi approfondita	Non è possibile eseguire la migrazione in sicurezza finché la logica non viene estratta e documentata.

Creazione della sequenza di migrazione a partire dal grafo delle dipendenze

Il grafico delle dipendenze, una volta completato, definisce direttamente la sequenza di migrazione. I componenti che non dipendono da altri componenti del mainframe possono essere migrati in modo indipendente e nelle prime fasi. I componenti da cui dipendono molti altri devono essere migrati per ultimi, dopo che tutti i loro dipendenti sono pronti.

Un approccio pratico al sequenziamento:

Fase 1: Programmi di utilità e processi batch autonomi. Programmi senza chiamanti e senza dataset condivisi. Questi possono essere migrati singolarmente senza necessità di coordinamento.

Fase 2: Programmi foglia nell'albero delle dipendenze. Programmi che ne chiamano altri ma non vengono chiamati da molti. La migrazione di questi programmi li rimuove dall'ambito delle dipendenze per i programmi rimanenti.

Fase 3: Programmi con dati accoppiati. Gruppi di programmi che condividono set di dati possono essere migrati insieme come un'unica unità, risolvendo il contratto di formato dati all'interno del gruppo migrato.

Fase 4: Programmi di servizio condivisi. I programmi con molti chiamanti, ovvero i nodi ad alto tasso di coinvolgimento nel grafo delle dipendenze, vengono migrati solo dopo che tutti i chiamanti sono stati validati rispetto all'implementazione migrata.

Fase 5: Programmi transazionali principali. I componenti a più alto rischio, migrati per ultimi con la copertura di test più completa e il processo di transizione più controllato.

Questa sequenza non è un'euristica generale, bensì deriva dallo specifico grafo delle dipendenze del sistema in fase di migrazione. Due ambienti mainframe con lo stesso numero di programmi avranno sequenze di migrazione ottimali completamente diverse, poiché le loro strutture di dipendenza differiscono.

Come SMART TS XL Produce l'analisi pre-migrazione

SMART TS XL Esegue automaticamente tutte le otto analisi descritte in questo articolo, analizzando il codice sorgente effettivo di ogni componente nell'ambiente. Non si basa su documentazione, interviste agli sviluppatori o diagrammi preesistenti, ma ricava il modello strutturale dal codice stesso, garantendo così l'accuratezza del modello anche per programmi mai documentati e dipendenze createsi involontariamente.

L' analisi di modernizzazione dei sistemi legacy inizia con la generazione di un inventario completo: ogni programma COBOL, job stream JCL, copybook, PROC e schema SQL viene catalogato con la relativa posizione del codice sorgente, dimensione, versione del linguaggio e punteggio di complessità preliminare. La mappatura delle dipendenze dell'applicazione crea il grafo completo delle dipendenze, risolvendo i parametri simbolici JCL tramite la funzionalità di espansione JCL per mostrare i programmi effettivamente invocati anziché i riferimenti a modelli non risolti.

La funzionalità di analisi dell'impatto rende interrogabile il grafico delle dipendenze: prima di migrare qualsiasi componente, il team può chiedere quali elementi saranno interessati dalla sua rimozione dal mainframe e ricevere un elenco strutturato e dettagliato di ogni componente dipendente che richiede convalida o coordinamento. La funzionalità di ricerca aziendale consente di effettuare ricerche nell'intero inventario simultaneamente in tutti i linguaggi, trovando in pochi secondi ogni programma che legge un dataset specifico, ogni copybook che definisce un campo specifico, ogni istruzione SQL che fa riferimento a una colonna specifica, all'interno di una codebase di milioni di righe.

Il risultato dell'analisi preliminare alla migrazione non è un piano di progetto. Si tratta di dati strutturali: il grafico delle dipendenze, la classificazione della complessità, l'inventario del codice inutilizzato, la documentazione della logica di business e la mappa di integrazione che, nel loro insieme, indicano al team di migrazione esattamente con cosa sta lavorando. Questi dati fanno la differenza tra una migrazione che scopre problemi in produzione e una che li scopre in fase di analisi, quando il costo per individuarli e risolverli si misura in settimane anziché in mesi.

L'analisi non è un costo aggiuntivo, è la migrazione

L'obiezione più comune a un'analisi pre-migrazione completa riguarda le tempistiche: l'organizzazione si è impegnata a rispettare una data di inizio della migrazione, la pressione da parte dei dirigenti è elevata e dedicare dalle sei alle otto settimane all'analisi prima di toccare qualsiasi codice viene percepito come un ritardo. Questo ragionamento inverte il calcolo del rischio. Una volta che le regole sono visibili e i flussi mappati, il progetto passa dalla fase speculativa a quella ingegneristica. Gli strumenti di automazione rendono visibile l'invisibile, ed è questo l'aspetto che conta.

Una migrazione che inizia senza un'analisi completa non è più rapida, ma inizia con un ambito sconosciuto. Un ambito sconosciuto genera sorprese in termini di pianificazione, sforamenti di budget e incidenti in produzione quando le dipendenze non individuate si rivelano. La fase di analisi non ritarda la migrazione; è la migrazione stessa. Ogni dipendenza scoperta durante l'analisi anziché durante il passaggio alla fase successiva rappresenta un incidente in produzione evitato. Ogni programma identificato come codice morto prima della migrazione rappresenta uno sforzo non impiegato. Ogni regola aziendale documentata prima della conversione è un criterio di validazione che può essere testato anziché ipotizzato.

Le organizzazioni di successo sono quelle che affrontano la complessità in modo proattivo, mappano le dipendenze fin dalle prime fasi, democratizzano la conoscenza, si concentrano sul valore aziendale e si allineano su obiettivi chiari fin dal primo giorno. Queste non sono solo buone pratiche, ma rappresentano la differenza tra i progetti di trasformazione che generano un ROI misurabile e quelli che diventano esempi da non seguire.