Puntare sulla trasformazione digitale guidata dal mainframe per i servizi finanziari

Questa è la terza parte di una serie in cinque parti sulla modernizzazione dei mainframe.

Abbiamo già spiegato come la modernizzazione del mainframe non riguardi solo il settore finanziario, quindi perché non affrontare l'argomento più spinoso? Le maggiori sfide di modernizzazione a livello mondiale si concentrano nel settore bancario.

Prima di internet e del cloud computing, prima degli smartphone e delle app mobili, le banche effettuavano pagamenti tramite enormi gateway elettronici di regolamento e gestivano i mainframe come sistemi di registrazione.

Le società di servizi finanziari sono considerate istituzioni perché gestiscono e spostano gli aspetti fondamentali del nostro sistema economico globale. E il cuore pulsante degli istituti finanziari è il mainframe IBM.

Le banche hanno molto da guadagnare se riescono (e molto da perdere se falliscono) nel portare le loro applicazioni mainframe e il loro patrimonio di dati ai moderni standard di flessibilità, agilità e innovazione simili a quelli del cloud, per soddisfare la domanda dei clienti.

Negli ultimi tempi abbiamo vissuto incertezze economiche globali, dalla crisi del "troppo grande per fallire" del 2008 ai nostri attuali alti tassi di interesse post-pandemici che hanno causato sovraesposizione e insolvenza di alcune grandi banche depositanti.

Sebbene i fallimenti bancari siano spesso il risultato di cattive decisioni e politiche gestionali, vi sono buone ragioni per attribuire una parte della colpa a iniziative e strategie di modernizzazione tardive. I dirigenti non avrebbero potuto eseguire analisi migliori per individuare i rischi all'interno dei dati? Perché non hanno lanciato una nuova app mobile? Qualcuno li ha hackerati e ha bloccato i clienti?

Tutti sanno che rimandare la modernizzazione delle applicazioni mainframe significa perdere opportunità, ma c'è la convinzione generale che cambiare i sistemi che attualmente supportano le operazioni sia rischioso.

Le banche comunitarie e regionali potrebbero non disporre delle risorse tecniche necessarie, mentre gli istituti più grandi hanno un debito tecnico enorme, problemi di movimentazione dati di notevole entità o difficoltà con il business case.

Le banche, grandi e piccole, probabilmente hanno fallito su una o più iniziative di modernizzazione o migrazione. Con l'abbandono degli sforzi, i responsabili IT di queste organizzazioni hanno avuto la sensazione di aver fatto il passo più lungo della gamba.

Trasformare lo sforzo di modernizzazione non dovrebbe richiedere una riscrittura totale del codice mainframe, né un laborioso e costoso esercizio di trasformazione. Piuttosto, i team dovrebbero modernizzare ciò che ha senso per le priorità più importanti dell'azienda.

Ecco alcuni casi d'uso eccellenti di banche che sono andate oltre il semplice riavvio di iniziative di modernizzazione per migliorare in modo significativo il valore dei loro mainframe nel contesto di architetture software altamente distribuite e delle elevate aspettative di esperienza del cliente di oggi.

Molte banche temono di affrontare il debito tecnico all'interno dell'indirizzo mainframe esistente, che potrebbe essere stato scritto in COBOL o in altri linguaggi prima dell'avvento dei sistemi distribuiti. Spesso, gli ingegneri che hanno progettato il sistema originale non sono più presenti e le interruzioni dell'attività non sono una buona opzione, quindi i responsabili delle decisioni IT ritardano la trasformazione armeggiando nel livello intermedio.

Atruvia AG è uno dei principali fornitori di tecnologie per servizi bancari al mondo. Oltre 800 banche si affidano ai loro servizi innovativi per quasi 100 miliardi di transazioni annuali, supportate da otto sistemi IBM z15 che operano in quattro data center.

Invece di procedere con la sostituzione, hanno deciso di effettuare la rilocalizzazione sul posto, scrivendo servizi RESTful in Java insieme al COBOL esistente in esecuzione sui mainframe. Sostituendo gradualmente l'85% delle loro transazioni bancarie principali con il moderno Java, sono stati in grado di creare nuove funzionalità per i clienti della banca, migliorando al contempo le prestazioni dei workload sul mainframe di 3 volte.

La maggior parte delle banche ha un piano di protezione dei dati che include una qualche forma di ridondanza per il disaster recovery (DR), come una copia primaria del mainframe di produzione nel data center e magari una soluzione di backup secondaria o a nastro virtuale offsite che riceve un nuovo caricamento in batch a intervalli di qualche mese.

