Modernizzazione Legacy in banca tier 1

Contesto

Un istituto finanziario tier-1 europeo esegue i suoi processi di calcolo finanziario critico (rischio, tesoreria, valutazione) su un core Oracle con logica in PL/SQL, un grid IBM Spectrum Symphony e sistemi di mercato come Murex e Algorithmics. È un'operatività 24/7: non esiste una finestra in cui il sistema possa fermarsi.

Il core era cresciuto negli anni sotto forma di monoliti PL/SQL difficili da far evolvere, con deployment manuali e processi il cui tempo di esecuzione non rientrava più nelle finestre di business. L'obiettivo era ridurre quei tempi e modernizzare il modo di rilasciare il software senza toccare la disponibilità.

La sfida

Tre vincoli hanno segnato il progetto:

• Processi di calcolo finanziario critico con tempi insostenibili, che bloccavano le operazioni del business.
• Monoliti Oracle con PL/SQL critico fortemente accoppiato, senza possibilità di modificare un componente senza mettere a rischio l'insieme.
• Operatività 24/7 e integrazioni con Murex e Algorithmics che dovevano restare intatte durante tutta la transizione.

Approccio per fasi

La modernizzazione è stata eseguita come una successione di fasi controllate, ciascuna con validazione e capacità di rollback.

1. 01

   Diagnosi del codice e del grid

   Identificazione del PL/SQL che concentrava il tempo di calcolo e dell'utilizzo reale delle risorse del grid.

2. 02

   Refattorizzazione e disaccoppiamento

   Riscrittura del PL/SQL critico e separazione progressiva dei monoliti Oracle in componenti rilasciabili in modo indipendente.

3. 03

   Pipeline DevOps e GitOps

   Automazione dei deployment: ogni modifica versionata, testata e promossa in modo riproducibile.

4. 04

   Migrazione per fasi senza downtime

   Messa in produzione componente per componente, mantenendo le integrazioni con Murex e Algorithmics e l'operatività 24/7.

Architettura e strategia

Il principio è stato lo stesso che applichiamo negli altri progetti di banca tier-1: estendere e disaccoppiare invece di sostituire. Il grid Symphony e il core Oracle restano al loro posto; ciò che cambia è come viene distribuito il lavoro (utilizzo del grid) e come viene rilasciato il software (pipeline automatizzata al posto dei deployment manuali).

Risultati misurabili

Risultati validati in produzione:

Cifre aggregate e anonimizzate in base a un accordo di riservatezza. Fonte: progetti di Vermont Solutions.

Lezioni applicabili

• In un core 24/7 la migrazione per fasi con capacità di rollback non è opzionale: è l'unico modo di avanzare senza esporre il business.
• Automatizzare il rilascio (DevOps + GitOps) riduce gli errori e rende ogni deployment prevedibile e verificabile.
• Misurare l'utilizzo reale del grid prima di ampliarlo evita investimenti non necessari: il margine era nella distribuzione, non nell'hardware.

Quadro normativo

Il calcolo del rischio nella banca tier-1 è materia sottoposta a vigilanza; la modernizzazione è stata progettata per rafforzare l'evidenza di controllo.

• Basilea III/IV: calcoli di capitale e rischio entro le finestre richieste.
• DORA (art. 28): tracciabilità delle modifiche, resilienza operativa e gestione dei fornitori terzi ICT.
• BCBS 239: aggregazione dei dati di rischio con processi documentati e riproducibili.

Domande frequenti

Contenuti correlati

• Servizio: modernizzazione di sistemi legacy →
• Servizio: HPC e Grid Computing →
• Prodotto: add-on per IBM Spectrum Symphony →
• Caso: estensione dinamica del GRID al cloud in banca →