COBOL oggi: perché il codice legacy è ancora strategico e come modernizzarlo

Almeno 800 miliardi di righe di COBOL (COmmon Business Oriented Language), ancora in produzione a livello globale, gestiscono ogni giorno miliardi di transazioni, nei sistemi di banche e assicurazioni, nelle pubbliche amministrazioni centrali, nella sanità, nelle prenotazioni aeree, nelle fatturazioni telco, nel retail, nelle operazioni bancomat. La longevità delle applicazioni COBOL deriva dalla loro resilienza e adattabilità che consente di svolgere un ruolo vitale nel mantenimento di questi sistemi legacy. Da considerare poi che, secondo un report di Forrester del 2024, il 61% delle aziende globali utilizza il mainframe e, fra le aziende che lo usano, il 54% prevede di intensificarne l’utilizzo.

Il linguaggio è stato progettato per scrivere applicazioni che eseguono transazioni e hanno come input dati (da file, database o altro) che, una volta elaborati, producono risultati nella forma desiderata. Il successo del COBOL è probabilmente dovuto anche alla sua portabilità: in quanto linguaggio compilato (normale oggi, un unicum all’epoca), a partire dal codice sorgente genera script per diverse tipologie di macchine/sistemi operativi.

Cos’è COBOL e perché è ancora usato

Il COBOL (Common Business-Oriented Language), nato nel 1959, rappresenta l’ossatura invisibile del sistema economico globale. Nonostante i decenni trascorsi dalla sua introduzione, questo linguaggio di programmazione domina ancora i settori ad alta intensità di transazioni, come il comparto bancario, assicurativo e la pubblica amministrazione.

Il motivo della sua persistenza non risiede nella nostalgia tecnologica, ma in una rigorosa logica di efficienza computazionale e stabilità operativa. Il COBOL è stato progettato specificamente per l’elaborazione di dati aziendali e finanziari su larga scala; la sua capacità di gestire calcoli decimali con precisione assoluta lo rende, ancora oggi, superiore a molti linguaggi moderni nel processing di massa dei mainframe.

Inoltre, il costo e il rischio associati alla migrazione totale verso nuove architetture sono spesso proibitivi. Si stima che miliardi di righe di codice COBOL gestiscano quotidianamente il 95% dei passaggi di carte di credito e l’80% delle transazioni commerciali mondiali. Sostituire un sistema che garantisce una business continuity pressoché perfetta con alternative meno collaudate rappresenta una sfida che molte organizzazioni preferiscono affrontare attraverso strategie di modernizzazione incrementale piuttosto che con una dismissione radicale.

Caratteristiche del linguaggio COBOL

Il successo e la longevità del COBOL derivano da una struttura sintattica e logica profondamente diversa dai linguaggi di programmazione general-purpose nati successivamente.

La sua architettura è ottimizzata per la gestione di input/output massivi e per l’affidabilità nei calcoli finanziari, ambiti in cui la precisione è un requisito non negoziabile.

Ecco i pilastri tecnici che ne definiscono il funzionamento:

• Sintassi orientata alla leggibilità (English-like): a differenza dei linguaggi simbolici, il COBOL utilizza una sintassi basata sulla lingua inglese. Questo approccio, voluto originariamente per permettere anche ai non tecnici di comprendere la logica di business, riduce drasticamente i margini di errore nella documentazione e facilita la manutenzione di sistemi che devono restare operativi per decenni.
• Struttura rigida in divisioni: ogni programma COBOL è organizzato in quattro aree gerarchiche obbligatorie:
  1. identification division: contiene i metadati del programma.
  2. environment division: specifica l’interazione tra il software e l’hardware sottostante.
  3. data division: definisce in modo granulare ogni singola variabile e record.
  4. procedure division: dove risiede la logica algoritmica vera e propria.
• Precisione aritmetica decimale: mentre molti linguaggi moderni utilizzano la virgola mobile (floating-point), che può introdurre piccoli errori di arrotondamento nei calcoli complessi, il COBOL utilizza il sistema Fixed-Point. Questa caratteristica garantisce che ogni centesimo di euro o dollaro venga calcolato con esattezza matematica, un fattore critico per i bilanci bancari.
• Efficienza nell’elaborazione Batch: il linguaggio eccelle nell’elaborazione di file sequenziali di enormi dimensioni. La sua capacità di gestire record strutturati e gerarchie di dati complessi lo rende lo strumento ideale per i processi notturni di riconciliazione bancaria o per il calcolo delle buste paga di grandi organizzazioni.

Perché è adatto ai sistemi transazionali

Il termine “transazionale” identifica operazioni che devono rispettare rigorosi criteri di atomicità, coerenza, isolamento e durabilità (ACID). Il COBOL è stato forgiato attorno a queste necessità molto prima che diventassero standard di mercato, consolidandosi come il motore preferenziale per l’economia in tempo reale.

La sua superiorità nei sistemi transazionali poggia su tre driver economici e tecnici fondamentali:

• Capacità di throughput massivo: il COBOL è ottimizzato per comunicare direttamente con i sottosistemi di gestione delle transazioni dei mainframe (come CICS o IMS). Questa integrazione permette di processare migliaia di operazioni al secondo con una latenza minima, una densità di calcolo che i sistemi distribuiti faticano a replicare con la stessa efficienza energetica e di costo per transazione.
• Gestione nativa dei dati strutturati: a differenza dei linguaggi orientati agli oggetti, che richiedono spesso complessi processi di mappatura (ORM) per dialogare con le basi dati, il COBOL tratta i record come entità native. Questa aderenza strutturale elimina i colli di bottiglia computazionali durante l’accesso ai database gerarchici e relazionali, accelerando le fasi di commit e rollback delle transazioni finanziarie.
• Affidabilità e scalabilità verticale: i sistemi transazionali critici non possono permettersi downtime. L’architettura del COBOL, eseguita su hardware mainframe progettato per la ridondanza totale, garantisce una disponibilità del sistema (“uptime”) vicina al 100%. La scalabilità verticale permette di assorbire picchi improvvisi di traffico — come quelli registrati durante i periodi di saldi o scadenze fiscali — senza degradare le performance operative.

La resilienza di questo linguaggio risiede dunque nella sua capacità di agire come un “notaio digitale”: ogni operazione viene verificata, registrata e conclusa con una precisione che protegge l’integrità del dato e, di riflesso, la solidità patrimoniale delle istituzioni che lo utilizzano.

Dove viene usato oggi

Sebbene gran parte degli utenti finali non interagisca mai direttamente con una riga di codice COBOL, la loro vita quotidiana dipende costantemente dal corretto funzionamento di questi sistemi.

L’impiego attuale del linguaggio si concentra laddove la continuità operativa e la gestione di volumi di dati monumentali sono requisiti vitali per la stabilità di un Paese.

I principali verticali di adozione includono:

