LEGACY MODERNIZATION

1

PERCHE’ SERVE UNA STRATEGIA DI LEGACY MODERNIZATION

• Customer experience: La customer centricity richiede customer journey multicanali, responsive in termini di user experience, ma anche di freschezza del dato che mal si conciliano con sistemi informativi pensati in un periodo nel quale l’interazione con l’utente avveniva essenzialmente attraverso un solo canale (sportello) in orari prefissati nella giornata (apertura della filiale);
• Compliance: nuovi adempimenti normativi (ad es. Circ. 285 Banca Italia, BCBS239, PSD2, etc..) richiedono ulteriore capacità elaborative e la messa in sicurezza di strumenti informatici;
• Nuovi player, che si affacciano sul mercato (OTT, Fintech) e che sono nelle condizioni di “pensare tutto a nuovo” e, di conseguenza, di essere disruptive nei confronti degli attuali incumbent;
• Enabler tecnologici, destinati a rivoluzionare il nostro modo di vivere (si pensi all’intelligenza artificiale della quale i canali conversazionali quali i chatbot rappresentano il primo tangibile risultato);
• Requisiti interni, espressi da CFO/CRO in asservimento a normative (ad es. vigilanza Off Site) o di maggiore conoscenza della propria base clienti;
• Consolidamenti e migrazioni, in conseguenza a fusioni bancarie che hanno portato a scegliere un sistema informativo di riferimento (mainstream) ed a ricondurre gli altri in esso generando sovente un maggior grado di disordine e maggiori difficoltà di gestione.

Le sfide poste dalle unità di Business devono essere coniugate con un efficientamento del costo della macchina operativa, che, soprattutto in un regime di contrazione dei ricavi, deve garantire l’erogazione dei servizi ad un costo progressivamente minore

• Time to Market sempre più stringenti che possono essere portati all’estremo come nel paradigma “Fail Fast, Success Faster);
• Continuità di servizio delle applicazioni estesa oltre il normale orario lavorativo (si pensi all’erogazione di un instant lending disponibile da una applicazione mobile);
• Debito Tecnologico: molto spesso le tecnologie utilizzate nelle applicazioni legacy sono in desupporting e le competenze necessarie al loro mantenimento sono sempre di più difficile reperimento sul mercato;
• Cost Cutting: le applicazioni legacy, in particolare quelle ospitate su Mainframes, presentano un costo di running non più sostenibile, ad es. eccessivo costo del MIPS (Million of Instruction per Second) .

D’altro canto “If it ain’t broke, don’t broke it” (se non è rotto non aggiustarlo). Serve quindi un’analisi approfondita che conduca ad una strategia chiara di gestione/evoluzione delle applicazioni legacy che per anni hanno costituito il cornerstone del proprio sistema informativo e ne hanno arginato la piena evoluzione vs il digital banking.

2

LA COESISTENZA DI APPLICAZIONI LEGACY E MODERNE

La seguente figura rappresenta un modello concettuale dell’attuale sistema informativo bancario nel quale le componenti legacy sono state progressivamente ridotte, ma rappresentano tutt’ora una componente centrale per la transazionalità e devono convivere con tutta una serie di applicazioni nate in tempi successivi per soddisfare nuovi requisiti di business (ad es. CRM, sistemi per CRO/CFO) e per abilitare un accesso multicanale (si veda i paradigmi presenti in letteratura di Two Speed Architecture e di BiModal Architecture).

Il punto focale risulta quindi essere come utilizzare al meglio l’eredità del passato rappresentata dalle applicazioni legacy nelle quali è innegabile che transazionalità, robustezza, affidabilità sono sempre garantiti e nel contempo intraprendere un percorso di innovazione volto a rendere l’intero ecosistema più flessibile, adattabile alle nuove esigenze di business, riducendo il costo complessivo di gestione.

Un primo aspetto è tattico ed è rappresentato dalla modalità di interazione con le applicazioni legacy sfruttandone al meglio le peculiarità ed abilitando la digital transformation.

Sotto questo aspetto le più moderne tecnologie quali ad esempio Architetture a Microservizi e Event Driven Architecture rappresentano un valido enabler.

Un microservizio implementa una specifica funzionalità di business nel proprio dominio di dati. L’utilizzo di microservizi consente quindi di esporre funzionalità tipiche di un ambiente Mainframe, quali ad esempio un'interrogazione di un saldo di conto corrente oppure un’operazione dispositiva di bonifico o di pagamento F24 evitando un eccessivo consumo di MIPS (workload offloloading).