Poiché i volumi di dati aumentano inesorabilmente di dimensioni, con più transazioni ed endpoint applicativi, crearne copie tramite tecnologie di backup legacy diventa sempre più costoso e dispendioso in termini di tempo, e anche la loro ricostituzione è lenta, il che può creare un divario DR nei tempi di inattività. Esiste una esigenza critica di backup and recovery più tempestivi per mettere in sicurezza l'ambiente informatico della banca moderna, incluso ransomware.

ANZ, una delle cinque principali banche in Australia, ha cercato di aumentare la sua capacità di backup mainframe più tempestivi e prestazioni di DR più rapide per garantire un'elevata disponibilità per i suoi oltre 8,5 milioni di clienti.

Hanno sviluppato una capacità di resilienza, eseguendo server IBM® zSystems con mirroring utilizzando la funzione HyperSwap per abilitare scambi di storage multi-target senza interruzioni, poiché uno qualsiasi dei server identici può prendere in carico i workload di produzione se uno sta effettuando un backup o un ripristino.

La dirigenza IT di ANZ può contare su una maggiore tranquillità grazie a una migliore disponibilità del sistema; ma soprattutto, ora dispone di una moderna strategia di disaster recovery che può essere certificata per garantire la continuità aziendale ai propri clienti.

Le banche si affidano ad analytics avanzate per quasi ogni aspetto delle decisioni aziendali chiave che incidono sulla soddisfazione del cliente, sulle prestazioni finanziarie, sugli investimenti infrastrutturali e sulla gestione del rischio.

Query di analytics complesse su enormi set di dati sul mainframe possono consumare budget di calcolo e richiedere ore o giorni per l'esecuzione. Spostare i dati altrove, come in un cloud data warehouse, può comportare ritardi di trasporto ancora maggiori, il che porta a dati obsoleti e decisioni di scarsa qualità.

Garanti BBVA, la seconda banca più grande della Turchia, ha implementato BM Db2 Analytics Accelerator per z/OS, che accelera i carichi di lavoro delle query riducendo al contempo il consumo di CPU del mainframe.

Separare i workload di analytics dalle preoccupazioni e dai costi dell'ambiente di produzione mainframe permette a Garanti di eseguire più di 300 workload di analytics ogni notte, e per ottenere un report di conformità che prima richiedeva due giorni ora è necessario solo un minuto.

Le banche competono sulla loro capacità di fornire nuove applicazioni e offerte di servizio innovative ai clienti, quindi i team devtest agili contribuiscono costantemente alle funzionalità software. Tendiamo naturalmente a generalizzarle come miglioramenti front-end alle app per smartphone e integrazioni basate sulle API con i cloud service.

Ma aspetta, quasi tutte queste nuove funzionalità prima o poi arriveranno anche sul mainframe. Perché non coinvolgere il team del mainframe come partecipante di prima classe nel movimento DevOps?

Danske Bank ha deciso di coinvolgere circa 1.000 sviluppatori del mainframe interni in un movimento di trasformazione DevOps a livello aziendale, utilizzando IBM Application Delivery Foundation for z/OS (ADFz) come piattaforma per lo sviluppo di funzionalità, il debug, i test e la gestione delle versioni.

Anche il codice COBOL e PL/1 già esistente può essere inserito nella pipeline di gestione CI/CD , per essere poi aperto e modificato in modo intuitivo all'interno degli IDE degli sviluppatori. Qui non c'è più bisogno di armeggiare con gli schermi verdi. La banca ora può commercializzare le sue offerte nella del tempo richiesto in precedenza.

Leggi il caso di studio della Danske Bank https://www.ibm.com/it-it/case-studies/danske_bank_as

Anche le aziende fintech più recenti, "nate nel cloud", farebbero bene a considerare come le proprie innovazioni debbano interagire con un ambiente informatico ibrido in continua evoluzione, composto da controparti.

Una transazione su un'app mobile colpirà comunque le reti di pagamento globali, gli enti normativi e altre banche, ognuna con le proprie risorse di storage e mainframe dietro l'adempimento di ogni richiesta.

In questo caso non ci sarà mai un percorso univoco da seguire, perché non esistono due banche identiche e sono numerose le possibili trasformazioni che potrebbero essere apportate nel percorso di modernizzazione delle applicazioni mainframe.

I leader IT devono iniziare da qualche parte e selezionare i casi d'uso più adatti alle loro esigenze aziendali e all'architettura dell'unico parco applicazioni in cui vivrà il mainframe.

Per maggiori informazioni, consulta gli altri post di questa serie:

• Parte 1: "Modernizzazione delle applicazioni mainframe oltre il settore bancario"
• Parte 2: “Utilizzare la collaborazione (non la migrazione) per modernizzare le applicazioni mainframe con il cloud”
• Parte 4: "Mainframe e cloud? È facile con l'open source"