• Banking e Finance: è il settore d’elezione. Dai sistemi di core banking che gestiscono i conti correnti ai circuiti interbancari per i bonifici (come i sistemi SWIFT o SEPA), il COBOL elabora la quasi totalità dei movimenti finanziari globali. Ogni volta che viene utilizzato un ATM o effettuato un pagamento tramite POS, è altamente probabile che un’istruzione COBOL stia validando la transazione in background.
• Assicurazioni: le grandi compagnie assicurative utilizzano il linguaggio per la gestione delle polizze, il calcolo dei premi e l’elaborazione dei sinistri su archivi storici che risalgono a decenni fa. La capacità del COBOL di gestire gerarchie di dati complesse lo rende ideale per mantenere l’integrità di contratti a lungo termine.
• Pubblica Amministrazione e previdenza: molte istituzioni governative si affidano al COBOL per l’erogazione dei servizi sociali. In Italia, come in molti altri Paesi occidentali, i sistemi che calcolano le pensioni e gestiscono le anagrafiche tributarie poggiano su infrastrutture mainframe legacy, proprio per la necessità di processare milioni di record simultaneamente senza margini di errore.
• Logistica e trasporti: dalla gestione delle prenotazioni aeree alla tracciabilità dei cargo nel commercio marittimo internazionale, il COBOL supporta la logistica globale, assicurando che i flussi di merci e passeggeri siano coordinati attraverso database centralizzati ad alta disponibilità.

L’attuale sfida per le aziende di questi settori non è tanto l’abbandono del linguaggio, quanto la sua integrazione con il cloud e le interfacce moderne, garantendo che il “motore” COBOL possa comunicare in modo fluido con le nuove applicazioni mobile e web.

Perché il COBOL è diventato un tema strategico per le aziende

Il ritorno del COBOL al centro delle agende dei CIO non è dettato da un revival tecnologico, ma da una necessità economica e operativa legata alla transizione digitale. Se per anni il software legacy è stato considerato un “debito” da gestire passivamente, oggi è diventato un asset critico per tre ragioni fondamentali: la scarsità di competenze, la resilienza del business e la pressione dei costi.

Ecco i fattori che lo rendono un tema prioritario nella strategia aziendale:

• Skills Gap generazionale: gran parte della forza lavoro esperta in programmazione mainframe sta raggiungendo l’età pensionabile. Questo crea un rischio operativo significativo: le aziende si trovano a gestire sistemi vitali senza avere internamente il ricambio generazionale necessario per la manutenzione e l’evoluzione del codice. La formazione di nuovi talenti o l’acquisizione di servizi gestiti specializzati è diventata una voce di spesa e di rischio strategico.
• Time-to-Market e Agilità: in un mercato dominato da fintech e startup agili, le grandi istituzioni finanziarie devono poter lanciare nuovi servizi digitali in tempi rapidi. Poiché i dati core risiedono spesso in programmi COBOL, la capacità di esporre queste funzioni tramite API moderne è il vero collo di bottiglia della competitività. Rendere il COBOL “parlante” con il resto dell’ecosistema software è la chiave per non restare isolati.
• Analisi dei rischi di migrazione: i fallimenti di molti progetti di “rip and replace” (sostituzione radicale) hanno dimostrato che il rischio di migrare decenni di logica di business stratificata è spesso superiore ai benefici ipotizzati. Di conseguenza, la strategia si è spostata sulla modernizzazione selettiva: mantenere il core stabile in COBOL e innovare lo strato applicativo circostante.
• Compliance e Cybersecurity: con l’irrigidimento delle normative sulla protezione dei dati (come il DORA per il settore finanziario), garantire la sicurezza dei sistemi legacy è un obbligo legale. Il COBOL, pur essendo intrinsecamente sicuro se isolato, richiede interventi strutturali per essere protetto all’interno di reti moderne e interconnesse.

In sintesi, il COBOL è oggi il banco di prova su cui si misura la capacità di un’azienda di bilanciare la sicurezza della tradizione con l’imperativo dell’innovazione. Ignorare il peso di questo codice significa compromettere le fondamenta stesse su cui poggia l’intera infrastruttura digitale dell’organizzazione.

Sistemi mission-critical e continuità operativa

Il concetto di mission-critical definisce tutti quei processi aziendali il cui fallimento comporterebbe l’arresto immediato delle attività core, con danni economici incalcolabili e ripercussioni reputazionali sistemiche. In questo scenario, il COBOL non è solo un linguaggio, ma il garante della business continuity per le infrastrutture critiche globali.

L’affidabilità del binomio COBOL-Mainframe si fonda su parametri di resilienza che superano gli standard comuni del software commerciale:

• Disponibilità “Five Nines” (99,999%): grazie all’architettura su cui viene eseguito, il codice COBOL supporta livelli di disponibilità tali da garantire un fermo macchina di pochi minuti l’anno. Per una banca o una compagnia aerea, un’interruzione di pochi secondi può tradursi in perdite milionarie; il COBOL minimizza questo rischio offrendo una stabilità consolidata in oltre sessant’anni di operatività.
• Integrità transazionale e Disaster Recovery: la gestione delle transazioni in ambiente COBOL è progettata per resistere a guasti hardware o interruzioni di rete. I meccanismi di sincronizzazione e recupero dei dati sono talmente integrati a livello di sistema operativo (come lo z/OS) che il ripristino della coerenza dei dati avviene in modo quasi istantaneo, proteggendo i record finanziari da corruzioni o perdite.
• Isolamento e sicurezza: operando in ambienti controllati e spesso fisicamente separati dalle reti pubbliche, il codice legacy COBOL offre una superficie di attacco ridotta rispetto alle moderne architetture distribuite. La sua natura deterministica e la rigorosa gestione degli accessi lo rendono intrinsecamente resiliente a molte tipologie di minacce informatiche che colpiscono i livelli applicativi più superficiali.

In un’economia che opera 24/7, la continuità non è un’opzione ma un requisito normativo e competitivo. Investire nella manutenzione e nell’ottimizzazione del codice COBOL significa, per un’azienda, proteggere il motore che genera il flusso di cassa e garantisce la fiducia degli stakeholder.

Carenza di competenze COBOL

Il paradosso del COBOL risiede nel divario tra la sua onnipresenza economica e la progressiva scomparsa degli specialisti in grado di gestirlo. Quello che per decenni è stato un problema latente è oggi diventato una criticità strategica, poiché l’uscita dal mercato del lavoro della “generazione mainframe” sta lasciando scoperti ruoli chiave per la manutenzione di infrastrutture vitali.

Questa carenza di talenti impatta sulle aziende attraverso tre direttrici principali:

• Il pensionamento degli esperti: la maggior parte dei programmatori COBOL ha iniziato la carriera tra gli anni ’70 e ’80. Con il raggiungimento dell’età pensionabile, la conoscenza tacita — ovvero quella comprensione profonda delle personalizzazioni apportate al codice nel corso di quarant’anni — rischia di svanire, rendendo ogni intervento di manutenzione più lento, costoso e rischioso.
• Difficoltà nel reclutamento e formazione: per anni, le università e i percorsi di formazione informatica hanno rimosso il COBOL dai programmi di studio a favore di linguaggi moderni come Python o Java. Di conseguenza, i giovani sviluppatori percepiscono il COBOL come una tecnologia obsoleta, riducendo drasticamente il bacino di talenti disponibili per le direzioni HR.
• Inflazione dei costi di consulenza: la scarsità di offerta rispetto a una domanda costante ha innescato un aumento dei costi per le prestazioni professionali. Le aziende che non hanno investito in programmi di formazione interna sono costrette a rivolgersi a società di consulenza esterne o a richiamare esperti in pensione, con un impatto diretto sul budget dell’area IT.