In modo analogo una Event Driven Architecture, compatibile anche con la forte presenza di legacy su mainframe,  consente di catturare eventi e dati significativi che avvengono nelle legacy application rendendo più reattivo l’intero processo di customer jorney (si pensi ad esempio all’invio di una push notification a seguito della conferma all’erogazione di un finanziamento).

3

GLI SCENARI DI LEGACY MODERNIZATION

Il secondo aspetto è invece strategico ed è rappresentato dal percorso che si intende predisporre per ridurre la dipendenza dalle applicazioni legacy.

Esistono differenti possibili approcci al problema della legacy modernization a partire dal Rehosting (ovvero mantenere invariato sia perimetro funzionale che tecnologia di base, ma muovendo l’applicazione in un ambiente tipicamente emulato dal costo inferiore) fino al completo ridisegno dell’applicazione (Rebuild).

La figura sottostante riporta i differenti scenari possibili descrivendone le caratteristiche salienti.

Ogni scenario è caratterizzato da benefici in termini di riduzione del debito tecnologico e di agilità/adattabilità crescente a fronte di rischi e costi differenti.

La matrice colloca gli scenari di cui sopra in termini di riduzione del debito tecnologico ( asse “Fill in the Technical Debt”), scomposizione funzionale e recepimento di nuovi requisiti di business che portano ad un aumento del grado di flessibilità ed adattabilità (asse “Componetization”).

A completamento sono riportate le scale di rischio e di costi che si devono affrontare.

La figura posiziona altresì all’interno del quadrante le principali tecnologie ad oggi disponibili a supporto del processo di legacy modernization.

4

IL PERCORSO DI TRASFORMAZIONE

Il percorso inizia necessariamente con una fase di assessment nella quale costruire l’inventory degli oggetti appartenenti al portfolio applicativo, in particolare occorre:

• Sintetizzare le esigenze di business che generano richieste di nuovi servizi\funzionalità da esporre sui canali ed oggi tradizionalmente erogati in filiale sul front end di sportello;
• Acquisire copia dell’ambiente mainframe (sorgenti e dati) utilizzando tool automatici per costruire l’inventory e censendo interrelazioni e dipendenze interne ed esterne;
• Raccogliere dati e KPI sulle applicazioni quali ad esempio: MIPS utilizzati, criteri di scheduling, utenti, interfacce esterne, costi operativi, business value, requisiti e piani evolutivi, KPI e policy di performance, disponibilità, sicurezza, etc…

Ne conseguirà una mappa delle applicazioni maggiormente critiche per vincoli al business o costo del servizio.

Per ogni singola applicazione occorre poi costruire la strategia di legacy modernization attribuendo la corretta priorità ai driver illustrati in precedenza (cost cutting, riduzione del debito tecnologico, continuità di servizio, time to market, nuovi requisiti di business e quindi componentizzazione dell’applicazione) per poi scegliere la tecnologia più opportuna da applicare.

Selezionato il primo use case ed identificata la tecnologia più opportuna, il percorso richiede un continuo affinamento in funzione dei risultati raggiunti, del livello crescente di maturità di tecnologie innovative. Esso potrebbe anche essere modellato in più passi per applicazioni particolarmente mission critical e ad elevata complessità funzionale; ad es. ReHosting iniziale per abbattimento dei costi ed uscita da lock in e successivo reengineering muovendo verso tecnologie standard di mercato (azzeramento del debito tecnologico ed insourcing della knowledge base in azienda).

Il percorso potrà in tal modo essere corredato di una road map che consenta di disporre:

• Dell’inventory degli oggetti e dei principali driver di valutazione e prioritizzazione;
• Della strategia di evoluzione per ciascun oggetto che potrà prevedere anche mix di strategie non essendo conseguibile l’obiettivo con un unico approccio dato il diverso livello di maturità dei legacy, dei requisiti di business e dei connessi volumi e rischi;
• Delle tempistiche e dei connessi costi di evoluzione dei legacy.

Reply ha sviluppato una metodologia e un approccio consolidato per affiancare le banche nell’indirizzare la crescente richiesta di modernizzazione dei legacy per poter abilitare il business e ridurre il cost to serve.

e*finance consulting Reply è la società del gruppo Reply specializzata in servizi di consulenza manageriale per le financial institution. accompagniamo i nostri clienti nel definire e realizzare le proprie linee strategiche attraverso la declinazione di nuovi modelli di business e distributivi, l’evoluzione di processi e strumenti operativi ed il disegno di nuovi prodotti e servizi. sempre più spesso, questo significa intraprendere un percorso di digital transformation che richiede la capacità di coniugare competenza di settore con piena padronanza dell’innovazione tecnologica e la capacità di declinarla in modo rilevante per il business.