L’evoluzione del software per database e dei nuovi strumenti della business intelligence punta verso una nuova cultura aziendale basata sulla centralità dell’informazione. Piccola guida tecnica e procedurale alla data governance
La data governance è il fondamento delle modalità attraverso le quali una organizzazione aziendale intende gestire i dati digitali, utilizzando nel modo più efficiente possibile dati ritenuti affidabili. Una gestione efficace del patrimonio rappresentato dai dati richiede una serie di meccanismi di controllo centralizzati. Potremmo definire il concetto di data governance, come quell’insieme di persone, tecnologie e processi necessari per gestire e proteggere i “data asset” di una azienda e per garantire che i dati aziendali siano sempre il più possibile comprensibili, corretti, completi, affidabili, sicuri e accessibili. Ma la materia abbraccia tanti aspetti, sfaccettature, sottodiscipline. Fanno parte di una buona politica di data governance le architetture, la qualità dei dati, la capacità di costruire modelli e simulazioni, un approccio corretto ai meta-dati che servono per classificare l’informazione, i sistemi e le operazioni di storage, la sicurezza, i sistemi di data warehousing e gli strumenti di business intelligence, l’integrazione e l’interoperabilità, i documenti e i contenuti aziendali, i modelli di riferimento qualitativi.
In sostanza, una strategia di data governance punta a stabilire una serie di metodiche e un modello organizzativo con chiare responsabilità e processi finalizzati a standardizzare, integrare, proteggere e archiviare i dati aziendali. Con l’obiettivo di minimizzare i rischi, stabilire delle regole interne, implementare i requisiti imposti dalla compliance (una questione diventata prioritaria per tutte le realtà di una certa dimensione con l’avvento del GDPR), migliorare la comunicazione interna ed esterna, massimizzare il valore dei dati riducendone al tempo stesso i costi e facilitando la continuità del business, proprio grazie all’ottimizzazione e una corretta gestione del rischio legato alla perdita o la corruzione del dato.
COME DARE VALORE AI DATI
Un programma di data governance si può articolare in generale su tre livelli: gli strumenti tecnologici, le regole e le funzioni di gestione e controllo. Si parte dalla definizione strategica, che ricade su linee di azione tattiche e queste a loro volta si traducono, sul piano operativo, in una serie di procedure. Ma bisogna affrontare simultaneamente anche tre aspetti, agendo e dando risposte da un punto di vista organizzativo (“chi” e “dove”); di business (“che cosa” e “perché”); e tecnico (“come”). Su questo ultimo punto in particolare si concentrerà questo dossier dedicato alla cultura del business data driven per capire in che misura l’evoluzione delle piattaforme di conservazione (database in primo luogo ma anche sistemi di storage, security), organizzazione (data warehouse e data lake) e messa a valore dei dati (integrazione, virtualizzazione, analytics) viene incontro ai principi di fondo della data governance.
Questo dossier è anche una buona occasione per cercare di fare il punto sull’evoluzione degli strumenti che organizzazioni aziendali, istituzioni, pubbliche amministrazioni hanno a disposizione per affrontare la problematica dei dati digitali e della loro valorizzazione, con una concisa panoramica sull’evoluzione di tali strumenti. In particolare, gli ambienti di database utilizzati per la conservazione e la registrazione di informazioni e gli ambienti di data warehouse rivolti in modo più specifico alle applicazioni analitiche e business intelligence. Entrambe le realtà hanno risentito molto del cambiamento di paradigma che il software ha a sua volta vissuto con l’avvento del cloud computing, delle applicazioni distribuite, sempre più orientate alla mobilità dei suoi utenti, e sotto fattori concomitanti come il grande sviluppo della progettualità open source e dei trend che riguardano tutti i segmenti dedicati al trattamento dei dati nel mercato delle soluzioni proprietarie. Essere al corrente di tutte queste evoluzioni può aiutare i decisori che nell’ambito delle rispettive organizzazioni stanno affrontando la questione di una corretta “politica” del dato.
QUALITÀ E AFFIDABILITÀ PER DECIDERE
Come sempre, al nostro fianco nella creazione di questi scenari, gli analisti di IDC Italia offrono la loro guida specializzata. Perché oggi è importante assicurare ai dati un ambiente di archiviazione e analisi curato dal punto di vista qualitativo? «Uno dei principali obiettivi dei progetti di trasformazione digitale delle aziende è quello di utilizzare i dati per abilitare decisioni in tempo reale. I dati sono oggi uno degli asset maggiormente strategici per le aziende, al centro delle attività di business e in grado di fornire un vantaggio competitivo» – afferma Diego Pandolfi, research & consulting manager di IDC Italia. Riuscire a produrre dati, catturarli attraverso le interazioni con i clienti, intercettarli dai costanti flussi generati dalle piattaforme digitali, dai siti Web, dai canali di interazione social, non è più sufficiente di per sé. «Da soli – prosegue Pandolfi – i dati non forniscono un valore distintivo alle aziende. Ma è il modo in cui tali dati sono gestiti e analizzati a rappresentare un vantaggio competitivo. Per questo, si rende necessario utilizzare dati di qualità e in maniera sicura. In questo scenario, la data governance rappresenta oggi una strategia fondamentale in grado di garantire alle aziende l’utilizzo di dati affidabili e di elevata qualità».
Semplificando molto, esistono due grandi domini di relazione che caratterizzano il ruolo delle informazioni digitali. Due modi di interagire e utilizzare il dato. La relazione può essere transazionale, o analitica. La velocità del business e dell’amministrazione tecnologicamente mediati, rendono necessari – tanto più nell’epoca della trasformazione digitale dei processi – supporti e strumenti in tempo reale a queste due grandi classi di applicazioni. Si parla quindi tendenzialmente di sistemi di online transaction processing (OLTP) e online analytical processing system (OLAP). Per ciascun approccio, oltre ad ambienti di gestione di database (DBMS) general purpose adattati alle specifiche necessità, è possibile utilizzare modelli più specializzati e ottimizzati di database. Per esempio, è comune incontrare in letteratura e nel linguaggio del marketing la distinzione tra database e data warehouse, dove il primo fa da supporto ad attività di tipo transazionale: tipicamente quelle che descrivono per esempio l’acquisto di un oggetto su un sito di e-commerce, o un’operazione al bancomat. In questi casi, l’operazione di OLTP è quella che determina una o più variazioni rispetto al database di partenza. Il data warehouse è l’ambiente di archiviazione del dato specifico per le applicazioni analitiche: una piattaforma che si è evoluta nel corso del tempo in ambiti come la business intelligence. Tipicamente una attività OLAP ha appunto un obiettivo analitico, di solito al servizio di una decisione di business, presa sulla base di una conoscenza storica costituita da una estesa varietà di fonti informative. Il database, proprio perché deve rispondere a richieste molto precise, utilizza un modello ben strutturato e coerente internamente (tecnicamente si usa il termine “normalizzato”), mentre un data warehouse deve privilegiare la flessibilità e la possibilità di fare accostamenti meno precisi, di tipo probabilistico, partendo da informazioni non strutturate, spesso nemmeno di tipo alfanumerico o testuale ed è quindi “denormalizzato”.
DAL DATA WAREHOUSE AL DATA LAKE
Storicamente la tecnologia dei data warehouse si è sviluppata nell’ambito della disciplina della business intelligence. Un campo di ricerca che precede di molto l’avvento del Web (specie nella sua accezione “semantica”) e soprattutto del cloud e che come si diceva ha visto una straordinaria evoluzione. L’attuale versione di questo concetto – il data lake – ha una sua specificità su cui vale la pena soffermarsi brevemente. Ma torniamo altrettanto sinteticamente al database e ai suoi modelli strutturali, ai linguaggi di interrogazione/accesso utilizzati. Il concetto moderno di base dati è nato storicamente verso la metà degli anni 60 del secolo scorso, con l’invenzione di sistemi di archiviazione ad accesso o indirizzamento diretto, come i dischi rigidi e gli ormai estinti “tamburi”. Il nonno, se non bisnonno, degli attuali database utilizzava un modello “navigazionale”, che permetteva di collegare un “record” all’altro, seguendo una “pista” rappresentata da una catena di rimandi a un elemento successivo (un po’ come succede con blockchain), fino all’arrivo a destinazione, senza essere costretti a seguire il modello strettamente sequenziale di un nastro magnetico. Uno dei primi prodotti navigazionali fu in qualche modo legato al lavoro del comitato Data Systems Language, che addirittura alla fine degli anni 50 aveva iniziato a occuparsi di standardizzazione dei linguaggi di programmazione (il loro lavoro portò alla creazione del linguaggio Cobol, che era appunto pensato per il trattamento di lunghe liste di informazioni).
Con l’aumento della potenza e della capacità di archiviazione, nascerà presto l’esigenza di un modello più efficiente per gestire dati che tendevano a diventare sempre più complessi e importanti. Nel 1970, viene per la prima volta teorizzato il modello di database relazionale, che consentiva una maggiore velocità nell’accedere a un contenuto archiviato, rispetto a un metodo che comunque costringeva a rincorrere l’informazione desiderata un collegamento dietro l’altro. Ecco che arriva il database relazionale, anche se solo teoricamente. La tecnologia di allora non garantiva grandi performance, che sarebbero arrivate solo una decina d’anni dopo, in pieni anni 80, con la definitiva affermazione del modello di calcolo client/server e del database relazionale.
Questo si basa su un insieme di record che invece di essere rappresentati da liste collegate l’una all’altra, vengono rappresentati da tabelle di lunghezza fissa, con una tabella per ciascuna entità da rappresentare (per esempio, una tabella per l’indirizzo abitativo di persone, un’altra per i numeri di telefono). Una importante differenza rispetto ai precedenti modelli navigazionali è che nel database relazionale le tabelle sono normalizzate: a una certa posizione campo corrisponde un preciso valore e anche i campi vuoti hanno una loro importanza (nel navigazionale, un valore “0” veniva omesso del tutto. Altro grosso vantaggio era che in caso di correzioni o aggiunte, non bisognava riscrivere o ridare coerenza ai collegamenti tra un campo e l’altro.
OLTRE IL MODELLO RELAZIONALE
Cominciano con il relazionale a svilupparsi concetti come i linguaggi di interrogazione standard (SQL, standard query language) che accelerano lo sviluppo di soluzioni più specializzate. Nasce un mercato di vendor di database server, alcuni dei quali ispirati a criteri di offerta integrata, che poteva includere l’ambiente di DBMS direttamente implementato su hardware specializzato, per esempio per applicazioni analitiche e di supporto decisionale. Soprattutto comincia per i cosiddetti RDBMS, in abbinamento con SQL, un dominio culturale che dura ancora oggi, sebbene il modello relazionale abbia dovuto cedere il passo, con Big Data, a modelli alternativi, detti appunto “non relazionali”, sviluppati per rispondere al bisogno di strumenti più performanti in ambiti come Big Data e dei database distribuiti tipici del mondo cloud. Alla fine degli anni 90, fu un ricercatore ed esperto Linux italiano, Carlo Strozzi, a sviluppare un ambiente di database ancora relazionale ma non conforme allo standard SQL. Dieci anni dopo, nel 2009 il termine NoSQL, che definiva il progetto di Strozzi, viene utilizzato in un convegno in cui si discute di database distribuiti, non relazionali. Lo stesso Strozzi ha successivamente osservato che considerando che il suo iniziale progetto voleva discostarsi più dalla standardizzazione di SQL che dal modello relazionale in sé, oggi sarebbe più appropriato parlare di ambienti NoREL. Ma si tratta di sottigliezze linguistiche. L’ultimo decennio è stato caratterizzato da un’esplosione di progetti di sviluppo di strumenti di gestione di database, in molti casi open source, che si discostano anche in modo radicale dal modello relazionale per raggiungere diversi obiettivi di ottimizzazione: l’uso di un minor volume di risorse di memoria, la velocità, la scalabilità, la capacità di adattarsi a informazioni sempre meno strutturate e appunto “normalizzate”, o di rispondere meglio ai requisiti di strumenti di analisi evoluti, come il machine learning, il deep learning, l’intelligenza artificiale, la semantica, la linguistica.
Si riconoscono almeno quattro modelli principali di sistemi di database NoSQL, in uno spettro di almeno una decina di varianti. Wide-Column, per esempio, descrive un modello che parte dalle tabelle relazionali, senza però imporre vincoli di lunghezza e tipo di valore costante nelle colonne (Apache Cassandra, utilizzato per gestire grandi volumi di dati in cluster distribuiti, è un esempio, ma anche BigTable, il sistema di storage di Google, applica un analogo modello). Key-value, un modello basato sulla libera associazione tra “chiavi” e valori (array associativi) molto semplice e performante come modello per lo storage di dati ma non interfacciabile tramite un linguaggio di query. Un database NoSQL documentale è particolarmente indicato per oggetti, o “documenti”, rappresentati attraverso linguaggi come l’Xml (Amazon DocumentDB o MongoDB sono due esempi). E infine a grafo, dove la relazione tra i valori immagazzinati è raffigurabile in nodi e archi, come in Neo4j e Apache Giraph: un modello utilizzato per memorizzare informazioni pertinenti a relazioni sociali, collegamenti coi trasporti pubblici, mappe stradali, topologie di rete.
VERSO NUOVI LINGUAGGI
Il superamento del modello relazionale ha portato anche nuovi linguaggi di interrogazione e nuovi linguaggi per la codifica di applicazioni DB. Tra i più utilizzati SPARQL classificato tra i linguaggi semantici della famiglia RDF (resource description framework) del W3C, originariamente studiata come modello generale per i metadati. Mentre in parallelo allo sviluppo dei progetti NoSQL/NoREL, una nuova generazione di database relazionali cerca di promuovere la robustezza e la semplicità del modello relazionale senza sacrificare performance e scalabilità. Origine di molti progetti è il “cloud database” di Google, Cloud Spanner, che ha ispirato lo sviluppo di CockroachDB, mentre NuoDB si avvale di uno strato di elaborazione transazionale che aggrega diversi nodi di processamento in-memory in funzione del carico di lavoro.
Nelle loro strategie di trasformazione, quando l’obiettivo è cercare di essere data driven, le aziende sono sempre più propense ad adottare tecnologie di data warehousing di nuova generazione per consolidare volumi di dati imponenti, generati da strumenti applicativi convenzionali e da stream completamente nuovi come l’IoT o i canali social. Questi progetti tendono però a non utilizzare più le tradizionali piattaforme on premises, puntando piuttosto a far leva sulla già consistente offerta di “cloud data warehouse”: Snowflakes, AWS Redshift, Azure SQL Data Warehouse, Google BigQuery. Inoltre, man mano che i dati stessi assumono un carattere destrutturato, le aziende data driven si trovano davanti alla scelta tra una business intelligence basata su data warehouse – un approccio sensato quando il management ha già un’idea precisa delle cose che andrà a chiedere a questi dati – e una modalità di raccolta dati non ancora finalizzata. In quest’ultimo caso, un approccio consigliabile può essere quello del data lake, una piattaforma orientata allo storage di dati non strutturati e alle analisi condotte più con lo spirito del data scientist che con quello del tipico business user. Termine coniato nel 2011 da James Dixon dell’azienda di business intelligence Pentaho (poi acquisita e confluita in Hitachi Vantara) come evoluzione del concetto di “datamart” – il data lake oggi è al centro delle strategie di aggregazione in un unico repository, attraverso piattaforme fortemente integrate, di tutte le attività di archiviazione e analisi delle informazioni di una organizzazione, anche se non mancano voci critiche nei confronti di questo approccio. Dal punto di vista delle piattaforme, anche qui si assiste al passaggio da piattaforme on premises come Apache Hadoop ad ambienti cloud data lake come Azure Data Lake.
CHE COSA SIGNIFICA DATA GOVERNANCE
Data governance significa costruire intorno alle applicazioni e all’analisi un ecosistema di procedure, funzioni organizzative e strumenti mirato ad assicurare la qualità, la compliance, la sicurezza, l’ottimizzazione dei costi e il rispetto delle norme. Un lavoro – spiega Diego Pandolfi di IDC Italia – che deve tener conto di diverse dinamiche. «Innanzitutto, l’evoluzione della normativa, che ha incrementato i requisiti di integrità, privacy e sicurezza. Il GDPR, entrato in vigore nel maggio 2018, ha introdotto regole più chiare sull’informativa e sul consenso al trattamento dei dati, definendo dei limiti al trattamento automatizzato e stabilendo anche nuovi diritti (per esempio, il diritto all’oblio), fissando criteri per il trasferimento dei dati al di fuori del territorio UE, nonché sanzioni in caso di violazione delle regole e in caso di data breach». In base a una recente survey condotta da IDC in Europa, la security si conferma una delle priorità strategiche fondamentali per le aziende. Le priorità di investimento in ambito sicurezza si focalizzano su data loss/leakage prevention, sulla compliance, su identity management e su data privacy. Ma anche le evoluzioni dei sistemi e delle infrastrutture tecnologiche stanno impattando le strategie di data governance. L’evoluzione degli ambienti IT verso modelli ibridi, ossia basati su piattaforme on-premise, su public cloud e su private cloud, e verso modelli distribuiti (per esempio, edge computing) rappresenta infatti una nuova sfida per la data governance. Negli ambienti ibridi odierni nei quali le aziende si trovano a operare, l’esposizione a rischi (perdita o furto di dati) può essere maggiore. Inoltre, i dati stessi si presentano sotto differenti e numerosi formati e sono generati e raccolti da tecnologie e strumenti di varia natura (macchinari, prodotti connessi, utenti). Queste dinamiche stanno imponendo alle aziende di adottare innanzitutto un approccio integrato e centralizzato, in grado di gestire e analizzare i dati a prescindere dalla loro collocazione. Inoltre, diventa oggi necessario l’utilizzo di sistemi di data management in grado di lavorare con dati di diverso formato, strutturati e non strutturati, e con un’ampia copertura di workload.
«Una corretta strategia di data governance richiede infine un ripensamento dei modelli organizzativi interni alle aziende, dei processi e delle policy» – afferma Pandolfi. «Risulta importante, infatti, sviluppare una cultura del dato in tutta l’azienda, aiutando i dipendenti a considerare i dati come un asset strategico e la data governance come un building block fondamentale della digital transformation. Inoltre, la data governance necessita di essere un imperativo multi-stakeholder, non esclusivamente una priorità dell’IT». Per efficientare le attività di data governance, le aziende possono oggi accedere a software di data intelligence, machine learning e artificial intelligence, in grado di automatizzare i controlli su enormi quantità di dati, con benefici evidenti sulle attività di master data management, data cataloging e data profiling. In base a una recente ricerca condotta da IDC, circa l’80% del tempo (ore per settimana) dedicato ai dati da parte delle aziende viene impiegato per attività di gestione dei dati stessi, ossia ricerca, preparazione, pulizia, protezione. Solo il 20% del tempo viene invece dedicato ad attività di analisi, volte a estrarre valore per il business e per prendere decisioni. Attraverso l’utilizzo di questi strumenti, le aziende potranno ridurre il tempo dedicato alla preparazione dei dati e dedicarsi maggiormente alle analisi di valore e alla produzione di insights di business.