Per mitigare questo rischio, le organizzazioni più lungimiranti stanno adottando strategie di reverse mentoring, dove gli esperti senior affiancano i giovani sviluppatori per trasferire la logica di business, e stanno implementando strumenti di intelligenza artificiale per l’analisi e la documentazione automatica del codice legacy.

Costi di manutenzione e debito tecnico

Dal punto di vista della gestione finanziaria dell’IT, il COBOL rappresenta oggi una delle voci più rilevanti nel calcolo del Total Cost of Ownership (TCO). Il mantenimento di sistemi legacy non è soltanto una questione di canoni hardware o licenze software, ma si configura come la gestione di un debito tecnico stratificato, il cui “interesse” economico aumenta proporzionalmente all’invecchiamento delle architetture.

L’impatto finanziario della manutenzione COBOL si articola su tre livelli:

• L’onere della conservazione: manutenere codice scritto decenni fa richiede test di regressione estremamente complessi ogni volta che viene introdotta una piccola modifica. Poiché molte di queste applicazioni mancano di documentazione aggiornata o di test automatizzati moderni, il tempo e il budget necessari per garantire che le nuove funzionalità non compromettano l’integrità del sistema core diventano sempre più onerosi.
• Infrastrutture e licenze: l’esecuzione di programmi COBOL è strettamente legata all’ecosistema mainframe. Sebbene queste macchine offrano prestazioni ineguagliabili, i costi di gestione dei data center proprietari, dei consumi energetici e delle licenze software specifiche sono sensibilmente superiori rispetto alle soluzioni cloud commodity o serverless, rendendo il costo per unità di calcolo meno flessibile.
• Costo opportunità e rigidità: il vero debito tecnico si manifesta nell’impossibilità di innovare rapidamente. Ogni euro investito semplicemente per “tenere accese le luci” (Run the Business) è un euro sottratto all’innovazione (Change the Business). La rigidità del codice legacy impedisce alle aziende di reagire con agilità ai cambiamenti del mercato, creando un costo indiretto legato alla perdita di competitività.

Tuttavia, il debito tecnico non si risolve necessariamente con la cancellazione del codice. Molte organizzazioni stanno scoprendo che la refactoring — ovvero la ristrutturazione del codice esistente per migliorarne la leggibilità e facilitarne l’integrazione — è spesso un investimento più redditizio rispetto a una riscrittura completa, poiché permette di abbattere i costi di manutenzione senza rinunciare alla stabilità del sistema.

COBOL, mainframe e applicazioni legacy: il nodo della modernizzazione

Il cuore della sfida per le direzioni IT non è la semplice esistenza del COBOL, ma la sua integrazione in un ecosistema tecnologico che evolve a velocità doppia. Il “nodo” della modernizzazione risiede nella necessità di trasformare sistemi monolitici, concepiti per un’era pre-internet, in componenti agili capaci di alimentare applicazioni mobile, piattaforme web e analisi dei dati in tempo reale.

Le strategie di modernizzazione adottate oggi dalle grandi imprese si muovono lungo tre direttrici principali, ciascuna con profili di rischio e rendimento differenti:

• Rehosting (Lift and Shift): questa tecnica prevede lo spostamento delle applicazioni COBOL esistenti dal mainframe fisico a infrastrutture cloud o x86, senza modificare il codice sorgente. È la soluzione più rapida per ridurre i costi fissi dei data center, pur mantenendo intatta la logica di business consolidata.
• Replatforming ed esposizione tramite API: invece di migrare l’intero sistema, le aziende creano uno strato di interconnessione (API Layer) che permette al codice COBOL di comunicare con il mondo esterno. In questo modo, un’applicazione scritta in Java o Python può interrogare il database del mainframe come se fosse un moderno microservizio, preservando la potenza transazionale del core legacy.
• Refactoring e Trasformazione del Codice: è l’approccio più profondo e consiste nella conversione automatizzata o assistita del COBOL in linguaggi moderni. Grazie all’avvento dell’intelligenza artificiale generativa, è oggi possibile mappare le dipendenze del codice legacy e tradurlo in strutture più flessibili, riducendo gli errori umani che storicamente hanno frenato questi progetti.

Modernizzare non significa necessariamente distruggere il passato, ma piuttosto liberare il valore racchiuso nelle applicazioni legacy. Il successo di questa operazione dipende dalla capacità di disaccoppiare i dati dalle funzioni, trasformando il mainframe da “silo isolato” a motore integrato della Hybrid Cloud strategy aziendale.

Cosa significa modernizzare un’applicazione COBOL

Modernizzare un’applicazione COBOL non è un semplice aggiornamento tecnico, ma un processo di evoluzione architettonica volto a eliminare i vincoli di un software monolitico senza perderne la logica di business. In termini economici, significa trasformare un costo fisso e rigido in un asset flessibile e integrato, capace di supportare i nuovi modelli di business digitali.

Il processo di modernizzazione si articola tipicamente su tre livelli di intervento:

• Modernizzazione dell’Interfaccia (In-Place): è l’intervento meno invasivo. Consiste nel mantenere il codice COBOL intatto sul mainframe, ma “esporre” le sue funzioni verso l’esterno attraverso web service o REST API. In questo scenario, il COBOL continua a elaborare le transazioni, ma i dati diventano accessibili ad app mobile, portali web o sistemi di analisi in tempo reale, abbattendo i silos informativi.
• Modernizzazione della Logica (Refactoring): questo approccio prevede la revisione del codice per migliorarne la struttura interna. Si tratta di eliminare il cosiddetto “codice spaghetti”, ottimizzare le query ai database e documentare le funzioni esistenti. Spesso ci si avvale di strumenti di AI-assisted refactoring per tradurre segmenti di codice COBOL in linguaggi moderni, facilitando la manutenzione da parte di sviluppatori non specialisti del linguaggio legacy.
• Modernizzazione dell’Infrastruttura (Replatforming): significa spostare l’applicazione dal mainframe fisico a un ambiente più moderno, come un cloud pubblico o privato. Questo passaggio permette di adottare metodologie DevOps e di scalare le risorse in modo elastico, riducendo i costi legati all’hardware proprietario e migliorando l’integrazione con le moderne pipeline di sviluppo software.

In definitiva, modernizzare significa garantire che il patrimonio di dati e regole di business accumulato in decenni di operatività possa continuare a generare valore in un contesto Hybrid Cloud. Non si tratta di una “rottamazione”, ma di un intervento di ingegneria mirato a rendere il sistema core resiliente, sicuro e, soprattutto, aperto all’innovazione.

Perché riscrivere tutto è spesso rischioso

Perché riscrivere tutto è spesso rischioso

Nella strategia IT, la tentazione del Rip and Replace, ovvero la riscrittura integrale di un sistema COBOL in un linguaggio moderno, si scontra spesso con una realtà economica e operativa complessa. Sebbene l’idea di liberarsi definitivamente del codice legacy possa apparire razionale, i dati storici indicano che i progetti di sostituzione radicale dei core system presentano tassi di fallimento elevatissimi, con costi che tendono a superare di gran lunga i budget iniziali.

Le ragioni per cui la riscrittura totale è considerata una mossa ad alto rischio sono molteplici:

