BPER Banca ha completato la migrazione dei servizi di core banking su LzLabs Software Defined Mainframe, con un trasferimento incrementale verso sistemi aperti che non ha richiesto ricompilazione o modifica dei dati. Un progetto che rientra nell’obiettivo di rivedere l’infrastruttura tecnologica della banca per superare i limiti del sistema mainframe in essere (e del budget IT) e restare competitivi nell’attuale scenario sfidante di mercato. AziendaBanca ne ha parlato con Omar Campana, Group Chief Information Officer di BPER Banca.
Domanda. Dottor Campana, quale valore strategico ha per una banca, di fronte all’evoluzione competitiva e normativa, il superamento dei sistemi legacy e dei loro limiti?
Risposta. Sono numerosi gli aspetti da considerare in un progetto di modernizzazione tecnologica, anche quando riguarda la piattaforma mainframe. Il passaggio da un ambiente legacy a uno distribuito porta con sé una serie di vantaggi, legati a una più stretta correlazione di eventi e procedure, che possono e debbono essere condivisi tra diversi ambiti operativi, come ad esempio IT e Business. È un cambio di approccio, per iniziare, con l’adozione della metodologia DevOps, che diventa necessariamente DevSecOps, per l’importanza fondamentale che un approccio security by design ha in questo ambito. Altro elemento rilevante nel passaggio a un ambiente distribuito è quello dell’automazione, che diventa tanto più cruciale quanto è ricco lo scenario di interazioni del nuovo ambiente. DevSecOps e automazione diventano abilitatori per l’innovazione, gettando di fatto le basi per la creazione di un ambiente moderno, distribuito, resiliente e performante.
D. Ci sono anche freni culturali o interni all’organizzazione della banca, quando si tratta di superare i sistemi legacy?
R. Non parlerei di freni culturali o organizzativi, quanto piuttosto di gestione del rischio operazionale, come problema concreto che ci siamo posti. Ovvero: il progetto di evoluzione e migrazione non doveva mettere a rischio l’operatività del Gruppo. Nel momento della migrazione dei diversi sistemi, non dovevano esserci disruption di nessun tipo. (I dati, durante la prima fase, sono rimasti sul mainframe di BPER e il passaggio ha richiesto un’interruzione del servizio minima, senza ricompilazione o modifica, NdR).
D. Avete definito una roadmap per la migrazione? A che punto siete?
R. Dopo un’analisi approfondita degli ambiti, si è deciso di procedere su due direttrici fondamentali: da un lato, come detto, la necessità di trovare una modalità di lavoro, graduale, che consentisse di azzerare i rischi operativi, dall’altro la scelta di selezionare gli ambiti sui quali intervenire tra quelli che ci garantivano i risultati più evidenti, con operazioni tutto sommato contenute. Abbiamo iniziato dai servizi per così dire complementari, in modo da verificare via via la resilienza dei sistemi e gli effetti postivi della migrazione. Che è stata condotta in questa prima fase su funzionalità di lettura, e non di scrittura, per lo stesso motivo.
D. Nello specifico di questo progetto, il protagonista è il mainframe, punto di riferimento storico del settore Finance. Come state gestendo la migrazione ad altri sistemi?
R. Se parliamo di migrazione pura, ovvero di replatforming, il partner di riferimento è LzLabs. Il tema dell’evoluzione dei sistemi legacy è un argomento che ci tocca ormai da anni, e sul quale l’IT di BPER ha definito nel tempo una strategia ben chiara. Innanzitutto, in termini di indirizzo tecnologico, il Gruppo ha adottato un approccio Open Source-first, con un uso molto spinto di microapplicazioni e microservizi. Parallelamente, BPER ha da sempre adottato in modo deciso la virtualizzazione e negli ultimi anni esteso la containerizzazione, proprio con l’obiettivo di ottenere agilità e resilienza, nonché di fornire un supporto sempre più efficace e puntuale al business. DevOps è un altro aspetto fondamentale del nostro IT, con focalizzazione su Continuous Integration/Continuous Delivery (CI/CD).
D. Avete anche individuato soluzioni o applicativi che non saranno migrati?
R. Allo stato attuale non ci sono applicativi per cui è stato preventivamente deciso che resteranno su sistema legacy. La migrazione è stata graduale e scandita anche dalle diverse opportunità di progetto che via via si presentavano, magari guidate da esigenze di business, per il risultato di un’esperienza win-win su entrambi gli ambiti. (Nella prima fase del progetto, sono stati migrati i servizi che controllano i portali front-end di BPER, grazie a cui filiali e utenti gestiscono online banking e carte di credito: entro fine del 2021, saranno migrati anche test di sistema e produzione, NdR).
D. Che tempistiche ha avuto il progetto e quale ruolo hanno svolto le risorse interne e quelle esterne?
R. In fase di avvio del progetto, in collaborazione e di concerto con LzLabs, abbiamo creato un prototipo, un sistema reale che permetteva di testare sul campo le prestazioni applicative nel nuovo scenario. Questo ha richiesto 3/4 mesi, con un duplice risultato: ci ha permesso di verificare il corretto funzionamento delle nuove correlazioni e ha generato entusiasmo nel team, che ha potuto vedere dall’inizio i vantaggi concreti di questa iniziativa, dando di fatto nuova spinta al suo completamento. Il progetto vero e proprio ha poi richiesto approssimativamente 12 mesi, con un coinvolgimento continuo e costante delle diverse parti in causa: LzLabs in quanto owner del prodotto e della piattaforma; CWS, system integrator, per l’implementazione del progetto; BPER con governance complessiva e ownership delle competenze specifiche di ambito.
D. La pandemia di Covid-19 ha in qualche modo rallentato od ostacolato il progetto di migrazione?
R. Proprio per la particolare complessità del progetto, e per la forte collaborazione tra le parti necessaria al suo successo, l’esplosione della pandemia ha portato qualche difficoltà aggiuntiva, superata facendo riferimento alle piattaforme e tecnologie di team collaboration. Un progetto così innovativo, a forte componente collaborativa, ha indubbiamente risentito dell’impossibilità di operare fianco a fianco come invece sarebbe stato in condizioni normali, ma sono state implementate modalità di lavoro che hanno consentito di superare in modo agevole anche questo ostacolo.
D. Un tema chiave nel rapporto tra banche e mainframe è quello delle competenze interne. Come lo gestite in BPER Banca?
R. Questo è un problema di fondo, che esula da progetti specifici e che riguarda il banking nel complesso. Un problema che in BPER ci siamo posti già diversi anni fa, quando ci siamo resi conto che i canali di recruiting tradizionali portavano risultati non più soddisfacenti rispetto alle nostre esigenze specifiche. Da circa 2 anni e mezzo abbiamo avviato una sperimentazione, in partnership con una realtà specializzata nel mondo HR: ci siamo rivolti ai neodiplomati e agli studenti neoiscritti all’università, abbiamo creato delle classi di 15/20 persone e abbiamo avviato un progetto di formazione in aula, dedicato a tecnologie legacy, a partire da Cobol Cics DB2, e seguito nella sua parte finale direttamente da esperti BPER. L’accordo era che avremmo avuto la prelazione sul possibile inserimento degli studenti una volta completato il loro percorso di formazione. Il risultato è stato doppiamente positivo: da un lato siamo stati in grado di inserire nel nostro team IT oltre 20 giovani programmatori, con una formazione del tutto in linea con le nostre esigenze operative; dall’altro l’ingresso di questa nuova generazione di specialisti ha di fatto dato grande spinta anche ai programmatori già presenti in azienda, che hanno beneficiato in modo più che significativo dell’energia, dell’entusiasmo e delle idee fresche dei nuovi arrivati.
D. Tra gli obiettivi del progetto c’è conquistare maggiore agilità nei processi per ridurre il go-to-market di prodotti e soluzioni. In quali altri ambiti state lavorando per migliorare la collaborazione tra macchina IT e business per restare competitivi nel contesto open?
R. La catena di delivery è fondamentale per ridurre il go-to-market. Un ruolo realmente abilitante è dato dall’adozione di pratiche DevOps a ogni livello del progetto: quando esiste una reale co-progettazione, ovvero IT e Business operano insieme fin dai primi step, il vantaggio in termini di efficienza e rapidità è sostanziale. A questo si aggiunge il valore dell’automazione, che diventa sempre più spinta, tanto che si inizia a parlare di iper-automazione. Possiamo quindi dire che coprogettazione e automazione sono le basi per una nuova competitività di business.
