Quali sono le quattro strategie di modernizzazione del mainframe?

Rehost, replatform, refactor e retain. Il rehost sposta il carico di lavoro su un emulatore o un'istanza cloud senza modificare il codice. Il replatform sostituisce il livello di runtime (database, transaction manager, scheduler) lasciando intatto il codice dell'applicazione. Il refactor riscrive il codice in un linguaggio moderno preservando la logica di business. Il retain mantiene deliberatamente il carico di lavoro sul mainframe. Le grandi organizzazioni normalmente ne applicano diverse all'interno di un unico portfolio piuttosto che sceglierne una sola.

Conviene eseguire il rehosting o il refactoring delle applicazioni COBOL?

Dipende dalla frequenza con cui il codice cambia e dal costo di un eventuale errore. Il rehosting è più rapido e comporta meno rischi, ma mantiene sia il codice legacy sia la dipendenza dalle competenze specifiche, pertanto è adatto a carichi di lavoro stabili soggetti a pressioni legate all'hardware o al data center. Il refactoring elimina definitivamente la dipendenza dal COBOL ed è indicato per i carichi di lavoro con un backlog di modifiche attivo, ma ha costi superiori e fallisce se le regole di business originali non sono mai state documentate. La decisione va presa per singolo carico di lavoro basandosi sullo storico delle modifiche, anziché a livello di intero portafoglio.

Quanto tempo richiede la modernizzazione del mainframe?

Dipende molto più dal livello di comprensione del sistema esistente che dalla quantità di codice. I portafogli con documentazione aggiornata ed esperti in materia disponibili procedono nell'arco di trimestri. I portafogli in cui le regole di business esistono solo come comportamento dedicano la maggior parte del tempo alla fase di discovery, prima di iniziare qualsiasi attività di migrazione. Per questo motivo, la documentazione e l'acquisizione della conoscenza sono prerequisiti, anziché flussi di lavoro paralleli.

È mai opportuno lasciare un workload sul mainframe?

