L’approccio data-centrico che cambia l’IT
Abstract
Questo è il secondo articolo 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.
Per chi non lo avesse letto, consiglio di leggere l’articolo introduttivo della serie, dal titolo “I principi di un moderno Data Management”, in cui abbiamo descritto i driver che spingono verso la ricerca di un cambio di paradigma nella progettazione delle architetture dati.
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’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
La spinta verso un nuovo paradigma data-centrico
Nell’articolo precedente, “I principi di un moderno Data Management”, abbiamo descritto le sfide che l’IT si trova di fronte nella nuova era di digitalizzazione, caratterizzata da una produzione e un consumo di dati di volumi, varietà e finalità di utilizzo di gran lunga superiori al passato, oltre che dalla presenza, all’interno delle architetture enterprise, di un numero molto più rilevante di applicativi che devono cooperare. La necessità di razionalizzare e ottimizzare le integrazioni e di riutilizzare gli stessi dati per processi e finalità differenti impone un cambio di prospettiva, per garantire all’IT di spendere al meglio il budget a disposizione e rilasciare le funzionalità digitali data-driven nei tempi rapidi richiesti da un contesto di business sempre più competitivo e incerto, in cui la possibilità di sperimentare diventa un potenziale fattore importante di profitto.
Il cambio di prospettiva non può che partire dal riconoscere che il vero valore digitale di un’organizzazione è costituito dai dati che l’azienda produce, utilizza ed elabora. Le applicazioni, nell’implementare le funzionalità di business, sono certamente importanti ma, in un certo senso, anche effimere e sostituibili. I dati persistono al di là del ciclo di vita dei sistemi stessi e possono essere riutilizzati per molteplici scopi: sono a tutti gli effetti gli asset digitali aziendali. Come vale per tutti gli altri tipi di asset delle aziende tradizionali, i dati, per essere sfruttati al meglio, dovrebbero essere controllati, resi accessibili facilmente e in sicurezza e condivisi a livello di intera organizzazione, per abilitare processi diversi da quelli all’interno dei quali sono stati generati.
Il design di un’architettura IT aziendale deve partire dall’identificare quali sono i data asset di rilevo per l’azienda, mediante un’analisi approfondita del dominio di business, dei concetti e dei processi core e una conseguente modellazione semantica dei dati, con uno sforzo congiunto tra il personale del team business e lo staff IT. La scelta dei prodotti che implementano le applicazioni aziendali dovrebbe essere coerente con la strategia di gestione dei dati che si intende perseguire.
Un data asset core rappresenta, dal punto di vista logico e fisico, un concetto informativo di primaria importanza per il business dell’azienda. Ogni data asset è generato da parte di un’applicazione, che nel libro “Data Management At Scale” è detta golden source (o, alternativamente, data provider) del dato stesso. In quanto tale, l’applicazione è responsabile di produrre e condividere i dati, assicurarne la comprensibilità, la qualità e la consistenza, ma non ne è proprietaria esclusiva: i dati sono un bene condiviso, un asset aziendale, pertanto l’applicazione deve entrare in una prospettiva di cooperazione per favorirne l’accesso, l’utilizzo, l’integrazione e la distribuzione ad altre applicazioni nel modo più efficiente ed efficace.
In termini concreti, questo significa che l’applicazione deve fornire delle interfacce (chiamate anche data endpoint) facilmente accessibili, sicure e auto descrittive per permettere di estrarre i dati in un formato aperto secondo gli standard più comunemente usati nelle tecniche di data management moderne: infatti, i data asset non devono rimanere confinati all’interno delle applicazioni, come by product, ma devono essere fisicamente portati al centro dell’architettura, devono risiedere nel data layer. Inoltre, le applicazioni di dominio (system of records) non dovrebbero ricoprire il ruolo di hub di elaborazione, trasferimento o distribuzione di dati ad altri sistemi: queste non sono le attività per cui tali applicazioni sono ottimizzate e rischiano di degradarne le performance per le finalità operazionali critiche per il business, che sono invece i compiti primari che le applicazioni dovrebbero assolvere.
La nuova prospettiva proposta viene definita data-centrica. Il “Data Centric Manifesto” illustra in modo chiaro i principi alla base dell’orientamento data-centrico. La tabella seguente, presente nel Manifesto, riassume le differenze tra un approccio application-centrico, che rappresenta lo stato dell’arte per diverse aziende, e un approccio data-centrico, che dovrebbe invece essere la direzione da perseguire per l’evoluzione presente e futura.
Possiamo riassumere i punti salienti dicendo che un approccio data-centrico di design delle architetture enterprise permette di abbassare i costi di integrazione e del cambiamento, rendendo sostenibili i progetti IT e abbassando il rischio di investimento; il data-centrismo favorisce inoltre l’adattabilità delle architetture aziendali, rendendole pronte ad evolvere rapidamente in risposta ad un contesto di business altamente variabile e incerto e permette di estrarre dai dati un valore strategico e trasversale per l’azienda, da sfruttare come elemento differenziante rispetto ai competitor.
In un’architettura pensata con un paradigma data centrico, i processi di offloading dei dati dalle applicazioni sorgenti sono impostati non con l’obiettivo di alimentare un sistema consumatore specifico per soddisfare le esigenze di un particolare caso d’uso di cui è stata fatta richiesta all’IT nel momento in cui è emersa l’esigenza, quanto piuttosto di estrarre e mettere a disposizione i dati su una piattaforma condivisa con un tracciato e un formato sufficientemente generico da rispondere alle aspettative di applicazioni differenti, che in qualunque momento possano richiedere di utilizzare i dati, in un’ottica di sottoscrizione. Nella prospettiva descritta, il design del modello dati e delle integrazioni è orientato più al significato e al valore del dato di per sè, rispetto che ai requisiti di un particolare use case.
In questo modo, si evita di moltiplicare l’implementazione dei processi (e di conseguenza i costi) di estrazione dalle sorgenti per ogni necessità differente di utilizzo degli stessi dati: questi ultimi sono già a disposizione sulla piattaforma di integrazione, a cui un potenziale nuovo sistema può agganciarsi per fruirne.
Data On The Outside versus Data On The Inside
Pat Helland, nel suo whitepaper intitolato “Data on the Outside versus Data on the Inside”, mette in luce la differenza tra le caratteristiche del modello dati interno di un’applicazione, a cui fa riferimento con il termine di “Data On the Inside”, e le caratteristiche dei dati di interesse generale che un’applicazione dovrebbe mettere a disposizione degli altri sistemi IT, detti “Data On The Outside”.
La maggior parte delle applicazioni software moderne è generalmente caratterizzata da un’architettura interna a livelli, detta layered architecture, in cui si distinguono il livello più alto, detto di presentation, costituito dall’interfaccia utente, il livello di business, che contiene le logiche funzionali, e infine il livello di persistence, detto anche livello dati, che implementa il modello dati interno dell’applicazione in un database dedicato. Quest’ultimo è ad uso privato dell’applicazione e, di conseguenza, viene progettato secondo il formato di rappresentazione dati e la tecnologia di data store più congeniale alle logiche funzionali che l’applicativo implementa. Si tratta dei Data On the Inside.
A livello concreto, questo significa che il software engineer, nella fase di design di un’applicazione, sceglie se rappresentare i dati in un modello document-oriented, in uno schema relazionale piuttosto che in un altro formato, che grado di normalizzazione adottare, quali tipi di dato utilizzare tra quelli messi a disposizione dal DBMS scelto e quali campi tecnici introdurre, in funzione esclusivamente delle esigenze dei layer superiori dell’applicazione, che tipicamente avranno necessità di creare dati, leggerli, modificarli o cancellarli, molto spesso secondo il modello CRUD. Nel caso in cui si utilizzi un data store relazionale, solitamente le modifiche nel livello dati sono gestite dall’applicazione con un modello di consistenza transazionale (ACID); inoltre, il layer delle Application Programming Interface (API), esposte dal livello di business, maschera i dettagli del modello dati all’esterno, secondo i buoni principi di information hiding ed encapsulation.
La mentalità application-centrica che si è consolidata negli anni ha portato i software architect e i software engineer a concentrare la maggior parte degli sforzi di progettazione sui Data on the Inside e sui layer applicativi, come se la responsabilità dell’applicazione si esaurisse all’interno del suo stesso perimetro e si limitasse a soddisfare al meglio i requisiti di dominio per cui è stata realizzata.
Secondo quanto discusso in precedenza, al giorno d’oggi una prospettiva simile inizia a mostrare i suoi limiti: la necessità di integrazione tra le applicazioni, l’esigenza di condivisione e riuso dei data asset core di importanza strategica per l’azienda sono inevitabili. Per questo motivo, l’attività di sviluppo e di design di un’applicazione moderna dovrebbe considerare come uno dei punti di maggior valore la modellazione semantica e fisica dei dati che dovranno essere messi a disposizione per l’integrazione con gli altri sistemi. Tali dati costituiscono i Data On The Outside: al contrario dei Data on The Inside, non si tratta di dati ad uso privato ed esclusivo dell’applicazione, ma di dati condivisi con il resto dell’architettura IT, pertanto è necessario che siano rappresentati in un formato orientato alle esigenze dei consumatori, autodescrittivo e aperto, facilmente comprensibile e che siano resi fruibili in modo efficace tramite diversi pattern di accesso. Un’applicazione che funge da data provider di certi dati è responsabile (accountable) della consistenza, della qualità e della sicurezza dei Data On The Outside che espone al mondo esterno.
Come esempio, consideriamo i dati delle prenotazioni di un’azienda di viaggi, il cui ciclo di vita è gestito da servizi di back-end del portale web aziendale: ipotizziamo che una prenotazione venga rappresentata all’interno del layer di persistenza dell’applicazione con un modello relazionale, tramite una struttura di “testata” con le informazioni generali della prenotazione, una o più strutture di dettaglio in base al tipo di soluzioni (alloggi, trasporti, altri servizi…) inserite nella prenotazione, in relazione N:1 con la tabella di testata, contenenti diversi attributi specifici del tipo di soluzione. Considerando la totalità degli attributi rappresentati, probabilmente non tutti sono di interesse a livello aziendale al di fuori dell’applicazione web, per abilitare altri processi.
Pertanto, fare un’adeguata modellazione dei Data On The Outside richiede prima di tutto di porsi quesiti come i seguenti: che cos’è una Prenotazione dal punto di vista logico di business? Quali attributi semantici basilari sono di rilievo trasversale per l’azienda? Che significato hanno? Che tipo di valori possono assumere? Quali sono le regole invarianti che gli attributi devono garantire? Questo tipo di analisi non dovrebbe essere portata avanti considerando le esigenze specifiche di un unico sistema consumatore, come può essere il data warehouse, la Business Intelligence, o le richieste del team di data science, al contrario dovrebbe tenere un approccio più generale, finalizzato ad identificare le informazioni importanti per un qualunque processo aziendale che ne possa far richiesta.
Una volta completata la modellazione semantica e definito il set di informazioni da rendere accessibili per le integrazioni, si passano in rassegna aspetti più tecnici: ad esempio, a prescindere dalla rappresentazione relazionale del modello interno, si potrebbe valutare di esporre ogni prenotazione ai sistemi esterni come unico oggetto document-oriented, con le informazioni generali al livello più alto e le entry di dettaglio rappresentate su livelli innestati, scegliendo JSON come formato di rappresentazione e mappando i nomi dei campi relazionali del modello Data On The Inside con nomi comprensibili e agnostici dalle specificità dell’applicazione, da utilizzare nei Data On The Outside esposti.
A differenza del modello interno dei Data On The Inside, su cui l’applicazione mantiene totale autonomia e libero arbitrio nell’effettuare modifiche o evolutive, le interfacce che espongono i Data On The Outside al resto dell’architettura dovrebbero rispettare delle regole di evolvibilità concordate a livello di governance aziendale e garantire determinati livelli di servizio definiti in documenti detti data delivery contract.
Nella nuova visione data-centrica, in base a quanto discusso, un’applicazione non solo mantiene la sua importanza funzionale, ma soprattutto assume rilevanza nel suo ruolo di data provider, di produttore di asset digitali afferenti ad un determinato ambito del dominio aziendale.
A questo punto sorge però una domanda: come l’applicazione può esporre in modo ottimale e funzionale ai consumatori i dati core di cui è responsabile, per portarli al centro dell’architettura? Quali tecnologie e metodologie si rendono necessarie?
Per rispondere è necessario introdurre i concetti di Data Governance e Data Fabric, che tratteremo nei prossimi due articoli.