• Perdita della logica di business stratificata: in decenni di attività, migliaia di modifiche, correzioni di bug e adattamenti normativi sono stati codificati direttamente nei programmi COBOL. Molte di queste regole di business non sono documentate altrove; riscrivere il sistema da zero significa rischiare di tralasciare eccezioni critiche o processi specifici che garantiscono il corretto funzionamento dell’azienda, con conseguenze imprevedibili sulla coerenza dei dati.
• Complessità delle integrazioni: un sistema mainframe non vive isolato, ma è collegato a centinaia di altre applicazioni, database e flussi di dati. Ricreare l’intera rete di interdipendenze in un nuovo ambiente è un’operazione di ingegneria massiva. Ogni errore nella mappatura delle interfacce può causare interruzioni nei servizi critici, con un impatto immediato sulla business continuity.
• Il paradosso del tempo e del mercato: un progetto di riscrittura di un sistema core può durare anni. Durante questo periodo, il mercato e le normative continuano a evolversi. Il rischio concreto è che, al momento del rilascio, il nuovo sistema sia già obsoleto o non più rispondente alle necessità correnti dell’azienda, trasformando l’investimento in un fallimento strategico.
• Stress organizzativo e costi ombra: La migrazione totale richiede un impegno massivo da parte del personale, distogliendo risorse preziose dall’innovazione e dalle attività ordinarie. I “costi ombra” legati alla formazione del personale sul nuovo sistema e alla gestione della fase di transizione (spesso con il mantenimento di entrambi i sistemi in parallelo) possono erodere rapidamente i margini di profitto.

In sintesi, la riscrittura integrale è spesso un azzardo finanziario. Le organizzazioni più mature preferiscono oggi approcci di modernizzazione incrementale, che permettono di aggiornare il sistema un modulo alla volta, riducendo l’esposizione al rischio e garantendo un ritorno sull’investimento più immediato e misurabile.

Quando ha senso mantenere il mainframe

Nonostante la spinta verso il cloud pubblico, la conservazione dell’infrastruttura mainframe rimane una scelta razionale, e spesso superiore, in presenza di specifici carichi di lavoro. La decisione di mantenere il “ferro” non è dettata da inerzia tecnologica, ma da una valutazione del rapporto costo-prestazione su volumi di dati che metterebbero in crisi le architetture distribuite.

Mantenere il mainframe ha senso logico ed economico in quattro scenari principali:

• Densità transazionale estrema: quando un’organizzazione deve gestire decine di migliaia di transazioni al secondo (TPS) con latenza prossima allo zero, il mainframe offre un’efficienza che il cloud fatica a pareggiare. In questi contesti, il costo per transazione su mainframe è spesso inferiore a quello di un’architettura a microservizi, che richiederebbe una gestione complessa di orchestrazione e rete per ottenere le medesime performance.
• Sicurezza e Governance del dato: per i settori soggetti a normative stringenti (come il settore bancario o la difesa), la capacità del mainframe di crittografare il 100% dei dati a riposo e in transito senza degradare le prestazioni (Pervasive Encryption) rappresenta un vantaggio competitivo. La centralizzazione del dato permette inoltre un controllo più granulare sulla compliance e sulla protezione da minacce esterne.
• Carichi di lavoro Predictable: il cloud eccelle nella gestione di picchi improvvisi e variabili (elasticità). Tuttavia, per processi core che presentano carichi costanti, prevedibili e massivi — come le elaborazioni batch notturne — il mainframe offre una stabilità operativa e una saturazione delle risorse che rendono il costo operativo più stabile e prevedibile nel lungo periodo.
• Sistemi con logica di business “imbricata”: se il sistema COBOL è talmente integrato con altre procedure core da rendere il disaccoppiamento troppo rischioso o costoso, mantenere l’ambiente originale è la scelta più sicura per la business continuity. In questo caso, l’hardware viene visto come una “black box” affidabile che continua a erogare valore mentre l’innovazione avviene agli strati superiori.

In conclusione, il mainframe non deve essere visto come un’alternativa al cloud, ma come una componente di una strategia di Hybrid Cloud. La vera efficienza si ottiene posizionando ogni carico di lavoro sull’infrastruttura più adatta: il dinamismo sul cloud, la solidità transazionale sul mainframe.

Le principali strategie di modernizzazione COBOL

Il ruolo dell’AI generativa nella modernizzazione COBOL

L’avvento dell’Intelligenza Artificiale Generativa ha segnato un punto di svolta nel rapporto tra aziende e codice legacy. Se fino a pochi anni fa la gestione del COBOL dipendeva esclusivamente dalla disponibilità di rari esperti senior, oggi i Large Language Models (LLM) agiscono come acceleratori tecnologici, riducendo drasticamente le barriere d’ingresso e i tempi di esecuzione dei progetti di trasformazione.

L’impatto dell’AI generativa si manifesta attraverso tre applicazioni principali che migliorano l’efficienza finanziaria e operativa:

• Traduzione assistita del codice: l’AI è in grado di analizzare migliaia di righe di codice COBOL e suggerire la loro traduzione in linguaggi moderni come Java o Python. Non si tratta di una conversione acritica, ma di una riscrittura che tiene conto dei nuovi paradigmi di programmazione, mantenendo intatta la logica di business originale. Questo approccio riduce i rischi di errore umano e i tempi di test necessari per la validazione delle nuove componenti.
• Documentazione e “spiegazione” del codice: uno dei costi maggiori nella manutenzione del legacy è il tempo speso dagli sviluppatori per comprendere programmi scritti decenni fa. L’AI generativa può agire come un analista virtuale, generando istantaneamente sintesi in linguaggio naturale che spiegano cosa fa una specifica funzione COBOL, quali sono le sue dipendenze e come interagisce con i dati, facilitando il passaggio di consegne tra diverse generazioni di programmatori.
• Generazione automatica di test unitari: garantire che una modifica non rompa un sistema critico richiede una copertura di test massiva. L’AI può generare automaticamente scenari di test e dati sintetici basati sul codice COBOL esistente, assicurando che la versione modernizzata dell’applicazione si comporti esattamente come l’originale in ogni condizione operativa.

Tuttavia, l’AI non sostituisce l’occhio umano, specialmente nei sistemi mission-critical. Il modello vincente è quello del Human-in-the-loop, dove gli strumenti di intelligenza artificiale automatizzano le attività ripetitive e a basso valore, permettendo agli architetti software di concentrarsi sulla governance del progetto e sulla sicurezza complessiva del sistema.

Analisi del codice e documentazione automatica

Uno degli ostacoli principali alla modernizzazione dei sistemi legacy è la cosiddetta “scatola nera”: programmi COBOL stratificati in decenni di interventi, spesso privi di una documentazione aggiornata. In questo contesto, l’analisi del codice e la documentazione automatica non sono solo strumenti tecnici, ma leve strategiche per ridurre il rischio operativo e accelerare il passaggio verso architetture più agili.

L’adozione di soluzioni avanzate per l’analisi del patrimonio applicativo permette di intervenire su tre fronti critici:

• Mappatura delle dipendenze (Inventory): gli strumenti di analisi statica scansionano milioni di righe di codice per identificare le relazioni tra i diversi programmi, i database e i file di sistema. Questa “radiografia” automatizzata è fondamentale per comprendere l’impatto di una modifica su un modulo specifico, evitando l’effetto domino che potrebbe compromettere la stabilità dell’intero mainframe.
• Reverse engineering della logica di Business: poiché gran parte della conoscenza funzionale è racchiusa esclusivamente nel codice sorgente, i tool di documentazione automatica estraggono le regole di business e le trasformano in diagrammi di flusso o specifiche leggibili anche da analisti non esperti di COBOL. Questo processo è vitale per trasferire il know-how dalla “generazione mainframe” ai nuovi team di sviluppo.
• Rilevazione del debito tecnico e vulnerabilità: l’analisi automatizzata permette di individuare pattern di programmazione inefficienti, codice morto (mai eseguito) o potenziali falle di sicurezza. Sapere esattamente cosa “pulire” prima di procedere a un’integrazione API o a una migrazione cloud riduce drasticamente i tempi e i costi del progetto.