Sì. I workload stabili e ad alto throughput, che cambiano raramente e sono economici da gestire (i processi di settlement batch ne sono l'esempio più evidente), sono spesso già adeguati allo scopo e spostarli aggiunge rischi senza offrire nuove funzionalità. Il retain è una strategia legittima quando viene scelto in modo deliberato e documentato. Non è invece una strategia mantenere un workload che nessuno sa spiegare, perché la conoscenza andrà comunque persa quando il team andrà in pensione.

Come modernizzare un mainframe COBOL

Quattro strategie, quanto costa realmente ciascuna e come stabilire di quale abbia bisogno un determinato carico di lavoro. Scritta per chi deve approvare la decisione.

La maggior parte dei consigli sulla modernizzazione del mainframe si riduce a un'unica domanda: migrare o meno. Questa impostazione è il motivo per cui tanti programmi si bloccano. Una grande organizzazione non ha un solo carico di lavoro mainframe; ne ha centinaia, e non tutti meritano lo stesso trattamento. La decisione utile viene presa per singolo carico di lavoro, e ci sono quattro risposte valide.

Le quattro strategie

Rehost

Sposta il carico di lavoro così com'è su un emulatore o su un'istanza cloud senza modificare il codice.

Good for: Carichi di lavoro in cui la logica di business è ancora valida e l'urgenza è dettata dai costi hardware, dalla capacità o dalla dismissione di un data center.
What it costs: L'opzione più rapida e meno rischiosa per ogni carico di lavoro. Il codice continua a essere eseguito, quindi il comportamento viene preservato quasi per costruzione.
The catch: Hai spostato il problema, non lo hai risolto. Il COBOL rimane COBOL, le regole di business non documentate restano non documentate e le persone che lo capiscono continuano a essere le uniche a capirlo. Il rehost di un carico di lavoro che non sai spiegare permette di guadagnare tempo e nient'altro.

Replatform

Sostituisci il livello di runtime (database, transaction manager, scheduler) mantenendo il codice applicativo in gran parte intatto.

Good for: Liberarsi dalle licenze per-MIPS o da un sottosistema a fine vita quando la logica applicativa è solida.
What it costs: Una via di mezzo. Meno rischi rispetto a una riscrittura, maggiori vantaggi rispetto a un lift-and-shift.
The catch: Le interfacce tra il codice applicativo e il runtime nascondono decenni di presupposti non documentati. Il passaggio da Db2 a PostgreSQL non è un semplice trova e sostituisci; i livelli di isolamento, le sequenze di collazione e la gestione dei valori null differiscono in modi che si manifestano come numeri errati anziché come crash.

Refactoring

Riscrivere il codice in un linguaggio moderno preservando la logica di business.

Good for: Carichi di lavoro che devono cambiare spesso, dove la scarsità di competenze COBOL rappresenta un vincolo per la roadmap anziché per il runbook.
What it costs: Il costo più alto e il potenziale più elevato. Se eseguita correttamente, elimina in modo permanente la dipendenza dalle competenze.
The catch: Questa è la strategia che fallisce pubblicamente. La causa del fallimento non è mai la sintassi: i transpiler gestiscono la sintassi. Il problema è che le specifiche non sono mai state messe per iscritto, quindi nessuno può dire se il nuovo sistema sia corretto. Non stai migrando codice; stai recuperando una specifica che esiste solo come comportamento.

Mantenimento

Lasciare deliberatamente il carico di lavoro sul mainframe.

Good for: Carichi di lavoro stabili e ad alto throughput, economici da gestire e che cambiano raramente. Il regolamento batch è spesso l'esempio più chiaro.
What it costs: Nessuno, se viene scelto deliberatamente e se ne documenta il motivo.
The catch: Il mantenimento è una strategia reale ed è sottoutilizzata, perché è difficile da inserire in una presentazione per il direttivo. Tuttavia, mantenere senza documentare non è una strategia, è un rinvio: si perde comunque la conoscenza quando il team va in pensione.

Come scegliere, per carico di lavoro

Quattro domande distinguono i carichi di lavoro che richiedono ciascuna strategia. Rispondi per applicazione, non per portafoglio.

Con quale frequenza viene effettivamente modificato questo codice?: Verifica la cronologia delle modifiche, non le opinioni. Il codice che non viene modificato da otto anni è un candidato per il retain o il rehost, indipendentemente dall'età del linguaggio. Il codice con una coda di modifiche in sospeso è quello in cui il refactoring si ripaga da solo.
Qualcuno è attualmente in grado di spiegarne il funzionamento?: Se la risposta dipende da una o due persone specifiche, nessuna strategia di migrazione può ancora considerarsi sicura. La documentazione e l'acquisizione delle conoscenze sono prerequisiti, non elementi da produrre in corso d'opera.
Qual è il costo di un errore?: Un'errata contabilizzazione degli interessi e un report lento non comportano lo stesso rischio. Maggiore è il costo di una differenza comportamentale silente, maggiori saranno le verifiche necessarie per la migrazione, spostando di conseguenza la convenienza economica verso il mantenimento o il rehosting.
Cosa impone realmente il cambiamento?: I costi dell'hardware, una scadenza normativa, una carenza di competenze e una roadmap di prodotto indirizzano verso strategie diverse. I programmi che non riescono a identificare il fattore trainante tendono a ripiegare sull'opzione più costosa.

Perché le migrazioni da COBOL a Java falliscono

Il percorso di refactoring merita una trattazione a sé, perché è quello che fa notizia. Le modalità di fallimento ricorrenti sono costanti in tutte le organizzazioni.

Le specifiche non sono mai state scritte

Quarant'anni di modifiche risiedono nel codice e da nessun'altra parte. Ogni riscrittura è quindi prima un atto di archeologia e poi di ingegneria. I team che saltano l'archeologia scoprono le regole mancanti in produzione.

La deriva comportamentale è silenziosa

L'aritmetica dei decimali compressi di COBOL e la virgola mobile di Java non arrotondano in modo identico. Le differenze di un centesimo per transazione non generano eccezioni; causano errori di riconciliazione a fine trimestre, molto tempo dopo che la migrazione è stata dichiarata conclusa.

I test codificano il comportamento attuale, non quello corretto

Una suite di test con esito positivo, scritta per il sistema legacy, dimostra che il nuovo sistema riproduce ciò che faceva il vecchio sui percorsi che qualcuno ha pensato di testare. I portafogli reali contengono percorsi che nessuno esegue deliberatamente da un decennio.

La ricertificazione normativa non è gratuita

Nel settore bancario, assicurativo e nella pubblica amministrazione, un sistema riscritto è spesso considerato un nuovo sistema ai fini dell'audit. Questo costo deve essere incluso nel business case fin dall'inizio, non come una scoperta al nono mese.

Gli esperti lasciano a metà programma

I programmi pluriennali si scontrano direttamente con la curva dei pensionamenti delle persone da cui dipendono. Le conoscenze devono essere acquisite prima dell'inizio del programma, perché non saranno più disponibili nel momento di maggiore necessità.

La domanda che cambia il quadro economico

Ogni strategia illustrata in precedenza è limitata dallo stesso vincolo: è possibile dimostrare che il sistema continua a fare ciò che faceva? Il testing campiona lo spazio degli input. La verifica formale lo analizza nella sua interezza, dimostrando che per ogni input il percorso modernizzato produce lo stesso output di quello legacy. Quando questa dimostrazione è disponibile, il refactoring smette di essere un salto nel buio e diventa un esercizio ingegneristico circoscritto, e la precedente domanda sul costo di un errore cambia risposta. Quando non lo è, un approccio conservativo è la posizione corretta.

Dove si inserisce Hypercubic

Sviluppiamo per l'archeologia e per la prova, in quest'ordine. HyperDocs ricostruisce la documentazione dai sorgenti COBOL, PL/I e JCL. HyperTwin acquisisce le conoscenze dei vostri ingegneri senior prima del loro pensionamento. Hopper gestisce le operazioni quotidiane di z/OS. HyperLoop esegue la migrazione vera e propria con prove di correttezza a livello di riga. Se siete in una fase abbastanza iniziale in cui i primi due contano più degli ultimi due, questa è la sequenza onesta.

Domande frequenti

Quali sono le quattro strategie di modernizzazione del mainframe?: Rehost, replatform, refactor e retain. Il rehost sposta il carico di lavoro su un emulatore o un'istanza cloud senza modificare il codice. Il replatform sostituisce il livello di runtime (database, transaction manager, scheduler) lasciando intatto il codice dell'applicazione. Il refactor riscrive il codice in un linguaggio moderno preservando la logica di business. Il retain mantiene deliberatamente il carico di lavoro sul mainframe. Le grandi organizzazioni normalmente ne applicano diverse all'interno di un unico portfolio piuttosto che sceglierne una sola.
Conviene eseguire il rehosting o il refactoring delle applicazioni COBOL?: Dipende dalla frequenza con cui il codice cambia e dal costo di un eventuale errore. Il rehosting è più rapido e comporta meno rischi, ma mantiene sia il codice legacy sia la dipendenza dalle competenze specifiche, pertanto è adatto a carichi di lavoro stabili soggetti a pressioni legate all'hardware o al data center. Il refactoring elimina definitivamente la dipendenza dal COBOL ed è indicato per i carichi di lavoro con un backlog di modifiche attivo, ma ha costi superiori e fallisce se le regole di business originali non sono mai state documentate. La decisione va presa per singolo carico di lavoro basandosi sullo storico delle modifiche, anziché a livello di intero portafoglio.
Perché le migrazioni da COBOL a Java falliscono?: Raramente a causa della sintassi. Falliscono perché le specifiche non sono mai state messe per iscritto, quindi nessuno può dimostrare che il sistema riscritto sia corretto; perché l'aritmetica differisce tra il formato packed decimal del COBOL e la virgola mobile di Java, producendo derive silenziose negli arrotondamenti anziché crash; perché le suite di test codificano il comportamento attuale sui percorsi che qualcuno ha pensato di testare, anziché il comportamento corretto su tutti i percorsi; perché i costi di ricertificazione normativa vengono scoperti in ritardo; e perché gli esperti che conoscono il sistema vanno in pensione durante il programma.
Quanto tempo richiede la modernizzazione del mainframe?: Dipende molto più dal livello di comprensione del sistema esistente che dalla quantità di codice. I portafogli con documentazione aggiornata ed esperti in materia disponibili procedono nell'arco di trimestri. I portafogli in cui le regole di business esistono solo come comportamento dedicano la maggior parte del tempo alla fase di discovery, prima di iniziare qualsiasi attività di migrazione. Per questo motivo, la documentazione e l'acquisizione della conoscenza sono prerequisiti, anziché flussi di lavoro paralleli.
È mai opportuno lasciare un workload sul mainframe?: Sì. I workload stabili e ad alto throughput, che cambiano raramente e sono economici da gestire (i processi di settlement batch ne sono l'esempio più evidente), sono spesso già adeguati allo scopo e spostarli aggiunge rischi senza offrire nuove funzionalità. Il retain è una strategia legittima quando viene scelto in modo deliberato e documentato. Non è invece una strategia mantenere un workload che nessuno sa spiegare, perché la conoscenza andrà comunque persa quando il team andrà in pensione.

Scopri quali workload migrare per primi.

Parla con il nostro team per mappare il tuo portafoglio rispetto alle quattro strategie, oppure inizia dal glossario se stai creando un vocabolario interno.

Richiedi demo Leggi il glossario