Negli ultimi anni il Cloud è diventato una strategia fondamentale per lo sviluppo IT delle grandi aziende finanziarie, e non solo.
Il comune denominatore è la digitalizzazione e questo richiede un’infrastruttura e una piattaforma tecnologica che siano altamente scalabili, innovativi ed elastici.
Nel mettere a terra questa strategia tecnologica, una delle principali sfide da affrontare riguarda l’architettura dati di riferimento, per riuscire a sfruttare il patrimonio informativo nel migliore dei modi.
Per le grandi corporate dei financial services, lo scenario di riferimento che si prospetta è per lo più ibrido: applicazioni e dati on premise, perché strategiche o semplicemente non pronte ad essere portate sul cloud, che convivono con applicazioni e dati in cloud, perciò nella definizione di questa architettura è necessario affrontare alcuni aspetti vincolanti: la latenza, il “Cap theorem” e la “data gravity”.
Latenza, Cap theorem e data gravity
Rispetto alla latenza, questa deriva dall’inevitabile distanza fisica tra i sistemi on-premise e i server del cloud provider. Maggiore è la distanza, maggiore è la latenza, che equivale a un ritardo più lungo nella trasmissione dei dati, cosa che può impattare sui tempi di risposta e quindi sull’esperienza utente. Progettare un’architettura dati per il cloud significa quindi fare leva anche sull’architettura della rete di connettività e delle telecomunicazioni. L’apertura di region cloud in Italia da parte dei principali provider porterà ovviamente benefici incrementando il potenziale workload dirottabile sul cloud.
D’altro canto, garantire velocità e performance dei sistemi IT è fondamentale per aiutare le organizzazioni a diventare data-driven e quindi capaci di creare insight in near real time, democratizzando l’utilizzo delle analisi sui dati ed ottimizzando i processi aziendali, oltre ad abilitare nuovi prodotti e servizi digitali.
Per quanto riguarda il Cap theorem (anche conosciuto come teorema di Brewer), esso afferma che per i sistemi informatici distribuiti non è possibile soddisfare simultaneamente la coerenza (copy Consistency), la disponibilità (full Availability) e la tolleranza di partizione (Partitioning), ma al massimo due di queste per volta. Negli scenari ibridi di cui stiamo trattando, è bene tenere a mente che la presenza di latenza porta inevitabilmente ad un effetto di partizionamento di rete.
Sebbene alcuni database innovativi (e.g. newSQL) aggirano i vincoli del Cap theorem utilizzando algoritmi di consenso dei nodi su cui il database è frazionato, occorre tuttavia che chi si occupa di sviluppare le componenti di scrittura (transazionali) e di lettura (analitiche) a valere su tali database possieda una specifica formazione, in modo da avere piena consapevolezza di come l’infrastruttura sottostante è organizzata e di quali siano le sue potenzialità e i suoi limiti (es. indici, viste, chiavi primarie, store procedures).
Con riferimento alla data gravity, questo concetto sottende la metafora che la massa dei dati è da considerarsi come un centro d’attrazione gravitazionale per i relativi processi elaborativi, per cui voler spostare le elaborazioni in Cloud implica in qualche misura un moving dei dati verso tali ambienti. Concetto enfatizzato, oggi giorno, con lo spostamento di alcuni processi computazionali e di dati verso gli end point (edge computing – IoT).
Questo aspetto legato al movimento del dato verso in sistemi in Cloud va affrontato anzitutto chiarendo il contesto dei sistemi informativi nel settore dei financial services: esiste, infatti, una certa distanza tra le ambizioni di democratizzazione degli analytics, l’utilizzo avanzato dei dati in ambito digitale (inclusa l’intelligenza artificiale) – spesso offerti da soluzioni di moderni analytics in cloud – e la situazione, stratificata ed a silos, dei sistemi legacy messi in piedi dalle banche lungo una storia anche trentennale, che spesso sono persino in contraddizione con alcuni fondamentali dell’information technology.
La necessità della data modernization
Risulta fondamentale quindi agire su due binari paralleli: la data modernization dei sistemi on premise e l’introduzione di un layer d’integrazione dei dati verso i sistemi cloud, il cosiddetto “Decoupling layer”.
A riguardo del primo aspetto, per conseguire una vera data modernization è necessario semplificare il “sistema dati” di riferimento, attraverso: programmi di ridisegno/riaggiornamento delle data pipelines (serie di fasi successive di elaborazioni dati) e dei modelli dati; la dizionarizzazione dei termini tecnici e di business; il recupero della conoscenza sui campi “calcolati/derivati”; l’eliminazione delle ridondanze; l’individuazione di golden source univoche. Si tratta, in altri termini, di irrobustire i processi di disegno delle data pipelines e della data governance ed i framework di data quality. È un percorso complesso, di valore e che richiede tempo, non sempre disponibile rispetto agli obiettivi sfidanti di digitalizzazione e di cloud strategy delle aziende.
L’introduzione del Decoupling layer, invece, è volto ad accelerare l’adozione di soluzioni in Cloud, permettendo di definire un nuovo “centro di massa” dei dati per l’integrazione verso questi ambienti. Questo layer deve chiaramente essere dotato di una robusta soluzione ibrida di data governance e della capacità di ospitare tipologie di dati eterogenei: strutturati e non strutturati. Ha l’obiettivo di rendere fruibili i dati alle moderne applicazioni in cloud per abilitare near-real time processing, multi-experience e context aware services (e.g., marketing, sales e post sales support commerciale). Risulta indispensabile, inoltre, in un contesto multicloud in cui è necessario garantire la consistenza e un contro-aggiornamento “ordinato” delle basi dati master a fronte di eventi provenienti dai canali.
Per dare corso a questa soluzione, due sono gli aspetti da indirizzare: la “distribuzione geografica” delle diverse subject areas dati e le valutazioni tecnologiche su database e strumenti (di integrazione, monitoraggio, etc.) da utilizzare per le verticalità distribuite in cloud.
In merito alla distribuzione geografica, in un contesto di strategia multicloud, si può ipotizzare di mantenere on premise alcune aree dati comuni, ad esempio i customer data, e di spostare le verticalità specifiche utilizzate dalle applicazioni distribuite sui diversi Cloud service provider sulle relative aree dati presso questi ultimi.
Per quanto concerne le valutazioni tecnologiche, prevalgono due approcci: base ed evoluto.
Il primo prevede l’utilizzo di database di terze parti (quelli usati on premise ad esempio) in modalità IAAS/self contained. Questa strategia può abilitare un veloce lift and shift dall’on premise al cloud e può essere preferita dagli end users con un’esperienza consolidata e di successo verso l’offering di un independent software vendor ma può essere penalizzante sotto il punto di vista del colloquio con il resto dell’ecosistema cloud scelto, oltre che sotto l’aspetto di lock-in verso l’independent software vendor.
Il secondo, l’estremo opposto, prevede una strategia in cui per ogni Cloud Service Provider scelto si adottano soluzioni database native che sfruttano i numerosi servizi, sempre più potenti, che i CSP continuano a sviluppare e che si focalizzano, ovviamente, sui database nativamente supportati.
Il principale beneficio di questo secondo approccio è la piena integrazione “out of the box” con l’ambiente del Cloud Service Provider e con le sue evoluzioni, mentre possono essere fattori critici il lock-in verso il Cloud Service Provider stesso e la maggior difficoltà nell’integrazione con dati residenti in altri Cloud.
Il doppio approccio si ritrova anche in termini di integrazione: la scelta tra l’utilizzo dei classici tool di ETL/ELT, contro la possibilità di utilizzo di strumenti nativi dei diversi Cloud Service Provider costruiti per garantire alto throughput e bassa latenza. Va ricordato che per l’utilizzo delle soluzioni in Cloud vanno pagate anche le data transfer fee e quindi l’ottimizzazione dei trasferimenti (ad esempio con gestioni a delta) è preferibile.
I diversi Cloud Service Provider propongono diverse metodologie e soluzioni (anche di terze parti) per agevolare la migrazione (ad esempio con tool di conversione degli ETL/ELT).
Concludendo, con l’obiettivo di cogliere a pieno le opportunità offerte dalle soluzioni in Cloud, diverse sono le azioni richieste in termini di architettura dati. Nel breve periodo la progettazione di un opportuno layer dati di interfaccia può essere la soluzione migliore per massimizzare i benefici d’adozione e ridurre il più possibile i costi d’utilizzo correnti e potenziali. Risulta però necessario affrontare fin da subito i temi di data governance, in un contesto ibrido e seamless, e strategicamente, con un orizzonte indubbiamente più lungo, procedere con un percorso di “data modernization” dei propri sistemi.