L’integrazione di queste tecnologie nei processi di Application Portfolio Management consente alle aziende di trasformare una massa informe di codice in un asset trasparente e governabile. Documentare in modo automatico significa, in ultima analisi, riappropriarsi del controllo sulla propria infrastruttura, rendendo la modernizzazione un percorso basato sui dati e non sulle supposizioni.

Supporto alla migrazione COBOL-Java

La transizione dal COBOL a Java rappresenta oggi il percorso di migrazione più battuto dalle organizzazioni che mirano a coniugare la solidità dei processi core con la flessibilità degli ecosistemi moderni.

Non si tratta solo di un cambio di sintassi, ma di un passaggio di paradigma: dalla programmazione procedurale orientata ai record a quella orientata agli oggetti (OOP), abilitando l’uso di microservizi, container e architetture cloud-native.

Il successo di questa migrazione poggia su una strategia di supporto strutturata in diverse fasi tecniche:

• Mapping dei tipi di dato e precisione aritmetica: uno dei nodi critici è la gestione dei calcoli decimali. Mentre il COBOL utilizza il formato Packed Decimal per la precisione assoluta, in Java è necessario implementare correttamente classi come BigDecimal per evitare errori di arrotondamento che sarebbero inaccettabili in ambito bancario o assicurativo.
• Refactoring della logica procedurale: i programmi COBOL tendono a essere monolitici e ricchi di istruzioni di salto (GO TO). Il supporto alla migrazione prevede l’estrazione di queste logiche per riorganizzarle in classi e metodi Java riutilizzabili, migliorando drasticamente la manutenibilità e la leggibilità del codice nel lungo periodo.
• Integrazione con i framework moderni: migrare verso Java permette di sfruttare ecosistemi come Spring Boot, che facilitano l’esposizione delle funzioni core come API REST. Questo consente alle aziende di integrare i vecchi processi di back-end con le moderne interfacce front-end e con i servizi di analisi dati basati su cloud in modo fluido e standardizzato.
• Pipeline di Continuous Integration (CI/CD): portare il codice COBOL verso Java significa poter adottare finalmente metodologie DevOps complete. Il supporto alla migrazione include la configurazione di test automatizzati e sistemi di deployment che riducono il time-to-market per ogni nuova funzionalità, eliminando i colli di bottiglia tipici dei cicli di rilascio mainframe.

Scegliere Java come target della migrazione non significa solo aggiornare il linguaggio, ma dotare l’azienda di una piattaforma standard, supportata da una vasta comunità di sviluppatori e pronta per le sfide della scalabilità globale.

Limiti dell’AI: perché serve ancora competenza umana

Nonostante l’intelligenza artificiale generativa abbia abbattuto drasticamente i tempi di analisi e traduzione del codice, essa non rappresenta una soluzione “chiavi in mano” per la modernizzazione dei sistemi core.

L’affidabilità dei sistemi transazionali non ammette margini di incertezza, e proprio qui emerge il limite intrinseco dei modelli probabilistici: l’AI può suggerire una soluzione sintatticamente corretta, ma priva della comprensione del contesto operativo e normativo in cui il programma agisce.

La supervisione umana rimane un requisito essenziale per tre ordini di motivi:

• Il rischio di allucinazioni tecniche: i Large Language Models possono generare codice che appare coerente ma che nasconde errori logici sottili, specialmente nella gestione delle eccezioni o nelle interazioni complesse con i database mainframe. Senza un esperto in grado di validare l’output dell’AI, il rischio di introdurre vulnerabilità o bug nei sistemi mission-critical aumenterebbe esponenzialmente, annullando i vantaggi della velocità di sviluppo.
• Decifrare il contesto e le regole non scritte: gran parte del codice COBOL esistente è frutto di stratificazioni decennali di logiche aziendali, spesso modificate per rispondere a specifiche crisi o normative locali ormai dimenticate. L’AI analizza il testo, ma l’uomo analizza il senso economico. Solo un professionista con esperienza di dominio può decidere se una vecchia funzione vada fedelmente tradotta o se debba essere ripensata per allinearsi ai nuovi obiettivi strategici dell’azienda.
• Governance e responsabilità: in settori regolamentati come quello bancario e assicurativo, la responsabilità ultima della conformità e della sicurezza del software non può essere delegata a un algoritmo. La competenza umana è necessaria per garantire che il processo di modernizzazione rispetti i criteri di audit e i requisiti di sicurezza previsti dalle normative nazionali e internazionali (come il regolamento DORA).

In definitiva, l’intelligenza artificiale deve essere considerata un copilota, non un pilota automatico. La modernizzazione di successo nasce dalla sinergia tra la capacità di calcolo e sintesi dell’AI e il giudizio critico degli sviluppatori, gli unici in grado di trasformare una conversione tecnica in un’evoluzione strategica sostenibile.

Come impostare un progetto di modernizzazione COBOL

L’avvio di un progetto di modernizzazione non deve essere inteso come un evento puramente tecnologico, ma come un’operazione di gestione del rischio e del valore.

Data la criticità dei sistemi coinvolti, l’approccio più efficace è quello incrementale, che permette di ottenere benefici tangibili in tempi brevi senza esporre l’organizzazione a shock operativi. Una strategia di successo deve necessariamente seguire un percorso strutturato in fasi chiare.

Il framework operativo consigliato si articola nei seguenti passaggi:

• Assessment e Discovery (analisi del patrimonio): la prima fase consiste nel censire l’intero portafoglio applicativo per identificare cosa deve essere modernizzato, cosa può restare sul mainframe e cosa può essere dismesso. In questa fase si utilizzano tool di analisi automatica per mappare le dipendenze e quantificare il debito tecnico, definendo le priorità in base al valore di business e alla complessità tecnica.
• Definizione della Target Architecture: è fondamentale stabilire l’obiettivo finale. Si punta a un rehosting nel cloud, a un’esposizione tramite API o a una migrazione verso Java? La scelta dipende dagli obiettivi strategici: se l’azienda cerca agilità nel lancio di nuovi servizi, l’esposizione tramite API o il refactoring sono spesso le strade più remunerative.
• Modernizzazione Incrementale (Roadmap a fasi): invece di un approccio “big bang”, si procede per piccoli blocchi logici o funzionali. Si inizia dai servizi meno critici o da quelli che offrono il maggior ritorno immediato (ad esempio, l’integrazione di un database legacy con un nuovo portale clienti), validando ogni passaggio prima di procedere al successivo.
• Test e validazione continua: data la precisione richiesta dal COBOL, ogni modulo modernizzato deve essere sottoposto a rigorosi test di regressione. L’utilizzo di pipeline DevOps e test automatizzati garantisce che la nuova versione mantenga la medesima integrità transazionale del codice originale.
• Governance e gestione del cambiamento: parallelamente agli aspetti tecnici, occorre gestire il trasferimento delle competenze. Formare il team IT sulle nuove tecnologie e documentare i processi modernizzati assicura che l’azienda possa mantenere il controllo sul nuovo ecosistema senza creare nuove forme di dipendenza.

