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. 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.
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.
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.
