Perché la modernizzazione dei sistemi legacy non è un problema tecnico. È un problema umano.
Il bancomat che non conosci
Stamattina hai prelevato al bancomat. Hai digitato il PIN, scelto l’importo, preso le banconote. Trenta secondi netti. Non hai pensato a cosa c’è dietro e perché dovresti?
Eppure dietro quei trenta secondi gira codice COBOL. Non solo negli Stati Uniti, dove gestisce il 95% delle transazioni ATM. Il 43% dei sistemi bancari mondiali si basa ancora su COBOL. L’80% delle transazioni con carta di credito in presenza passa attraverso codice scritto in questo linguaggio. Ogni giorno, sistemi COBOL elaborano transazioni per oltre 3.000 miliardi di dollari.
E il problema non è solo americano. In Europa, colossi come HSBC e ABN AMRO utilizzano ancora COBOL nei loro sistemi core. Il 70% delle grandi corporation — banche, assicurazioni, enti governativi — dipende da questo linguaggio per le operazioni mission-critical. Nel Regno Unito, diverse banche stanno già affrontando problemi IT concreti: blocchi nell’accesso ai conti e malfunzionamenti nei pagamenti, tutti riconducibili a infrastrutture obsolete.
Il numero di persone che sa leggere quel codice diminuisce ogni anno.
Non è un allarme nuovo, esiste da almeno un decennio. Ma c’è una differenza tra sapere che un ponte è vecchio e rendersi conto che l’ultimo ingegnere che ne capiva la struttura è andato in pensione cinque anni fa, portandosi via i disegni.
La paura di toccare ciò che funziona
Se lavori nella Information Technology, conosci questa dinamica: sistemi che nessuno osa modificare perché “funzionano”. Flussi di dati costruiti vent’anni fa, rattoppati decine di volte, con documentazione, se esiste, mai aggiornata.
Toccare un sistema COBOL in produzione significa assumersi un rischio che nessuno vuole quantificare. Significa fare reverse engineering di logica di business scritta quando Nixon era presidente. Chi ha costruito quei sistemi sapeva cosa faceva. Ma quella conoscenza era nelle loro teste, non nella documentazione. E quando sono andati in pensione, se la sono portata via. Il codice è rimasto ma il significato, no.
Chiediti: quanti dei tuoi sistemi aziendali hanno la stessa dinamica? Quante procedure vivono solo nella memoria di chi le ha scritte?
Il vero costo dell’immobilismo
Un tempo, modernizzare un sistema COBOL significava una cosa sola: eserciti di consulenti. Mesi di analisi. Anni di implementazione. Budget che facevano impallidire i CFO. E un rischio residuo enorme, perché mappare manualmente migliaia di dipendenze implicite —file condivisi, stati globali, sequenze di inizializzazione che influenzano il comportamento a runtime — è un’impresa laboriosa e difficile. Il risultato? Paralisi. Si continua a rattoppare. Si aggiungono strati su strati. E il debito tecnico cresce silenziosamente, come una crepa nel muro che ignori finché non diventa strutturale. Ma più aspetti, più diventa costoso intervenire e più è costoso, più aspetti.
E quando finalmente qualcuno si muove, il rischio si materializza. Nel 2018 la banca britannica TSB fu costretta a migrare da un sistema COBOL a causa di un’acquisizione. Il risultato fu un disastro: sistemi in tilt per settimane, frodi per 49 milioni di sterline, compensazioni ai clienti per 125 milioni, oltre 200.000 reclami e le dimissioni del CEO. La Commonwealth Bank of Australia ci aveva messo cinque anni e quasi 750 milioni di dollari.
L’intelligenza artificiale come lente, non come bacchetta magica
L’AI non riscrive magicamente il COBOL in Java. Cambia l’economia della fase che ha sempre reso proibitiva la modernizzazione: l’esplorazione. Strumenti di AI specializzati possono leggere un intero codebase, mapparne la struttura, tracciare percorsi di esecuzione e individuare dipendenze implicite che non emergono dall’analisi statica — strutture dati condivise, accoppiamenti nascosti, stati globali che nessuno ricorda. Sono esattamente ciò che rende pericolosa ogni migrazione. E l’AI sa trovarle.
Da lì, il metodo è quello che chiunque abbia fatto migrazioni enterprise conosce: incrementale, un componente alla volta, con test prima di ogni modifica e codice vecchio e nuovo che girano fianco a fianco. Ogni passaggio validabile e soprattutto reversibile.
Ma l’AI non prende decisioni. Mappa. Documenta. Suggerisce priorità. La tolleranza al rischio della tua organizzazione, i vincoli normativi, il valore di business — quelli li conosci tu. E la decisione resta tua.
Il rischio è ….
L’AI riduce i tempi di analisi da anni a trimestri, è vero, ma la fase umana (requisiti normativi, priorità di business, validazione con gli esperti di dominio) quella non si comprime.
E il vero collo di bottiglia non è mai stato solo tecnico. È convincere un board che il rischio di NON modernizzare supera ormai il rischio di farlo. È gestire il terrore silenzioso di chi lavora con quei sistemi da trent’anni e vede nella modernizzazione una minaccia alla propria rilevanza.
L’AI risolve il problema dell’analisi. Il problema della decisione resta tutto nostro.
Probabilmente il COBOL non è tuo problema
Magari non hai sistemi COBOL. Ma hai sistemi che nessuno vuole toccare. Documentazione che non riflette più la realtà. Flussi che funzionano “per ragioni storiche”. Allora anche tu prima o poi dovrai affrontare il problema … quindi cerca di usare l’AI nel modo migliore.