Impostare correttamente il progetto significa, in ultima analisi, trasformare un’eredità pesante in una piattaforma abilitante, capace di sostenere la crescita futura dell’azienda con costi prevedibili e rischi controllati.

Discovery applicativa

La Discovery applicativa rappresenta la fase analitica preliminare, e probabilmente la più critica, di ogni percorso di modernizzazione. In sistemi che si sono stratificati per oltre quarant’anni, la conoscenza del software è spesso frammentata o dispersa; la discovery ha l’obiettivo di ricostruire questa mappa logica, trasformando un patrimonio oscuro in un inventario trasparente e azionabile.

Un processo di discovery efficace si sviluppa su tre direttrici analitiche:

• Analisi statica e gerarchica: attraverso l’uso di tool automatizzati, vengono scansionate milioni di righe di codice per identificare tutti i componenti del sistema (programmi, copybook, JCL, file e tabelle DB2). Questo permette di mappare le interdipendenze: capire, ad esempio, quali programmi chiamano una specifica subroutine o quali processi batch impattano su determinati set di dati.
• Identificazione della Business Logic: non tutto il codice ha lo stesso valore strategico. La discovery permette di distinguere tra funzioni puramente tecniche (come la gestione dei file) e regole di business vitali (come il calcolo di un tasso d’interesse o di una franchigia assicurativa). Questo “carotaggio” informativo è essenziale per decidere cosa meriti un refactoring profondo e cosa possa essere mantenuto tal quale.
• Valutazione della complessità e del rischio: in questa fase vengono calcolate metriche oggettive, come la complessità ciclotomatica e il volume di “codice morto” (porzioni di software mai eseguite ma che appesantiscono la manutenzione). Questi dati permettono di stimare con precisione chirurgica l’impegno economico e i tempi necessari per la migrazione, trasformando le ipotesi in un piano industriale solido.

Senza una corretta discovery applicativa, il rischio è di navigare a vista, sottostimando le connessioni nascoste e sovrastimando la semplicità del passaggio verso nuove architetture. Al contrario, una mappatura accurata riduce drasticamente l’incertezza, garantendo che ogni intervento sia mirato e che la stabilità del sistema core non venga mai messa a repentaglio.

Mappatura dipendenze

All’interno di un ecosistema mainframe, nessun programma COBOL agisce come un’entità isolata. La mappatura delle dipendenze è l’attività tecnica che permette di tracciare i legami invisibili tra il codice sorgente, le strutture dati e i flussi di esecuzione. Senza questa visione d’insieme, qualsiasi intervento di modernizzazione rischia di innescare il cosiddetto “effetto domino”, dove la modifica di una singola riga di codice provoca il malfunzionamento di processi apparentemente non correlati.

Una mappatura rigorosa deve coprire tre livelli di interconnessione:

• Dipendenze Applicative (Call Tree): si tratta di ricostruire l’albero delle chiamate tra i diversi moduli. Un programma principale può richiamare decine di subroutine, che a loro volta attingono a file di configurazione o tabelle comuni. Mappare queste relazioni è fondamentale per definire il perimetro di un test di regressione e per decidere quali moduli devono essere migrati simultaneamente.
• Dipendenze dai dati (Data Flow Analysis): questo livello analizza come l’informazione fluisce attraverso il sistema. Identifica quali programmi leggono o scrivono su specifici dataset, file VSAM o tabelle DB2. Questa conoscenza è vitale quando si decide di modernizzare il database o di spostare i dati sul cloud, poiché permette di garantire che l’integrità referenziale e la coerenza transazionale siano mantenute durante e dopo la transizione.
• Dipendenze operative (JCL e Batch Scheduling): spesso trascurate, le dipendenze racchiuse nei Job Control Language (JCL) definiscono la sequenza temporale e logica delle operazioni. Capire come i job batch sono concatenati e quali risorse hardware richiedono è essenziale per replicare la stessa affidabilità operativa in un ambiente modernizzato o distribuito.

L’output di questa fase è solitamente un grafo delle dipendenze, un documento tecnico che trasforma la complessità del legacy in uno schema logico comprensibile. Disporre di una mappatura accurata significa poter pianificare la modernizzazione con un approccio chirurgico, riducendo al minimo i tempi di fermo macchina e assicurando che la business continuity rimanga solida durante l’intera evoluzione dell’architettura.

Identificazione regole di business

L’identificazione delle regole di business (Business Rules Extraction) è il processo di traduzione della logica algoritmica racchiusa nel COBOL in concetti di business comprensibili e documentati.

In molti sistemi legacy, il codice è l’unica fonte della verità rimasta: le specifiche originali sono spesso andate perdute e le regole che governano calcoli fiscali, criteri di affidabilità creditizia o algoritmi di pricing esistono solo sotto forma di istruzioni procedurali stratificate.

Estrarre correttamente queste regole è fondamentale per garantire che la versione modernizzata dell’applicazione continui a operare secondo i requisiti normativi e commerciali dell’azienda. Il processo si articola su tre fasi chiave:

• Isolamento della logica decisionale: attraverso l’analisi del flusso di controllo, vengono identificate le strutture condizionali (istruzioni IF-THEN-ELSE o EVALUATE) che determinano il comportamento del sistema. L’obiettivo è separare la logica puramente tecnica — come la gestione della memoria o dei file — dalle regole che definiscono, ad esempio, se un cliente ha diritto a un rimborso o come viene calcolata una penale.
• Decodifica dei calcoli proprietari: molti programmi COBOL contengono formule matematiche complesse, ottimizzate per la precisione decimale, che riflettono decenni di prassi aziendali. Identificare queste formule significa mappare le variabili di input, le costanti utilizzate e le logiche di arrotondamento, assicurando che la loro trasposizione in linguaggi moderni non generi discrepanze finanziarie.
• Validazione con gli stakeholder di dominio: una volta estratte, le regole devono essere validate dai responsabili delle linee di business (LOB). Questo passaggio permette di verificare se una regola codificata trent’anni fa sia ancora valida o se la modernizzazione sia l’occasione giusta per semplificarla o aggiornarla secondo le attuali esigenze di mercato.

Identificare le regole di business trasforma un’operazione di migrazione tecnica in un’opportunità di Business Process Re-engineering. Documentare ciò che il software “sa fare” permette all’azienda di riappropriarsi della propria proprietà intellettuale, rendendola indipendente dalle singole tecnologie e pronta per future evoluzioni.

Refactoring e test: garantire qualità e coerenza funzionale

Il refactoring e il testing rappresentano la fase operativa in cui la modernizzazione prende corpo, trasformando il codice COBOL in una struttura più agile e manutenibile. In questa fase, l’obiettivo non è modificare cosa il sistema fa, ma ottimizzare come lo fa. Un refactoring efficace riduce la complessità del codice, elimina le ridondanze e prepara il terreno per l’integrazione con architetture moderne, ma la sua riuscita dipende interamente dalla robustezza della strategia di test.

Il binomio refactoring-test si sviluppa attraverso tre pilastri fondamentali:

