Di: Niloy Sengupta
I sistemi di core banking non sono adatti a campagne pubblicitarie patinate.
Spesso descritti come tecnologie legacy, sono in realtà applicazioni mission-critical che elaborano transazioni quotidiane, aggiornamenti dei conti e altro ancora. Le banche attirano i clienti con promesse di convenienza e sicurezza finanziaria, ma sono i sistemi core a svolgere il lavoro pesante.
Questi sistemi core tendono anche a presentare ostacoli quando diventa forte la spinta alla modernizzazione.
Con il clamore che in questi giorni suscita la trasformazione nel settore bancario, è utile ricordare come i sistemi core siano diventati oggetto di discordia tra i vertici aziendali. Nell'articolo seguente è presentata una retrospettiva per capire in che modo il settore bancario potrà modernizzare efficacemente le proprie applicazioni più importanti.
Nascita dei sistemi di core banking
I primi sistemi di core banking comparvero negli anni '80, facendo abbandonare alle banche la pratica secolare della scrittura manuale di registri e libri contabili.
Gli istituti bancari dovevano essere in grado di gestire grandi volumi di transazioni in modo rapido, affidabile ed efficiente. I sistemi di core banking di prima generazione1 quindi si trasformarono, offrendo centralizzazione, velocità, scalabilità e affidabilità. Scritti nei linguaggi COBOL, Assembler, PL/I e JCL, questi sistemi erano monolitici, con un accoppiamento stretto dei moduli aziendali interdipendenti sottostanti quali clienti, transazioni e prodotti.
Queste applicazioni supportavano solo l'elaborazione batch e la registrazione avveniva alla fine della giornata. I saldi infragiornalieri potevano essere resi disponibili attraverso soluzioni alternative come la pubblicazione di promemoria. In tali applicazioni, la logica del business e quella di accesso ai dati erano fortemente intrecciate 2 e separarle diventava difficile.
La seconda generazione di sistemi di core banking
A cavallo tra la fine degli anni '80 e l'inizio degli anni '90 i sistemi di core banking di seconda generazione ampliarono il mercato a banche regionali e realtà più piccole. I nuovi sistemi core introdussero architetture multilivello meno costose in grado di supportare l'elaborazione in tempo reale e che consentivano di separare la logica del business front-end da quella del livello intermedio e dalla logica di accesso ai dati.
Queste applicazioni erano tipicamente incentrate sul prodotto; i prodotti erano più facili da costruire e configurare e furono adottate diverse metodologie di integrazione. Poiché le applicazioni erano per natura più semplici e maggiormente basate su parametri, le banche potevano implementare nuovi prodotti, funzionalità e prezzi in un time-to-market più breve.3
L'ascesa di Internet negli anni '90 alimentò la crescita di sportelli front-office, filiali bancarie e applicazioni di banking online. Gli investimenti nelle applicazioni di core banking subirono un notevole rallentamento, mentre emergevano difficoltà di integrazione tra sistemi front-end e core.
Per superare tali vincoli, le banche cominciarono a creare o acquistare applicazioni middleware orientate ai servizi e basate su messaggi che consentivano un’integrazione più semplice e flessibile tra applicazioni front-end e back-end. Nel frattempo, framework di settore come IFX, FIX e FpML tentavano di fornire standardizzazione e interoperabilità tra istituzioni.