Negli ultimi anni, le organizzazioni hanno investito ingenti risorse nella raccolta di informazioni. Hanno implementato CRM, ERP, piattaforme di e-commerce, strumenti di analisi, sistemi di assistenza clienti e applicazioni interne. Ogni nuova soluzione prometteva una maggiore visibilità sulle operazioni, ma creava anche un'ulteriore fonte di dati, nuove definizioni e ulteriori integrazioni da gestire.
Il risultato è una frequente contraddizione. L'azienda possiede milioni di record, ma i vari reparti continuano a discutere su quale cifra sia corretta. Il marketing riporta un numero di clienti, le vendite un altro e la finanza ne utilizza una terza definizione. La stessa metrica cambia a seconda del sistema consultato, del momento della raccolta dei dati o della persona che ha redatto il report.
Questa frammentazione era problematica quando i dati venivano utilizzati principalmente nei report. Con l'avvento dell'intelligenza artificiale e degli agenti aziendali, il rischio aumenta. Un sistema automatizzato non può interrompere una riunione per chiedere quale definizione utilizzare. Elabora le informazioni disponibili e produce una risposta, una raccomandazione o un'azione.
Pertanto, la sfida non consiste più semplicemente nell'archiviare i dati. Si tratta di trasformarli in risorse affidabili che possano essere scoperte, comprese e utilizzate in modo coerente. Questo è lo scopo di... prodotti dati.
Un prodotto dati è un insieme di informazioni progettato per soddisfare una specifica esigenza dell'utente. Può assumere la forma di una tabella, un'API, un modello analitico, un flusso di eventi, una dashboard o una combinazione di diversi componenti. La differenza rispetto a un dataset tradizionale è che viene gestito come un prodotto con responsabilità, utenti, documentazione, criteri di qualità e un ciclo di vita definiti.
Google Cloud descrive l'approccio data mesh come un framework architetturale e organizzativo che considera i dati come prodotti sviluppati dai team che meglio comprendono ciascun ambito aziendale. Questi team devono aderire a standard di governance comuni affinché le informazioni possano essere reperite e utilizzate in modo coerente in tutta l'organizzazione.
Consideriamo un prodotto chiamato "Cliente a 360 gradi". Non dovrebbe essere semplicemente una tabella con nomi, indirizzi email e acquisti. Deve definire cosa costituisce un cliente attivo, quali sistemi forniscono le informazioni, con quale frequenza vengono aggiornate, quale livello di qualità offrono e chi è responsabile in caso di errore.
Il prodotto fa molto di più che fornire dati. Offre la capacità affidabile di prendere decisioni sui clienti.
In molti sistemi aziendali, i dati compaiono come sottoprodotto delle operazioni. Un CRM registra le opportunità perché deve gestire le vendite. Un ERP memorizza le fatture perché deve supportare i processi finanziari. Una piattaforma di assistenza conserva le conversazioni per gestire i casi. Le informazioni esistono, ma non sono state necessariamente progettate per essere riutilizzate da altri reparti.
Quando un team di analisti deve combinare queste fonti, inizia un processo di interpretazione. Devono scoprire cosa rappresenta ciascun campo, quali record sono incompleti, quali regole utilizza il sistema e come un'entità si relaziona a un'altra. Una parte significativa del lavoro non è dedicata all'analisi, ma alla comprensione.
Questo modello favorisce la dipendenza dalla conoscenza informale. Una persona sa che una determinata colonna non dovrebbe essere utilizzata dopo un certo anno. Un'altra ricorda che alcuni record sono duplicati. Una terza conosce la query corretta per escludere i test interni. Quando queste persone cambiano ruolo, l'organizzazione perde parte del significato insito nei propri dati.
Un approccio incentrato sul prodotto richiede che tale conoscenza sia visibile. Le informazioni devono essere documentate, testate e mantenute in modo che altri consumatori possano utilizzarle senza dover dipendere costantemente da conversazioni informali.
Quando i dati vengono trattati come rifiuti tecnici, la loro qualità spesso non è responsabilità di nessuno. Il team che si occupa della fonte dei dati afferma di gestire solo l'applicazione. Il team di analisi riceve informazioni incomplete e cerca di correggerle. Le unità aziendali utilizzano report diversi e i problemi emergono solo alla fine del processo.
Un prodotto basato sui dati necessita di una chiara definizione delle responsabilità. Il team responsabile deve comprendere il dominio aziendale, chi utilizza le informazioni e mantenere un livello di servizio adeguato. Ciò non significa che una sola persona debba risolvere tutti i problemi tecnici e funzionali, ma piuttosto che vi sia una chiara responsabilità per l'affidabilità del prodotto.
Il modello di data mesh propone una struttura di proprietà orientata al dominio. Il reparto Vendite può essere responsabile dei prodotti relativi alle opportunità e ai potenziali clienti. Il reparto Finanza può gestire le informazioni relative a fatturazione, ricavi e pagamenti. Il reparto Risorse Umane può gestire i prodotti relativi ai talenti e alla struttura organizzativa.
Il decentramento non elimina la governance, ma ne cambia la forma. I team acquisiscono la responsabilità dei propri dati, ma operano secondo standard comuni che garantiscono interoperabilità, sicurezza e controllo.
Una delle differenze più importanti tra l'archiviazione dei dati e la creazione di un prodotto sta nel comprendere a chi è destinato. Un prodotto senza utenti definiti rischia di diventare semplicemente un'altra raccolta di informazioni che nessuno sa come utilizzare.
I consumatori possono essere analisti, applicazioni, dirigenti, modelli predittivi o agenti di intelligenza artificiale. Ognuno di essi richiede caratteristiche diverse. Un analista potrebbe aver bisogno di dati storici e flessibilità. Un sistema transazionale necessita di risposte rapide e contratti stabili. Un agente di intelligenza artificiale ha bisogno di un contesto comprensibile, autorizzazioni chiare e dati sufficientemente affidabili per supportare una decisione.
Progettare dal punto di vista del consumatore richiede di porsi domande specifiche. Qual è il problema che sta cercando di risolvere? Di quale livello di aggiornamenti ha bisogno? Qual è l'impatto di una risposta errata? Quali campi sono essenziali? Quali definizioni devono essere spiegate?
Google Cloud raccomanda che le architetture data mesh consentano diversi modelli di consumo e che gli utenti possano valutare se un prodotto è adatto alle loro esigenze, alla qualità e alle condizioni di accesso.
Il valore di un prodotto non risiede nel numero di colonne che contiene, bensì nella sua capacità di agevolare una specifica decisione o un determinato processo.
Un prodotto software non è considerato finito solo perché funziona una volta. Necessita di documentazione, supporto, metriche, versioning e meccanismi per gestire le modifiche. I prodotti basati sui dati richiedono una disciplina simile.
Devono essere facilmente reperibili, in modo che gli utenti sappiano che esistono. Devono avere una descrizione chiara, una proprietà ben definita ed esempi di utilizzo. Devono inoltre essere interoperabili, ovvero utilizzare standard che ne consentano l'integrazione con altri prodotti senza modifiche eccessive.
L'affidabilità è altrettanto importante. I consumatori devono conoscere la frequenza degli aggiornamenti, la completezza, la disponibilità e gli eventuali limiti. Se una fonte smette di ricevere informazioni per due giorni, il prodotto dovrebbe comunicarlo prima che un report o un agente utilizzi dati incompleti.
Martin Fowler sottolinea che la progettazione di prodotti basati sui dati implica l'automazione della governance e la garanzia che i team indipendenti seguano pratiche comuni che consentano l'interoperabilità su larga scala.
Il prodotto dati non dovrebbe essere valutato esclusivamente in base alla sua esistenza tecnica. Dovrebbe essere valutato in base alla sua utilità, affidabilità ed esperienza utente.
Uno dei problemi più gravi nell'architettura dei dati si verifica quando un sistema cambia senza avvisare gli utenti. Un team potrebbe modificare il nome di una colonna, cambiare il tipo di dati o rimuovere un valore che sembrava superfluo. L'applicazione originale continua a funzionare, ma i report, i modelli e le automazioni che si basavano su quella struttura iniziano a non funzionare correttamente.
Un contratto dati definisce formalmente cosa un consumatore può aspettarsi. Può includere schema, campi obbligatori, tipi, frequenza di aggiornamento, regole di qualità, proprietario e politiche di compatibilità. Il suo scopo è impedire che le dipendenze rimangano nascoste.
Virgin Media O2 ha spiegato come utilizza i contratti sui dati come livello di qualità e garanzia per assicurare che i set di dati pubblicati siano affidabili, documentati e pronti per l'uso.
Il contratto non deve necessariamente essere un documento scritto a mano e non aggiornato. Può essere espresso in formati leggibili dalle macchine e convalidato automaticamente all'interno dei processi. Se una modifica viola una condizione concordata, il sistema può bloccare la pubblicazione o avvisare le parti interessate prima che ciò abbia ripercussioni sui consumatori.
La fiducia non dipende più esclusivamente dalle conversazioni. Diventa una proprietà verificabile.
Ogni organizzazione ha bisogno di evolversi. Emergono nuovi settori, i processi vengono modificati e le definizioni aziendali cambiano. L'obiettivo di un contratto dati non è quello di cristallizzare la struttura in modo permanente, ma di gestire il cambiamento in modo responsabile.
Quando una modifica è compatibile, può essere implementata senza ripercussioni sui consumatori. Quando invece viola il contratto esistente, è necessario affrontare la questione con una nuova versione, un periodo di transizione o un preavviso. Questo dà ai team che si occupano dei consumatori il tempo di adattare i propri processi.
Questo approccio riduce i guasti silenziosi. Senza contratti, una colonna può continuare a esistere ma cambiare significato. La pipeline continua a funzionare e il problema si manifesta nel report sbagliato. Con regole semantiche e di qualità, l'organizzazione può rilevare quando le informazioni non soddisfano più le condizioni previste.
Il controllo delle versioni migliora anche la tracciabilità. Un team può sapere quale modello è stato utilizzato in una particolare versione di un prodotto e ricostruire il motivo per cui un risultato è cambiato.
Stabilità non significa assenza di cambiamento. Significa che il cambiamento avviene senza sconvolgere inaspettatamente l'ecosistema.
Molte organizzazioni scoprono problemi di qualità quando un dirigente mette in discussione un dato o un cliente riceve informazioni errate. A quel punto, inizia un'indagine che può coinvolgere diversi sistemi, consulenze e team. L'azienda corregge l'incidente, ma non sempre modifica il processo che ne ha permesso il verificarsi.
I prodotti dati richiedono un monitoraggio continuo. Questo può includere convalide per completezza, unicità, coerenza, aggiornamento e conformità alle regole di dominio. Una tabella clienti non dovrebbe accettare identificatori duplicati senza una spiegazione. Un prodotto di fatturazione deve rilevare valori negativi inattesi. Un flusso di inventario dovrebbe inviare un avviso quando smette di aggiornarsi.
Martin Fowler propone di utilizzare funzioni di fitness o funzioni di fitness Automatizzare le regole di governance e verificare continuamente se i prodotti soddisfano gli standard organizzativi.
La qualità non è un'attività finale svolta da un team separato. Deve essere integrata nel processo di sviluppo e implementazione. L'obiettivo è impedire che dati errati diventino una fonte di affidabilità per altri sistemi.
I modelli generativi possono produrre risposte convincenti anche quando le informazioni disponibili sono incomplete o contraddittorie. Questo rende la qualità del contesto particolarmente importante. Un agente connesso a fonti frammentate non acquisisce intelligenza semplicemente utilizzando un modello avanzato. Acquisisce piuttosto un modo più rapido per combinare le incongruenze.
Microsoft sottolinea che gli agenti sintetizzano le informazioni anziché creare i dati aziendali di cui hanno bisogno. Per questo motivo, la loro accuratezza dipende dalla qualità, dall'accessibilità e dalla governance delle fonti sottostanti. Informazioni frammentate o non controllate possono portare a risposte fuorvianti e a rischi per la sicurezza.
Un prodotto dati fornisce un contesto definito. Un agente di vendita può consultare un prodotto di opportunità attive invece di collegarsi direttamente a numerose tabelle non documentate. Un assistente finanziario può utilizzare un prodotto di ricavi validato con regole e responsabili noti.
Ciò riduce le ambiguità e facilita la valutazione. L'azienda può analizzare se l'agente ha utilizzato il prodotto corretto, quale versione ha consultato e quali limitazioni presentavano le informazioni.
L'intelligenza artificiale non elimina la necessità di un'architettura dati. La rende piuttosto molto più urgente.
Collegare un modello a tutti i database aziendali potrebbe sembrare un modo rapido per creare un assistente potente. Tuttavia, questo approccio crea problemi di sicurezza, semantici e di manutenzione. L'agente si imbatte in campi non documentati, dati sensibili e strutture progettate per esigenze interne che non dovrebbero essere utilizzate direttamente.
Il livello prodotto consente di controllare quali informazioni vengono rese disponibili al consumo. Ogni prodotto può esporre solo i campi necessari, applicare politiche sulla privacy e offrire definizioni adatte sia agli esseri umani che alle macchine.
Questa separazione protegge anche i sistemi operativi. Invece di eseguire query imprevedibili su applicazioni critiche, gli agenti utilizzano interfacce controllate, repliche o servizi progettati per l'analisi e l'intelligenza artificiale.
Le architetture moderne per gli agenti aziendali raccomandano un accesso sicuro e controllato a fonti strutturate e non strutturate, soprattutto quando i sistemi devono operare su piattaforme o cloud diversi.
L'obiettivo non è limitare artificialmente l'IA, bensì offrirle una superficie informativa che possa essere utilizzata con fiducia.
Uno dei progetti più comuni prevede la creazione di un'unica "fonte di verità". L'organizzazione raccoglie informazioni da diversi sistemi su una piattaforma centrale e si aspetta di risolvere automaticamente le incongruenze. Tuttavia, il consolidamento dei dati non elimina le differenze di significato.
Il reparto vendite potrebbe considerare cliente qualsiasi azienda con un'opportunità di vendita aperta. Il reparto finanziario potrebbe riconoscere come cliente solo le organizzazioni che hanno già ricevuto una fattura. Il reparto assistenza potrebbe collaborare con gli utenti finali anche in assenza di un rapporto contrattuale diretto. Nessuna di queste definizioni è necessariamente errata. Semplicemente, riflettono contesti diversi.
Un prodotto dati dovrebbe dichiarare quale definizione utilizza e per quali decisioni è appropriato. Invece di fingere che esista un'unica visione universale, l'architettura può offrire prodotti correlati ma semanticamente chiari.
Questa disciplina è particolarmente importante per l'intelligenza artificiale. Una domanda come "Quanti clienti abbiamo?" necessita di contesto. Senza una definizione esplicita, l'agente potrebbe scegliere un numero tecnicamente possibile e presentarlo con una sicurezza che l'azienda non dovrebbe concedere.
La qualità semantica è importante tanto quanto la qualità strutturale. Un campo può essere completo eppure completamente inutile se nessuno ne conosce il significato.
Il concetto di data mesh ha guadagnato popolarità, ma è stato anche eccessivamente semplificato. Alcune organizzazioni lo interpretano semplicemente come la fornitura a ciascun dipartimento di una propria piattaforma o di un proprio insieme di tabelle. Il risultato può essere una frammentazione ancora maggiore.
La rete di dati combina quattro principi: proprietà orientata al dominio, dati come prodotto, infrastruttura self-service e governance federata. La decentralizzazione funziona solo quando i team condividono standard, piattaforme e meccanismi di interoperabilità.
La governance federata consente di prendere decisioni più vicine al dominio senza compromettere la coerenza aziendale. Un team può avere una migliore comprensione della logica di vendita, ma deve comunque attenersi a regole comuni in materia di sicurezza, identificazione, documentazione e accesso.
Un'infrastruttura self-service riduce i costi di conformità a queste regole. Se ogni dominio deve creare le proprie pipeline, cataloghi e controlli, la strategia risulterà proibitivamente costosa. Una piattaforma comune trasforma le migliori pratiche in funzionalità riutilizzabili.
La rete di dati non è una tecnologia specifica. È un modello organizzativo e architetturale per scalare le responsabilità senza perdere il controllo.
Un catalogo tradizionale potrebbe mostrare nomi tecnici, posizioni e diagrammi. Questo aiuta a trovare le informazioni, ma non indica necessariamente se siano utilizzabili. Due prodotti possono contenere dati simili ma offrire livelli di qualità o aggiornamenti differenti.
Un catalogo orientato al prodotto deve includere scopo, proprietario, consumatori, qualità, provenienza, politiche di accesso ed esempi. Dovrebbe inoltre indicare se il prodotto è attivo, in fase di sviluppo o prossimo al ritiro.
La reperibilità delle informazioni riduce le duplicazioni. Quando i team non sanno quali informazioni esistono, creano nuove estrazioni e versioni parallele degli stessi dati. Ogni copia introduce costi aggiuntivi, regole diverse e nuove possibilità di incoerenza.
Per gli agenti di intelligenza artificiale, il catalogo può diventare un livello semantico che consente loro di selezionare le fonti appropriate. Tuttavia, questa capacità richiede metadati affidabili e gestiti in modo appropriato.
Un'organizzazione non trae valore dalla catalogazione di migliaia di tabelle che nessuno comprende. Il valore si ottiene quando un utente o un sistema può trovare rapidamente la fonte corretta e comprenderne le condizioni di utilizzo.
Quando ogni prodotto richiede lunghi processi manuali, i team cercano scorciatoie. Creano set di dati temporanei che finiscono per diventare permanenti, condividono file al di fuori delle piattaforme ufficiali o sviluppano integrazioni che nessuno documenta.
La governance dovrebbe essere integrata negli strumenti e nei flussi di lavoro. Le classificazioni sensibili possono essere applicate automaticamente. I contratti possono essere convalidati durante la fase di erogazione. Le politiche di accesso possono essere configurate in base a domini e responsabilità.
Google Cloud definisce la governance dei dati come un approccio che copre l'intero ciclo di vita, dall'acquisizione e dall'utilizzo fino alla cancellazione sicura, e sottolinea che il valore delle informazioni dipende dalla loro affidabilità, reperibilità e governance.
L'automazione permette di fare la scelta giusta anche nel modo più semplice. I team non dovrebbero dover completare decine di passaggi per pubblicare un prodotto di base se la piattaforma è in grado di applicare gli standard per impostazione predefinita.
Una governance efficace non impedisce alle persone di utilizzare i dati. Rende possibile l'utilizzo dei dati su larga scala senza compromettere la sicurezza o la fiducia.
Anche un prodotto ben progettato può deteriorarsi. Una fonte potrebbe smettere di inviare record, un'integrazione potrebbe iniziare a duplicarli o un aggiornamento potrebbe modificare una distribuzione critica. La pipeline potrebbe continuare a funzionare tecnicamente, anche se le informazioni non sono più valide per lo scopo previsto.
L'osservabilità dei dati analizza il comportamento, il volume, la freschezza, la distribuzione e la provenienza. Consente di identificare le anomalie prima che queste influenzino report, modelli o agenti.
Inoltre, facilita la valutazione dell'impatto. Se un prodotto subisce un incidente, la tracciabilità del prodotto aiuta a identificare quali pannelli, applicazioni e modelli dipendono da esso. Senza questa visibilità, l'organizzazione scopre i consumatori interessati gradualmente e solo a posteriori.
Per i sistemi di intelligenza artificiale, questa capacità è fondamentale. Un agente può continuare a rispondere anche se la sua fonte di dati ha smesso di aggiornarsi. L'architettura deve comunicare lo stato del prodotto e, quando il rischio lo giustifica, disabilitarne temporaneamente l'utilizzo.
La fiducia non dovrebbe essere binaria. I consumatori devono conoscere lo stato attuale delle informazioni e decidere se possono essere utilizzate per un consiglio, per l'automazione o per una decisione critica.
Spesso le organizzazioni si concentrano sulla creazione di nuove fonti di dati, ma poche eliminano quelle che non dovrebbero più essere utilizzate. Col tempo, si accumulano prodotti duplicati, versioni abbandonate e set di dati i cui responsabili sono passati ad altri reparti.
Ogni prodotto necessita di un ciclo di vita ben definito. Dovrebbe prevedere le fasi di progettazione, rilascio, funzionamento, evoluzione e dismissione. Quando una versione non è più consigliata, ai consumatori dovrebbe essere fornito un percorso di migrazione.
La rimozione della piattaforma impedisce che si trasformi in un catalogo di opzioni contrastanti. Riduce inoltre i costi di archiviazione, supporto e gestione.
Prima di rimuovere un prodotto, l'azienda deve comprenderne le dipendenze. Questo è un altro motivo per cui la tracciabilità e i contratti sono importanti. Un set di dati apparentemente inattivo potrebbe alimentare un'automazione mensile o un processo di cui nessuno si ricorda.
La gestione del prodotto richiede di prendere decisioni sulla continuità. Mantenere tutto indefinitamente non è una strategia di dati, bensì un accumulo tecnologico.
Il primo passo non dovrebbe essere quello di riorganizzare tutti i team o migrare immediatamente a una nuova piattaforma. È preferibile individuare un ambito con evidenti problemi di fiducia, duplicazione o accesso. Clienti, vendite, inventario o fatturazione sono spesso buoni candidati perché generano valore interfunzionale.
Successivamente, è necessario selezionare un caso d'uso specifico. Invece di creare un prodotto troppo generico, l'azienda può progettarne uno che risponda a un'esigenza specifica. Questo semplifica la definizione degli utenti, della qualità attesa e delle metriche.
In seguito, vengono definiti la proprietà, la documentazione, un contratto e i controlli automatizzati. Il prodotto viene pubblicato in un catalogo e il suo utilizzo viene monitorato. Questo feedback consente di apportare modifiche al design prima di estendere il modello ad altri ambiti.
Il successo iniziale non si misura dalla quantità di dati centralizzati, bensì dalla riduzione del tempo impiegato per reperire informazioni, dalla diminuzione degli errori e dal riutilizzo del prodotto in processi diversi.
La strategia dovrebbe basarsi su valori comprovati, non su una trasformazione teorica troppo complessa da realizzare.
Noi di The Cloud Group aiutiamo le organizzazioni a trasformare le informazioni frammentate in un'architettura affidabile per l'analisi, l'automazione e l'intelligenza artificiale. Il nostro lavoro inizia con la comprensione dei processi, dei sistemi di origine e delle decisioni che l'azienda deve migliorare.
Progettiamo prodotti dati, integrazioni, contratti, piattaforme cloud e modelli di governance che consentono un utilizzo coerente delle informazioni provenienti da CRM, ERP, applicazioni interne e fonti esterne. L'obiettivo non è semplicemente trasferire i dati su una nuova piattaforma, ma preservarne il significato, la qualità e la tracciabilità.
Offriamo inoltre supporto nella preparazione delle risorse per agenti di intelligenza artificiale e applicazioni generative, definendo chiaramente livelli di accesso, controlli di sicurezza e contesti aziendali. Un agente non dovrebbe essere costretto a navigare tra sistemi contraddittori nella speranza di trovare la verità. Ha bisogno di prodotti affidabili, progettati specificamente per la sua funzione.
L'intelligenza artificiale può accelerare i processi decisionali e automatizzarli, ma non può compensare indefinitamente un'architettura dati frammentata.
Perché prima di costruire un'azienda basata sull'intelligenza artificiale, è necessario costruire un'azienda capace di fidarsi delle proprie informazioni.
Si tratta di un insieme di dati progettato e gestito per rispondere a una specifica esigenza dei suoi consumatori. Comprende informazioni, documentazione, responsabili, regole di qualità, politiche di accesso e un ciclo di vita definito.
Un dataset è una raccolta di informazioni. Un prodotto dati aggiunge scopo, proprietà, standard di qualità, documentazione, supporto e condizioni di utilizzo. Il suo obiettivo è generare valore ricorrente e affidabile.
Si tratta di un accordo formale tra chi produce e chi utilizza le informazioni. Definisce schemi, campi, tipologie, frequenza di aggiornamento, regole di qualità e condizioni di compatibilità. Può essere convalidato automaticamente all'interno delle pipeline.
I prodotti forniscono ai sistemi di intelligenza artificiale fonti di informazione affidabili, documentate e controllate. Ciò riduce la probabilità che modelli e agenti utilizzino informazioni errate, obsolete o decontestualizzate.
Si tratta di un approccio architettonico e organizzativo che distribuisce la responsabilità dei dati tra i diversi ambiti aziendali. Si basa sulla proprietà decentralizzata, sui dati considerati come prodotto, sulle piattaforme self-service e sulla governance federata.
No. In genere, una struttura a rete di dati (data mesh) ha più senso in organizzazioni con domini multipli, team e sfide di scalabilità. Le aziende più piccole possono applicare i principi dei prodotti dati senza dover intraprendere una trasformazione organizzativa completa.
All'interno del dominio deve esserci un proprietario visibile che ne comprenda l'importanza aziendale. Possono essere coinvolti anche ingegneri dei dati, analisti, specialisti della sicurezza e gestori di piattaforma.
Attraverso dimensioni quali completezza, accuratezza, coerenza, unicità, freschezza e disponibilità. I parametri devono essere correlati alle reali esigenze dei consumatori.
La modifica deve essere valutata in base al contratto. In caso di incompatibilità, potrebbe essere necessaria una nuova versione, un preavviso e un periodo di transizione affinché i consumatori possano adattare i propri processi.
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
