L’orchestrazione dei processi bancari è la strada per far coesistere piattaforme legacy e nuovi servizi cloud-native. È, questa, una strada dettata dalle esigenze dei clienti: il mercato globale delle piattaforme per il Digital Banking crescerà con un tasso composito annuo (CAGR) del 10,66% nel periodo 2024-2033. È quanto emerge da una ricerca di Gran View Research, che individua tra le ragioni di questo sviluppo la crescente richiesta dei clienti di servizi in mobilità, pagamenti online e gestione remota dei propri account. Tale richiesta accelera lo sviluppo di servizi cloud-native o ibridi, che offrono elasticità, resilienza e prestazioni non disponibili altrimenti. Le applicazioni legacy, che non hanno tali caratteristiche, racchiudono, tuttavia, decenni di logica aziendale che le imprese non possono facilmente sostituire: i software tradizionali sono stabili e affidabili; i costi per smantellarli sono maggiori di quelli per tenerli in vita; le competenze necessarie per la migrazione sono rare; infine, l’esito delle operazioni è incerto. L’unica strada percorribile è quella di creare un’architettura applicativa in cui si possano integrare i sistemi legacy e i nuovi servizi cloud-native. È necessaria, cioè, un’orchestrazione che integri le piattaforme legacy con i nuovi servizi digitali.
In questo articolo scoprirai:
a cosa servono oggi i sistemi legacy nel Finance;
perché i sistemi legacy sono importanti e strategici;
come si fa a integrare i sistemi legacy coi servizi digitali in cloud;
cosa vuol dire orchestrare i servizi e come si fa in pratica.
L’evoluzione del mercato Finance ha nell’Open Banking uno dei paradigmi di riferimento. Non è casuale, dunque, che normative, come, ad esempio, FIDA - Financial Data Access, regolamentino lo scambio di dati tra le istituzioni finanziarie. I nuovi servizi (embedded services, Banking-as-a-Service, ecc.) o i nuovi modelli d’impresa (FinTech), disegnano flussi di lavoro che coinvolgono applicazioni appartenenti a soggetti diversi. È nata, di conseguenza, l’API Economy - Application Programmable Interface, che si basa su 3 pillar:
l’API è la modalità per connettere applicazioni diverse;
il cloud è la tecnologia abilitante per sviluppare software altamente flessibile e scalabile;
gli orchestratori come Kubernetes governano e coordinano l’insieme dei servizi.
I sistemi legacy, che hanno un ruolo essenziale nei nuovi processi digitali, devono essere parte integrante dell’orchestrazione.
Nel Banking, la coesistenza tra i sistemi legacy e i nuovi servizi digitali rappresenta sempre una sfida. Le applicazioni in mobilità e i nuovi paradigmi di servizio (pagamenti online, smart spending, ecc.), richiedono, spesso, l’innesco di applicazioni di back-end, di solito molto complesse. Si pensi, ad esempio, al bonifico istantaneo: il sistema di core banking legacy e il motore antifrode vengono interrogati per le relative verifiche, e l’operazione deve concludersi in pochi secondi. Inoltre, i processi del Digital Banking non prevedono solo operazioni interne all’organizzazione. L’embedded banking o il Banking-as-a-Service, ad esempio, includono attività esterne che contemplano, di nuovo, operazioni di back-end.
Le piattaforme legacy, però, sono nate prima del cloud e con paradigmi architetturali diversi, e risultano strutturalmente incompatibili con il cloud. Il legacy è stato concepito e si è sviluppato come piattaforma on premise, monolitica, in cui l’interfacciamento con il mondo esterno era confinato alla ricezione o all’invio di dati (File Transfer), necessari per elaborazioni batch di tipo procedurale. Anche le attività transazionali di sportello e l’accesso in tempo reale ai database, avvenivano in una rete chiusa, progettata, configurata e controllata da apposite piattaforme centralizzate. I nuovi paradigmi di comunicazione (Internet), di delocalizzazione delle risorse elaborative (cloud) e di interfacciamento tra applicazioni (API), mettono i sistemi legacy fuori gioco. Tali piattaforme racchiudono, tuttavia, un patrimonio aziendale non alienabile: basi dati storiche, logica applicativa raffinata nel tempo, processi di comprovata efficacia. La migrazione completa, ovvero la riscrittura in ottica cloud-native, è teoricamente possibile, ma nella realtà dei fatti si scontra con criticità importanti: il costo di riscrittura è molto alto; la trasformazione completa è un percorso incerto e soggetto a forti rischi; infine, le competenze necessarie per padroneggiare le logiche legacy non sono facilmente reperibili, sia all’interno che all’esterno dell’organizzazione. Lo stesso discorso vale per le applicazioni fortemente personalizzate, che se anche sono state sviluppate in architettura cloud, sono da considerarsi legacy a tutti gli effetti: una re-ingegnerizzazione completa, pur auspicabile, risulta molto impegnativa per via dei costi e dei rischi.
Vi sono molti esempi, in ambito banking, di processi in cui una parte delle attività resta vincolata agli ambienti legacy:
Disponibilità dei fondi (Balance Check). Il registro contabile e le logiche di posting (registrazione ufficiale delle transazioni) sono nate su mainframe e assicurano in modo assoluto la consistenza del dato.
Pagamenti digitali. L’autorizzazione della carta è la parte più critica del processo per via delle certificazioni con i circuiti interbancari, e facilmente risiedono su sistemi legacy.
Apertura di conti correnti digitali. Il caricamento dell’anagrafica e l’apertura del conto nel core banking sono processi legacy: sono fortemente integrati con diversi sistemi e necessitano di verifiche di compatibilità con le policy aziendali storiche.
Prestiti istantanei. Il motore per l’erogazione del prestito e il piano di ammortamento fanno riferimento a logiche finanziarie complesse residenti su legacy.
Un’evoluzione e un ammodernamento delle applicazioni legacy è comunque necessario, perché, restando nello stato in cui si trovano, non è possibile integrare tali servizi nei nuovi processi digitali: la vecchia piattaforma monolitica ha bisogno di far parte di un nuovo processo e quindi di interfacciarsi con altre parti del flusso.
Il percorso di modernizzazione dei sistemi legacy può avvenire a livelli diversi, a seconda delle complessità delle applicazioni e delle attività stesse di migrazione. Le diverse possibilità sono conosciute come le “5R”:
Rehosting. È lo spostamento “as-is” dell’applicazione su cloud, senza alcuna modifica all’applicazione stessa;
Refactoring. Il codice viene parzialmente riscritto per includere logiche di manutenibilità e modularità tipiche delle applicazioni cloud-native;
Replatforming. A differenza del rehosting, il codice viene adattato per sfruttare al meglio i servizi della nuova piattaforma, ad esempio le modalità di accesso a database;
Rebuild. L’applicazione viene riscritta ex-novo, secondo una logica di micro-servizi;
Replace. L’applicazione viene sostituita con una soluzione completamente nuova, spesso in una logica commerciale di tipo SaaS – Software-as-a-Service.
La scelta di una di queste opzioni è strategica, non solo tecnica: si rendono espliciti i confini funzionali di un’applicazione, e partecipano all’orchestrazione complessiva con una logica basata su API ed eventi. Le logiche legacy restano le stesse, ma partecipano all’ecosistema del Digital Banking come microservizi all’interno di container riutilizzabili.
La trasformazione delle vecchie architetture legacy in servizi richiamabili secondo necessità implica non solo la scelta del livello a cui intervenire, ma anche la progettazione della nuova architettura applicativa. Nei processi del Banking citati in precedenza, occorre trasformare la parte vincolata ai legacy in passi di un flusso coordinato. L’orchestrazione dei servizi bancari richiede, cioè, una serie di interventi tecnici esterni alla logica software in quanto tale:
Containerizzazione delle applicazioni. Il software viene “pacchettizzato” in un container standard, che ne garantisce la portabilità tra ambienti e applicazioni. Il software viene isolato e richiamato al bisogno, garantendo la scalabilità nell’utilizzo.
Orchestrazione. I motori come Kubernetes gestiscono il ciclo di vita dei container (deploy, istanziazione, scaling, ecc.). Kubernetes consente ai moduli software di essere disponibili all’esecuzione, realizzando un’applicazione distribuita.
API management e API gateway. Il software espone le proprie funzionalità in modalità standard, permettendo l’utilizzo da parte di altri software. Sia il ciclo di vita (versioning, richiamo, ecc.), sia il contesto di utilizzo (autenticazione, sicurezza, ecc.) devono essere progettati e gestiti.
Integrazione sincrona o asincrona. Il microservizio può essere progettato per un utilizzo sincrono (la risposta deve essere immediata) e asincrono (l’esecuzione avviene tramite code o eventi). Le due modalità si combinano per bilanciare la latenza e la capacità di rispondere alle richieste. Una corretta orchestrazione dei processi bancari deve tenere conto del giusto bilanciamento tra le due modalità. Nel caso del bonifico, ad esempio, è opportuno separare i servizi che devono di necessità essere eseguiti in modo sincrono (autenticazione dell’utente, controllo del saldo, validazione IBAN, ecc.), da quelli che possono essere asincroni (registrazione sul libro mastro, invio al circuito interbancario, ecc.).
L’integrazione dei sistemi legacy della banca, ovvero l’orchestrazione applicativa, è realmente possibile, grazie a un lavoro progressivo di disaccoppiamento e modernizzazione, basato sulla creazione di microservizi containerizzati e governati da Kubernetes. Il nuovo modo di sviluppare i servizi ha creato, nei fatti, un nuovo ecosistema, che necessita di attività peculiari: l’Observability, ovvero il monitoraggio delle applicazioni e delle risorse elaborative per garantire disponibilità e livello di servizio; la Continuous Integration/Continuous Delivery (CI/CD), per automatizza, secondo il modello DevOps, le fasi di sviluppo e rilascio del software; infine, la gestione degli accessi token, password, certificati, ecc.), per proteggere le funzioni e i dati sensibili.
Il problema della sicurezza ha, com’è evidente, un valore capitale. L’utilizzo del cloud e il nuovo paradigma del software distribuito rendono le applicazioni soggette a molteplici rischi. Non è casuale, dunque, che vi siano diverse normative che obbligano le banche a costruire opportune difese contro i furti dei dati o l’uso fraudolento dei servizi. Le normative FIDA, PSD2 (PSD3 in prospettiva) e DORA, danno chiara indicazione sui rischi possibili e le necessarie contromisure. Orchestrare i processi bancari significa, quindi, gestire aspetti specifici di sicurezza, che possono riferirsi sia all’uso dell’applicazione (la PSD2 introduce l’uso dell’autenticazione forte per l’acceso ai servizi), sia alla creazione di ambienti protetti nei confronti di interruzioni operative o attacchi informatici.
L’evoluzione del mercato finanziario (Open Banking) e la concorrenza delle imprese FinTech impone alle banche di creare servizi digitali in linea con le attese dei clienti: il mobile banking, l’embedded services o il Bank-as-a-Service sono esempi di servizi digitali innovativi, che per essere sviluppati necessitano di integrare software e dati gestiti da applicazioni legacy.
L’integrazione dei sistemi legacy della banca richiede, però, una orchestrazione applicativa: i servizi legacy devono, cioè, essere isolati dal vecchio ambiente e migrati verso una nuova architettura. E questa è un’attività critica, sia per la complessità e la stratificazione delle applicazioni legacy, sia per le nuove logiche di gestione richieste dalle architetture a microservizi e dalla containerizzazione. È opportuno, dunque, che si adottino percorsi di transizione adeguati, che contemplino:
il tipo di migrazione (5R);
le tecniche del nuovo ecosistema (DevOps, API management, ecc.);
l’utilizzo di un motore di orchestrazione come Kubernetes.
È possibile, in questo modo, creare un’orchestrazione applicativa dei processi bancari, ovvero un’integrazione dei servizi legacy che consente di valorizzare tutto il patrimonio applicativo e garantire lo sviluppo futuro del business.