• Ristrutturazione del codice (Clean Coding): il refactoring interviene per scomporre i programmi monolitici in moduli più piccoli e riutilizzabili. Si eliminano le istruzioni obsolete, si standardizzano le denominazioni delle variabili e si isolano le logiche di accesso ai dati. Questo processo riduce drasticamente il debito tecnico e rende il sistema comprensibile anche a chi non ha una formazione specifica sul COBOL, facilitando la futura manutenzione.
• Test di regressione e comparazione (Gold Standard): per garantire che il refactoring non abbia alterato la logica di business, si applica il test di comparazione. Si eseguono gli stessi dati di input sia sulla versione originale (“Gold”) che su quella modernizzata, confrontando i risultati (output, file prodotti, aggiornamenti ai database) bit per bit. Ogni minima divergenza viene analizzata e corretta per assicurare una coerenza funzionale del 100%.
• Automazione e Continuous Integration (CI/CD): la modernizzazione offre l’opportunità di introdurre metodologie moderne come il testing automatizzato. Creando suite di test che possono essere eseguite a ogni minima modifica, l’azienda riduce i tempi di validazione e aumenta la fiducia nella stabilità del sistema. Questo approccio trasforma il mainframe da un ambiente statico a una piattaforma dinamica, capace di supportare rilasci più frequenti e sicuri.

In ultima analisi, il refactoring senza un piano di test rigoroso è un rischio inaccettabile; al contrario, un processo di trasformazione guidato dai test (Test-Driven Modernization) permette di evolvere il sistema core con la certezza matematica di preservare l’integrità dei dati e la continuità dei processi aziendali.

Migrazione graduale e governance: l’approccio Step-by-Step

La scelta di una migrazione graduale si contrappone alla rischiosa strategia del Big Bang, offrendo un percorso di modernizzazione che privilegia la continuità operativa e la sostenibilità finanziaria. In questo modello, il sistema COBOL non viene spento integralmente, ma “eroso” ai margini: i moduli vengono migrati o trasformati uno alla volta, mantenendo una coesistenza ibrida tra il vecchio e il nuovo. La governance diventa quindi il timone necessario per coordinare questo passaggio, assicurando che l’evoluzione tecnologica rimanga allineata agli obiettivi di business.

Una corretta gestione della migrazione graduale poggia su tre pilastri di governance:

• Interoperabilità e coesistenza: durante la fase di transizione, il nuovo codice (ad esempio in Java o su Cloud) deve dialogare costantemente con il core legacy rimasto sul mainframe. La governance deve garantire l’integrità dei dati attraverso strati di integrazione robusti, assicurando che le transazioni siano sincronizzate e che non si verifichino inconsistenze tra i diversi database.
• Gestione del rischio e Rollback: ogni fase della migrazione deve prevedere un piano di mitigazione del rischio. L’approccio graduale permette di isolare eventuali malfunzionamenti in un singolo perimetro funzionale, facilitando procedure di rollback (ritorno alla versione precedente) rapide e sicure, senza impattare sull’intera infrastruttura aziendale.
• Gestione del cambiamento (Change Management): la governance deve monitorare l’impatto della trasformazione sulle persone. Mentre la tecnologia cambia, le competenze interne devono evolvere: è necessario pianificare il trasferimento di conoscenza dai “seniores” del COBOL ai nuovi sviluppatori, evitando la creazione di nuovi silos informativi e garantendo che il team IT sia in grado di manutenere l’architettura ibrida.

In definitiva, la migrazione graduale trasforma un evento traumatico in un processo di miglioramento continuo. Attraverso una governance attenta, l’azienda può distribuire l’investimento economico nel tempo, misurando il ROI di ogni singolo modulo modernizzato e adattando la strategia in base ai risultati ottenuti, riducendo drasticamente le probabilità di fallimento sistemico.

Checklist per CIO e IT manager

Per un CIO o un IT Manager, la modernizzazione del COBOL non è solo una sfida tecnica, ma una decisione di allocazione del capitale e gestione del rischio. Prima di impegnare risorse in un progetto di tale portata, è fondamentale sottoporre la strategia a una validazione rigorosa. La seguente checklist rappresenta un framework decisionale per garantire che l’iniziativa sia sostenibile, sicura e orientata al valore.

Valutazione strategica e finanziaria

• Analisi del TCO (Total Cost of Ownership): avete confrontato i costi di mantenimento del mainframe (canoni MIPS, licenze, specialisti) con i costi operativi post-migrazione (canoni Cloud, gestione architetture distribuite)?
• Definizione del valore di business: il progetto serve a ridurre i costi, a migliorare l’agilità del time-to-market o a mitigare il rischio di obsolescenza delle competenze? Ogni obiettivo richiede un approccio tecnico differente.
• Mappatura delle competenze: esiste un piano per il trasferimento del know-how dai tecnici senior ai nuovi sviluppatori? Avete valutato l’impatto sulla cultura aziendale nel passaggio da logiche waterfall a metodologie DevOps?

Sicurezza e continuità operativa

• Compliance e Data Sovereignty: la nuova architettura rispetta i vincoli normativi (GDPR, DORA, regolamenti settoriali) per la gestione e la residenza dei dati sensibili?
• Piano di Business Continuity: è stato definito un protocollo di rollback immediato in caso di fallimento di un modulo migrato? Come viene garantita la coerenza dei dati durante la fase di coesistenza ibrida?
• Integrità Transazionale: avete strumenti di testing automatizzato capaci di validare la precisione dei calcoli (Gold Standard test) tra il vecchio e il nuovo sistema?

Governance tecnica

• Inventory e Discovery: disponete di una mappatura aggiornata e automatizzata di tutte le dipendenze applicative (JCL, Copybook, DB2)?
• Selezione dei Partner e dei Tool: gli strumenti di AI o di conversione automatica scelti offrono garanzie di supporto a lungo termine o introducono nuovi vincoli di vendor lock-in?
• Roadmap Incrementale: il progetto è diviso in fasi che rilasciano valore misurabile ogni 3-6 mesi, o è impostato come un rischioso rilascio “Big Bang”?
• Le applicazioni COBOL sono documentate?
• Esistono sviluppatori interni con competenze COBOL?
• Quali processi business dipendono dal mainframe?
• Quali moduli possono essere esposti via API?
• Quali parti possono essere refactorizzate?
• Esiste una strategia di test regression?
• L’AI viene usata come supporto o come sostituto del processo?

Gestire questa checklist con trasparenza permette di trasformare una migrazione complessa in un percorso governato, dove ogni passo è giustificato da un ritorno sull’investimento chiaro e da un profilo di rischio accettabile per l’organizzazione.

COBOL è destinato a sparire?

La questione della presunta “morte” del COBOL è un tema ricorrente nel dibattito tecnologico da almeno tre decenni, eppure i dati macroeconomici suggeriscono una realtà ben diversa. Nonostante l’emergere di linguaggi più agili e moderni, il COBOL non sta scomparendo; al contrario, sta attraversando una fase di “modernizzazione resiliente”. La sua longevità non è dovuta a una mancanza di alternative, ma all’eccezionale efficienza con cui gestisce i volumi transazionali critici che reggono l’economia globale.

L’analisi della permanenza del COBOL nel panorama IT si fonda su tre pilastri:

