Modernizzare il core senza fermare la banca: l’equivalenza si dimostra

Le applicazioni core — COBOL su mainframe, Java di vecchia generazione, Delphi o linguaggi di nicchia — sostengono il business da decenni. Mantenerle invariate costa ogni anno di più: MIPS e licenze in crescita, competenze che escono dall’organizzazione, canali digitali che faticano a innestarsi, tracciabilità difficile da produrre quando la chiede un audit.

Le promesse di riduzione dell’effort riguardano la scrittura del codice, che è la parte minore del problema. I progetti si fermano altrove: documentazione obsoleta, regole di business sepolte sotto strati di modifiche e rami morti, dipendenze non evidenti fra catene batch e partitari, e soprattutto la difficoltà di dimostrare che il nuovo sistema fa esattamente ciò che faceva il vecchio.

L’approccio che regge mette l’intelligenza artificiale dentro un progetto governato: gli agenti analizzano, generano e testano, mentre le persone validano i passaggi critici. La conoscenza viene ricostruita dal codice e certificata dagli esperti prima che qualcuno riscriva una riga, e una funzione pilota migrata a mano fissa architettura e standard per tutte le successive.

L’equivalenza non si dichiara, si misura. Significa verificare che il nuovo applicativo, a parità di dati in ingresso, produca gli stessi risultati del sistema precedente e rispetti le stesse regole di business. Il controllo riguarda sia le elaborazioni automatiche (batch) sia le operazioni eseguite dagli utenti online. Nel batch il programma originale, eseguito fuori dall’ambiente di produzione, fa da oracolo: stessi input, confronto degli output record per record. Nell’online si verifica sulla transazione di business, con test case quadrati sull’analisi funzionale e UAT con sign-off. È l’unico modo per spegnere il legacy con una decisione documentata invece che con un atto di fiducia.