Modernizzare le applicazioni bancarie - come navigare tra rischio e ricompensa

Nonostante tutti i benefici del cloud computing, le aziende finanziarie tradizionali fanno ancora molto affidamento sui mainframe. Ma il cambiamento sta arrivando, è inevitabile.

Per le applicazioni che girano su mainframe è sempre più difficile competere nell’economia digitale. Le fintech e le neo-banche cloud-native stanno acquisendo quote di mercato, alimentate dai cicli di innovazione più rapidi e i costi contenuti che il cloud assicura.

Ma questa è una narrazione fuorviante. La modernizzazione delle applicazioni non è necessariamente una questione di mainframe contro cloud. Molte banche apprezzano ancora i mainframe per la loro affidabilità e intendono continuare a usarli. Piuttosto, si tratta delle applicazioni legacy che girano su di essi, che sono caratterizzate da architetture monolitiche, standard e protocolli proprietari, e vecchi linguaggi di programmazione che non aiutano ad attrarre la prossima generazione di talenti. In altre parole, modernizzare le applicazioni non significa necessariamente migrare dai mainframe. Quindi, come può una banca scegliere l’approccio migliore?

L’ambiguità è OK

Si può essere tentati di analizzare questa domanda in termini binari. A un estremo, i radicali, che vedono solo il costo e la diminuzione dei talenti associati ai loro mainframe e vogliono eliminarli il più presto possibile. Dall’altra parte, i conservatori, che non sono pronti a compromettere potenzialmente il track record di sicurezza, disponibilità e throughput delle transazioni dei loro mainframe, specialmente per le applicazioni core. 

Una caratterizzazione più credibile delle grandi banche e delle istituzioni finanziarie è quella di organizzazioni che cercano efficienze tecnologiche e vogliono competere per i migliori talenti, ma sono prudenti e consapevoli dei rischi legati al muoversi troppo in fretta e vogliono ammortizzare il pieno valore dei loro investimenti in sistemi e competenze attuali.

Questo presenta molta ambiguità, e più grande è l’azienda, maggiore sarà l’ambiguità. Ciò che ha senso per un’organizzazione non sarà giusto per un’altra. Le grandi banche e le finanziarie vorranno definire i propri piani e programmi di modernizzazione, e che questi si adattino a situazioni mutevoli e imprevedibili. In altre parole, vogliono una tecnologia che si adatti all’ambiguità, piuttosto che eliminarla. 

5 modi per modernizzare un’applicazione

In generale, ci sono cinque modi in cui un’organizzazione può modernizzare un’applicazione che gira su un mainframe. Questi possono includere il mantenimento del mainframe o la migrazione da esso (completa o parziale) verso un’implementazione ibrida o completamente in-the-cloud.

1. Sostituzione - mandare in “pensione” l’applicazione e iniziare da zero con una nuova che richiede implementazione, personalizzazione e adozione. Sebbene sia una trasformazione a livello organizzativo, questa non è strettamente una modernizzazione, poiché si sta eliminando l’applicazione. Detto questo, di solito ci sarà un periodo di coesistenza mentre i dati vengono migrati alla nuova applicazione e fino a quando integrazioni, personalizzazioni e adozione non saranno completate.
2. Emulazione / Rehost - spostare l’applicazione su una piattaforma di distribuzione meno costosa, con poco o nessun impatto sulle sue prestazioni, tipicamente come misura temporanea prima di ritirarla. Di nuovo, questa non è una vera modernizzazione.
3. Conversione - riscrivere il codice dell’applicazione, sia automaticamente (veloce ma con il rischio di imprecisioni) o manualmente (più accurato, ma più lento.) Questa opzione aiuta a rimuovere i linguaggi di programmazione legacy con compilatori e ambienti runtime costosi e per i quali è difficile trovare personale qualificato. Invece, le applicazioni possono essere tradotte in linguaggi moderni che usano compilatori e ambienti runtime comuni (open source), e per i quali le competenze sono più comuni. Per una maggiore flessibilità futura, riscrivete il codice per un ambiente cloud-native in modo che l’applicazione possa essere eseguita ovunque: in un cloud pubblico, privato, su server o mainframe.
4. Refactor - riprogettare elementi selezionati dell’applicazione per utilizzare container e microservizi, lasciando altri elementi intatti.
5. Riarchitettare / Ricostruire - riprogettare l’intera applicazione.
6. In realtà, poiché le banche eseguono centinaia di applicazioni diverse, è probabile che sia necessario un mix di queste opzioni. Inoltre, con tutte queste alternative (ma specialmente la 3 e la 4), elementi della stessa applicazione gireranno contemporaneamente su diversi mainframe o ambienti. E visto che la modernizzazione delle applicazioni richiede tempo, ognuna di esse dovrà essere mantenuta e gestita in modo continuativo.

Superare la complessità

Tutto questo può portare complessità. Quando le applicazioni vengono eseguite interamente su un mainframe, c’è solo un’infrastruttura sottostante di cui preoccuparsi. Ma non appena si introducono altri modelli di deployment, e si inizia a dividere le singole applicazioni in parti costituenti e a farle girare in posti diversi, può nascere il caos. Qualsiasi beneficio economico o di produttività che si spera di ottenere nel lungo periodo sarà annullato se non si riesce a orchestrare questa complessità nel breve termine.

Per molto tempo, è stata questa la sfida che ha trattenuto le grandi banche e istituzioni dalla modernizzazione delle loro applicazioni. Ma tutto questo sta cambiando con le piattaforme aziendali Kubernetes come Red Hat OpenShift e i partner che ne gestiscono le complessità per i loro clienti bancari. Questa partnership di tecnologia e competenza sta dando al settore finanziario il controllo necessario per modernizzare alle loro condizioni, al loro ritmo.

OpenShift fornisce il toolkit DevOps per modernizzare in modo efficiente un’applicazione o costruirne una nuova. È agnostico, il che significa che le applicazioni e le loro componenti possono essere distribuite su più modelli di deployment, e facilmente spostate tra di essi. Questo non solo permette libertà di scelta oggi, ma flessibilità futura.

Se un progetto di modernizzazione di un’applicazione dovesse fallire, può essere messo in pausa o riportato al mainframe, senza che quel lavoro sia stato vano. Allo stesso modo, un’applicazione può essere spostata nel cloud - privato e pubblico - mitigando il rischio di vendor lock in.

L’urgenza per le banche e le istituzioni finanziarie di modernizzare le loro applicazioni non è mai stata così elevata. La scelta di come farlo non è mai stata così ampia. I rischi non sono mai stati più contenuti. OpenShift permette a radicali, conservatori e a tutti quelli che stanno nel mezzo di vincere.