• Evoluzione verso il Cloud Ibrido: il COBOL moderno non è più confinato a terminali a fosfori verdi. I principali fornitori di tecnologia hanno reso il linguaggio capace di integrarsi con container, microservizi e pipeline DevOps. Oggi, un’applicazione COBOL può girare su un mainframe moderno che dialoga nativamente con il cloud pubblico, trasformando il linguaggio da “eredità pesante” a componente stabile di un’architettura Hybrid IT.
• Il problema del ricambio generazionale: La vera minaccia alla sopravvivenza del COBOL non è tecnologica, ma demografica. La progressiva uscita dal mercato del lavoro degli sviluppatori esperti sta creando un vuoto di competenze. Tuttavia, questo scenario sta spingendo le aziende verso l’adozione di strumenti di AI generativa e documentazione automatica, che permettono a una nuova generazione di programmatori (spesso orientati a Java o Python) di interagire con il codice legacy senza doverne padroneggiare ogni segreto sintattico.

In conclusione, il COBOL non è destinato a sparire, ma a diventare invisibile. Continuerà a esistere come strato fondamentale di calcolo, sempre più interconnesso e mediato da interfacce moderne. La sfida per le aziende non è dunque la sua eliminazione, ma la sua integrazione in un ecosistema digitale fluido, dove la stabilità del passato incontra la velocità del futuro.

Quali approcci per la trasformazione

La spinta a mettere mano a questo immenso patrimonio legacy, spesso scarsamente documentato, deriva dai costi crescenti della manutenzione applicativa anche a causa dello shortage di competenze soprattutto per ragioni anagrafiche. I programmatori COBOL sono andati in pensione o ci andranno a breve, mentre le nuove leve sono formate su linguaggi di nuova generazione.

La sfida è trovare un equilibrio fra la modernizzazione applicativa, necessaria per rispondere all’agilità richiesta dalle esigenze del business, e la capacità di preservare le funzionalità esistenti e l’integrità dei dati. La prima domanda che si pongono le organizzazioni è dunque se trasformare il patrimonio COBOL in un linguaggio più moderno o se riscriverlo da zero.

La riscrittura di un’applicazione legacy ha però senso solo se la logica di business è obsoleta; richiede infatti tempi lunghi, molti mesi o più probabilmente anni, per essere completata, costi e rischi elevati. D’altra parte, anche la conversione del COBOL linea per linea non è probabilmente una buona idea, visto che i nuovi linguaggi hanno logiche del tutto differenti. Java, ad esempio, segue modelli e best practice del tutto incompatibili con quelli del COBOL.

Un’alternativa potrebbe essere la disponibilità di uno strumento che in automatico fosse in grado di estrarre le regole di business anche secomporterebbe comunque una riscrittura con tempi e costi di poco inferiori, sfruttando le competenze su linguaggi moderni, e probabilmente rischi più contenuti.

Un’opzione più attraente potrebbe essere uno strumento di conversione automatica da COBOL a un codice moderno. Tuttavia, i prodotti disponibili sul mercato che lo promettevano non hanno finora soddisfatto le aspettative. Non c’è dunque da stupirsi che la scelta prevalente sia stata finora la conservazione delle applicazioni esistenti.

Un’indagine globale indipendente, condotta da Vanson Bourne e commissionata da MicroFocus (oggi OpenText), conferma che la modernizzazione delle applicazioni è considerata la scelta preferenziale. Anziché un approccio di sostituzione, il 64% degli intervistati intende infatti modernizzare le proprie applicazioni COBOL e il 72% degli intervistati vede questa scelta come una strategia aziendale complessiva, visto che il 92% delle organizzazioni intervistate ritiene che il codice COBOL tuttora attivo rivesta un’importanza strategica per il business.

Va anche detto che IBM ha introdotto il watsonx Code Assistant for Z, uno strumento basato su AI generativa che supporta la trasformazione del codice COBOL in Java, migliorando la produttività degli sviluppatori e riducendo i rischi associati alla modernizzazione. Inoltre è stato sviluppato XMainframe, un LLM per la modernizzazione dei mainframe in grado di comprendere e interagire con sistemi legacy basati su COBOL. L’industria si sta quindi muovendo per “modernizzare” questi storici ambienti.

Il percorso suggerito da IBM per la modernizzazione del patrimonio COBOL

“Le organizzazioni chiedono agilità per offrire servizi nativi cloud e integrarli nel mondo esistente ma vogliono al tempo stesso conservare il loro patrimonio applicativo” conferma Francesco Casa, Vice President zStack, IBM Technology che abbiamo intervistato per avere il punto di vista del vendor sui cui mainframe risiede la maggior parte del codice COBOL e che ha recentemente lanciato uno strumento che supporta la conversione del linguaggio.

IBM, per vincere la sfida della carenza skill Cobol e superare il gap generazionale, ha da tempo lavorato per raggiungere l’uniformità degli strumenti di sviluppo grazie all’integrazione dei tool del mondo applicativo mainframe con quelli del mondo distribuito, con l’obiettivo di realizzare una catena di DevOps unica. Un salto significativo verso la modernizzazione applicativa potrebbe però arrivare con il lancio di uno strumento pensato per tradurre il COBOL in Java e, in prospettiva, qualunque linguaggio sorgente in qualunque linguaggio di destinazione, con il supporto dell’AI generativa. “WatsonX Code Assistant for Z non va però interpretato come una proposta di traduzione automatica dell’intero patrimonio di applicazioni”, avverte Casa. Si tratta piuttosto di un approccio metodologico strutturato che IBM propone come modello collaudato, per trasformare e validare, con basso rischio, applicazioni di grande impatto sul business. Il percorso, dove automazione e intervento umano si affiancano, prevede più fasi:

• Undestanding e discovery per capire le interdipendenze tra i diversi programmi realizzando la mappatura delle relazioni fra programmi;
• Refactor che permette di eliminare righe di codice non più attive e riscrivere una parte di codice COBOL in ottica microservizi;
• Trasform che impiega l’AI generativa per suggerire quali parti di codice sono più eleggibili per la trasformazione in Java;
• Explanation che arriverà nella seconda parte del 2024 e, grazie al supporto dell’AI generativa, produrrà documentazione in linguaggio naturale inglese per la parte che resterà in COBOL.

“In alcuni settori la richiesta non è tanto la trasformazione del codice quanto la capacità di riappropriarsi della conoscenza di questo importante patrimonio di applicazioni”, sottolinea Casa. Più in generale, l’obiettivo delle aziende che hanno come priorità la salvaguardia del business, sembra essere ottimizzare il codice COBOL e documentare cosa fa e come impatta.

“Ci aspettiamo, sulla base delle prime sperimentazioni, che in media solo il 30% del codice venga tradotto in Java e il restante 70% sia trasformato da COBOL in COBOL ottimizzato”, precisa Casa.

Il mainframe continuerà ad avere un ruolo da protagonista ospitando non solo le applicazioni COBOL ringiovanite, ma anche le applicazioni tradotte in Java nel caso operino su dati ospitati sul mainframe per garantire, grazie alla vicinanza, le performance. Verrebbe così sfruttata la sua capacità di ospitare applicazioni native containerizzate su motori specializzati, i cosiddetti zIIP (z Integrated Information Processor), che non seguono la logica tradizionale del sistema operativo mainframe z/OS ma sono container su cui far girare traffico Java.

In conclusione, come la notizia della morte del mainframe, diffusa qualche anno fa, era largamente prematura, così oggi quella del superamento del COBOL che, rinnovato, ha davanti a sé ancora lunga vita.