I principi di un moderno Data Management
Abstract
Questo articolo costituisce l’introduzione di una serie di blog post finalizzata a trasmettere i punti salienti della visione delle architetture IT enterprise e del Data Management che, come Quantyca, proponiamo ai nostri clienti.
Negli articoli successivi tratteremo diversi aspetti che riteniamo interessanti per costruire piattaforme dati in grado di rispondere alle esigenze pressanti di un business che sta diventando sempre più data-driven.
Questo l’elenco dei prossimi articoli:
- “L’approccio data-centrico che cambia l’IT”: sostiene la visione dei dati come asset condivisi attorno a cui costruire le architetture enterprise
- “L’esigenza di governo nella gestione dei dati”: discute la necessità di costruire un framework di governance metadata-driven per mantenere il controllo della distribuzione dei dati nell’architettura enterprise
- “L’adattabilità della piattaforma di integrazione in un modello Data Fabric”: descrive un nuovo modello di piattaforma architetturale intelligente e automatizzata
- “Il Domain Driven Design applicato ai dati per una maggiore agilità nella progettazione”: riporta i punti fondamentali del modello di sviluppo software Domain Driven Design, che ha influenzato la proposta di nuovi modelli organizzativi anche per il Data Management
- “Il Data Mesh e la spinta verso una gestione dati distribuita”: descrive le ragioni che hanno contribuito alla proposta del paradigma Data Mesh, in favore di una gestione dei dati decentralizzata e domain-oriented per ottenere scalabilità organizzativa
- “Il Data Mesh e il principio di consumo self-service dei dati come prodotti”: descrive la visione dei dati come prodotti, che formano una rete di domain-oriented Data Product e sono fruiti tramite una piattaforma self-service e un modello di governance federato;
- “La Data Strategy come motore dell’IT”: chiude la serie con un riassunto dei principi architetturali che riteniamo basilari per una strategia di Data Management efficace e una visione del ruolo dell’Enterprise Architect nel delineare l’evoluzione delle architetture dati
Le sfide dell’IT nell’era dei dati
Nella mia esperienza come Data Architect in Quantyca, ho l’occasione di conoscere svariate realtà aziendali, più o meno mature dal punto di vista della trasformazione digitale.
In generale lo stato di avanzamento di un’azienda nel processo di trasformazione digitale è direttamente proporzionale alla concezione che l’organizzazione ha del ruolo dell’IT: le aziende in ritardo considerano ancora la funzione IT come centro di costo, al contrario le imprese leader considerano l’IT come funzione di business alla pari delle altre, come abilitatore di vantaggio competitivo.
La capacità dell’IT di fornire valore strategico può dipendere da diversi fattori, uno dei quali è il grado di modernità ed efficacia dell’architettura dati e applicativa. La maggior parte delle aziende non native digitali ha ereditato negli anni una strategia IT che si può definire application-centrica: l’organizzazione ha scelto di implementare soluzioni custom o acquistare prodotti di mercato dai vendor più affermati per rispondere alle funzionalità digitali richieste dal dominio di business (come la necessità di implementare un sistema ERP, un sistema di gestione del magazzino, un software di cassa, un sistema di controllo qualità o di monitoraggio degli impianti produttivi). Il design interno dei vari livelli (presentation layer, business layer, persistence layer) che costituiscono le applicazioni è stato comunemente il fattore primario considerato nella progettazione dell’architettura IT, dalla scelta degli stili architetturali alla scelta degli stack tecnologici e delle infrastrutture a supporto. In quest’ottica i dati erano considerati un by-product delle applicazioni, un elemento funzionale a mantenere lo stato applicativo e a supportare le logiche di processo.
Una strategia di questo genere era più che giustificata nella prima era di digitalizzazione, nella quale le applicazioni necessarie all’azienda erano relativamente poche: in un simile scenario, il contributo richiesto all’IT era, in primo luogo, di fornire supporto digitale ai processi aziendali core (ad esempio digitalizzare la gestione del magazzino, delle commesse ecc…). Pertanto, l’obiettivo primario era fondare un’architettura IT basata su applicazioni robuste ed affidabili nel svolgere il proprio compito operativo.
Gli applicativi aziendali, per supportare alcuni processi, richiedevano comunque un minimo di integrazione a livello di servizi: per adempiere a questa esigenza, si è consolidato negli anni il modello Service Oriented Architecture (SOA), basato sui sistemi di Enterprise Service Bus (ESB).
Oltre all’esigenza operazionale di digitalizzare i processi di business, era stato compreso fin da subito anche il valore dell’analytics e della Business Intelligence, come area funzionale a supporto dei processi di decision-making aziendali. Tuttavia, essendo relativamente limitate le applicazioni sorgenti di dati e avendo incentrato le piattaforme analitiche dell’epoca su un unico data store centralizzato costituito dal data warehouse, le integrazioni rimanevano in un numero contenuto e venivano progettate secondo uno stile di Extract, Transform and Load (ETL) point-to-point, dalle applicazioni sorgenti al DWH target.
Nella nuova era di digitalizzazione tipica degli ultimi anni, l’esigenza non è più quella di digitalizzare i processi core, quanto piuttosto di usare il digitale per creare nuovi modelli di business. Il numero e la varietà delle sorgenti dati e delle applicazioni utilizzatrici, così come la pletora di finalità possibili di utilizzo dei dati per scopi operazionali e analitici, sono aumentate esponenzialmente: questo fenomeno ha reso le integrazioni, che prima erano considerate di secondo ordine, un aspetto di centrale importanza.
Infatti, nell’ultimo ventennio lo scenario è radicalmente cambiato: l’avvento del business online, la diffusione delle applicazioni mobile, la necessità di fornire all’utente più touch point con il brand aziendale su canali differenti, la personalizzazione dell’esperienza utente e gli investimenti sui sistemi di engagement, i progressi significativi fatti nell’area dell’intelligenza artificiale e della data science, la necessità sempre più spinta di integrare gli applicativi e i dati aziendali, come ad esempio per la realizzazione delle customer data platform, hanno portato a rivedere le scelte alla base delle architetture IT.
I modelli IT tradizionali che affidavano le attività di integrazione a team centrali, quali il team SOA per i processi operazionali e il team DWH per il mondo analitico, hanno iniziato a vacillare, in quanto questi team sono presto diventati dei colli di bottiglia che rallentano la capacità di delivery dei servizi digitali.
Alla luce di questo fatto, è il momento di cambiare prospettiva, gli strumenti tecnologici per farlo sono disponibili, quello che occorre è modificare radicalmente la visione sulla strategia digitale. Ci possono essere diverse vie, ma un tratto comune che si osserva è che le aziende più mature nella trasformazione digitale hanno iniziato un percorso per cercare diversi modelli di organizzazione verso un trend data centrico.
Questo implica interrogarsi su che valore hanno i dati prodotti e consumati da un’azienda all’interno dei processi digitali, al di là del loro utilizzo ai fini dei processi stessi e del ciclo di vita delle applicazioni che li producono o li consumano: come è possibile spendere al meglio il budget IT per costruire una piattaforma dati moderna, scalabile e versatile, che offra all’azienda nuovi asset duraturi e riusabili, da sfruttare per trarne vantaggio competitivo?
Il rischio di non affrontare questi temi nel modo corretto è di accumulare debito tecnologico: i prodotti software selezionati, tradizionali o moderni che siano, diventano con buona probabilità dei legacy, che tendono ad accentrare all’interno di essi sempre più funzionalità e dati, raggiungendo con buona probabilità livelli di complessità e costi di manutenzione insostenibili, al punto di condizionare e rallentare le scelte future sull’evoluzione dell’architettura.
Dal lato loro, i vendor di applicazioni enterprise spingono in questa direzione, per accentuare il lock-in dell’azienda cliente sul prodotto e garantirsi una fonte di revenue maggiore, fornendo piattaforme sempre più estese e apparentemente auto-consistenti, costruite attorno alle funzionalità core del prodotto stesso. Esempi di tali sistemi sono anche alcune piattaforme cloud native, che hanno sostituito in molte aziende i sistemi ERP e CRM tradizionali, ma che comunque fondano il loro business sull’attrarre il cliente a rimanere legato alla suite offrendo moduli fortemente integrati tra di loro e funzionalità di analytics on top della piattaforma centrale, offerta con modelli Platform as a Service(PaaS) o Software as a Service(SaaS).
Tuttavia, nella realtà delle cose si osserva che non esiste un prodotto in grado di soddisfare bene tutte le esigenze digitali di un’azienda, pertanto l’integrazione non è una scelta, ma una necessità.
Le conseguenze del debito tecnologico accumulato e dell’approccio application-centrico vengono pagate nel momento in cui si presenta la necessità di integrare le soluzioni software per realizzare nuovi servizi data-driven. In quel momento ci si rende conto che si ha spesso a che fare con diversi data silos che è difficile far comunicare.
Il documento “2022 Connectivity benchmark report” di Mulesoft ha evidenziato che i costi di integrazione assorbono più di 1/3 della spesa IT annuale nel mondo. Non deve pertanto sorprendere il fatto che si osservi una quantità ingiustificabile di progetti IT che eccedono il budget iniziale di ordini di grandezza e che immancabilmente sforano le deadline. Sempre secondo il report, infatti, nel 2021 la percentuale di progetti che non sono stati consegnati in tempo è del 52%.
Del resto, la richiesta di nuove funzionalità e di servizi digitali è sempre più pressante (nel 2021 il report stima una crescita della domanda del 40%), il budget IT cresce ma in modo non proporzionale alla domanda e gran parte di esso viene inevitabilmente investito in attività di integrazione, per cui il risultato è una difficoltà di delivery dei servizi. In un contesto competitivo altamente variabile e incerto, un fattore determinante di successo è dato non tanto da un un’economia di scala ma da un’economia di velocità: essere veloci nel rispondere ai cambiamenti delle esigenze di business, al variare delle priorità delle evolutive in backlog, poter adattare modalità e finalità di utilizzo dei dati in tempi brevi e cambiare agilmente la direzione strategica sono aspetti di fondamentale importanza.
In aggiunta ai costi diretti, è doveroso considerare anche la perdita indiretta che un’azienda subisce se non sfrutta al meglio il valore potenziale dei dati. Infatti, se questi rimangono confinati all’interno dei database privati delle singole applicazioni e, per ogni necessità esterna all’applicazione, bisogna mettere in opera una nuova soluzione di integrazione ad-hoc con il sistema consumatore, è difficile riutilizzare i dati per abilitare servizi data-driven e applicazioni analitiche avanzate (casi d’uso molto richiesti oggigiorno, come monitoraggio in real time dei processi, previsioni e modelli di machine learning, identificazione di frodi, sistemi di raccomandazione, customer data platform, solo per citarne alcuni).
Pertanto è necessario rivedere le priorità che diamo nella progettazione delle architetture aziendali. Buona parte dello sforzo di design di un’architettura IT dovrebbe essere dedicato alla strategia di gestione dei dati: i componenti nell’architettura che salvano, elaborano, orchestrano e distribuiscono i dati sono quelli che avranno il peso specifico più determinante nelle scelte di evoluzione. Infatti, uno dei fattori primari che si considerano nel valutare migrazioni di prodotti o revisioni architetturali è l’incidenza della Data Gravity: tipicamente migrare una funzionalità software in un’altra applicazione è un’attività meno onerosa che spostare grossi volumi di dati in un nuovo sistema, che solitamente comporta la necessità di gestire i costi di trasferimento, la compatibilità dei modelli, l’allineamento continuo durante il transitorio e la gestione del caricamento iniziale.
Dopo questa breve introduzione alle sfide che l’IT si trova a dover affrontare nell’era moderna, nei prossimi articoli di questa serie cercheremo di delineare i pillar su cui si basano la visione architetturale e di data management che, come Quantyca, proponiamo ai clienti per rispondere alle loro necessità digitali. Ogni realtà aziendale ha il suo contesto e le sue esigenze peculiari, pertanto non esiste una strategia unica e perfetta per ogni organizzazione, al contrario l’architettura IT ottimale per un’azienda è spesso riflesso dell’organizzazione e della cultura aziendale: esistono però dei buoni principi che tracciano la direzione da seguire nell’evolvere l’architettura dati, per raggiungere l’agilità necessaria per la richiesta digitale di oggi e di domani.
In questa serie di blog post inizieremo illustrando il valore del principio di centricità dei dati, sostenendo l’approccio proposto dal Data Centric Manifesto, in cui i dati sono considerati come asset condivisi e riusabili a livello di intera organizzazione, che oltrepassano il perimetro di una singola applicazione. Vedremo poi la differenza tra i concetti di Data On The Inside e Data On The Outside, che pone le basi per gli stili di integrazione moderni. Continueremo poi il percorso ponendo l’attenzione sul principio di governo di un’architettura IT, entrando nel merito delle tematiche specifiche di Data Governance e di automazione metadata-driven. Concluderemo parlando del principio di adattabilità che, sotto l’aspetto tecnologico e architetturale trova concretizzazione nella proposta dei modelli di Data Fabric e Data Mesh. Quest’ultimo, in particolare, sfruttando l’influenza rilevante del Domain Driven Design sul mondo dati, aggiunge un’ulteriore dimensione di adattabilità, proponendo modelli organizzativi federati e decentralizzati, per massimizzare la rapidità di delivery dei progetti di data management.
