Architettura e funzioni in un data mesh

Last reviewed 2022-10-06 UTC

Un data mesh è un framework architetturale e organizzativo che tratta i dati come un prodotto (definito in questo documento come "prodotti dati"). In questo framework, i prodotti dati vengono sviluppati dai team che comprendono meglio i dati e che seguono una serie di standard di governance dei dati a livello di organizzazione. Una volta eseguito il deployment dei prodotti di dati nel data mesh, i team distribuiti di un'organizzazione possono scoprire e accedere ai dati pertinenti alle loro esigenze in modo più rapido ed efficiente. Per ottenere un data mesh così ben funzionante, è necessario innanzitutto stabilire i componenti architetturali di alto livello e i ruoli organizzativi descritti in questo documento.

Questo documento fa parte di una serie che descrive come implementare un data mesh su Google Cloud. Presuppone che tu abbia letto e dimestichezza con i concetti descritti in Creare un data mesh moderno e distribuito con Google Cloud.

La serie è costituita dai seguenti componenti:

In questa serie, il data mesh descritto è interno a un'organizzazione. Sebbene sia possibile estendere un'architettura di data mesh per fornire prodotti dati a terze parti, questo approccio esteso non rientra nell'ambito di questo documento. L'estensione di un data mesh comporta ulteriori considerazioni oltre all'utilizzo all'interno di un'organizzazione.

Architettura

I seguenti termini chiave vengono utilizzati per definire i componenti architetturali descritti in questa serie:

  • Prodotto dati: un prodotto dati è un container logico o un raggruppamento di una o più risorse dati correlate.
  • Risorsa di dati: una risorsa di dati è un asset fisico in un sistema di archiviazione che contiene dati strutturati o archivia una query che restituisce dati strutturati.
  • Attributo dei dati: un attributo dei dati è un campo o un elemento di una risorsa di dati.

Il seguente diagramma offre una panoramica dei componenti architetturali chiave in un data mesh implementato su Google Cloud.

Componenti dell'architettura in un data mesh.

Il diagramma precedente mostra quanto segue:

  • I servizi centrali consentono la creazione e la gestione di prodotti dati, inclusi i criteri dell'organizzazione che interessano i partecipanti del data mesh, i controlli dell'accesso (tramite i gruppi di Identity and Access Management) e gli artefatti specifici dell'infrastruttura. Esempi di tali impegni e prenotazioni, nonché l'infrastruttura che facilita il funzionamento del data mesh, sono descritti in Creare componenti e soluzioni della piattaforma.
  • I servizi centrali forniscono principalmente Data Catalog per tutti i prodotti dati nel data mesh e il meccanismo di rilevamento per i potenziali clienti di questi prodotti. Per scoprire come registrare i prodotti dati nel catalogo dati, consulta Descrivere e organizzare i prodotti e le risorse dati in un data mesh.
  • I domini di dati espongono sottoinsiemi dei loro dati come prodotti dati tramite interfacce di consumo dati ben definite. Questi prodotti dati possono essere una tabella, una visualizzazione, un file strutturato, un argomento o un flusso. In BigQuery sarebbe un set di dati, mentre in Cloud Storage sarebbe una cartella o un bucket. Possono essere presenti diversi tipi di interfacce che possono essere esposte come prodotto dati. Un esempio di interfaccia è la vista di BigQuery su una tabella BigQuery. I tipi di interfacce più comunemente utilizzati per scopi analitici sono descritti in Creare prodotti dati in un mesh di dati.

Implementazione di riferimento del data mesh

Puoi trovare un'implementazione di riferimento di questa architettura nel repository data-mesh-demo. Gli script Terraform utilizzati nell'implementazione dei riferimenti dimostrano i concetti del data mesh e non sono destinati all'uso in produzione. Eseguendo questi script, imparerai a:

  • Separa le definizioni dei prodotti dai dati sottostanti.
  • Creare modelli di Data Catalog per descrivere le interfacce dei prodotti.
  • Applica il tagging alle interfacce dei prodotti con questi modelli.
  • Concedi le autorizzazioni ai consumatori del prodotto.

Per le interfacce del prodotto, l'implementazione del riferimento crea e utilizza i seguenti tipi di interfaccia:

  • Visualizzazioni autorizzate sulle tabelle BigQuery.
  • Stream di dati basati su argomenti Pub/Sub.

Per ulteriori dettagli, consulta il file README nel repository.

Funzioni in un data mesh

Affinché un data mesh funzioni correttamente, devi definire ruoli chiari per le persone che eseguono attività all'interno del data mesh. La proprietà è assegnata agli archetipi o funzioni del team. Queste funzioni contengono i percorsi degli utenti principali per le persone che lavorano nel data mesh. Per descrivere chiaramente i percorsi degli utenti, sono stati assegnati ruoli utente. Questi ruoli utente possono essere suddivisi e combinati in base alle circostanze di ciascuna azienda. Non è necessario mappare i ruoli direttamente ai dipendenti o ai team della tua organizzazione.

Un dominio dati è allineato a una business unit (BU) o a una funzione all'interno di un'azienda. Esempi comuni di domini aziendali possono essere il reparto mutui in una banca o i reparti clienti, di distribuzione, finanziari o delle risorse RU di un'azienda. A livello concettuale, in una rete di dati ci sono due funzioni correlate al dominio: i team data producer e data consumer team. È importante capire che è probabile che un singolo dominio di dati utilizzi entrambe le funzioni contemporaneamente. Un team che si occupa del dominio dati genera prodotti dati dai dati di sua proprietà. Il team consuma anche prodotti dati per insight aziendali e per produrre prodotti di dati derivati per l'utilizzo di altri domini.

Oltre alle funzioni basate sul dominio, un data mesh ha anche un insieme di funzioni eseguite dai team centralizzati all'interno dell'organizzazione. Questi team centrali consentono il funzionamento del data mesh fornendo supervisione, servizi e governance interdominio. Riducono il carico operativo per i domini di dati nella produzione e nell'utilizzo di prodotti dati e facilitano le relazioni interdominio necessarie per il funzionamento del data mesh.

Questo documento descrive solo le funzioni che hanno un ruolo specifico per il data mesh. Esistono molti altri ruoli richiesti in qualsiasi azienda, indipendentemente dall'architettura utilizzata per la piattaforma. Tuttavia, questi altri ruoli non rientrano nell'ambito di questo documento.

Le quattro funzioni principali in un data mesh sono le seguenti:

  • Team di produttori basati sul dominio di dati: crea e gestisci i prodotti dati per tutto il loro ciclo di vita. Questi team sono spesso indicati come produttori di dati.
  • Team dei consumatori basati sul dominio dei dati: scopri i prodotti dati e utilizzali in varie applicazioni di analisi. Questi team potrebbero utilizzare prodotti dati per creare nuovi prodotti dati. Questi team sono spesso indicati come consumatori di dati.
  • Team centrale per la governance dei dati: definisce e applica le norme di governance dei dati tra i produttori di dati, garantendo alta qualità e affidabilità dei dati per i consumatori. Questo team è spesso indicato come team per la governance dei dati.
  • Team della piattaforma di infrastruttura dati self-service centrale: fornisce una piattaforma dati self-service per i data producer. Questo team fornisce anche gli strumenti per l'individuazione centralizzata dei dati e l'osservabilità dei prodotti dati, utilizzati sia dai consumatori che dai produttori di dati. Questo team viene spesso indicato come il team della piattaforma dati.

Una funzione aggiuntiva facoltativa da considerare è quella di un centro di eccellenza (COE) per il data mesh. Lo scopo del COE è fornire la gestione della rete di dati. Il COE è inoltre il team arbitrale designato che risolve qualsiasi conflitto sollevato da una qualsiasi delle altre funzioni. Questa funzione è utile per collegare le altre quattro funzioni.

Team di produttori basato sul dominio dati

In genere, i prodotti dati sono basati su un repository fisico di dati (uno o più data warehouse, data lake o flussi). Un'organizzazione ha bisogno di ruoli tradizionali nella piattaforma dati per creare e gestire questi repository fisici. Tuttavia, questi ruoli tradizionali della piattaforma dati non sono in genere le persone che creano il prodotto dati.

Per creare prodotti dati da questi repository fisici, un'organizzazione ha bisogno di un mix di professionisti dei dati, come data engineer e data architect. La seguente tabella elenca tutti i ruoli utente specifici del dominio necessari nei team dei produttori di dati.


Ruolo

Responsabilità

Competenze richieste

Risultati desiderati

Proprietario del prodotto dati
  • Agisce come principale punto di contatto aziendale per il prodotto dati.
  • È responsabile delle definizioni, delle norme, delle decisioni aziendali e dell'applicazione delle regole aziendali per i dati esposti come prodotti.
  • Agisce da punto di contatto per domande commerciali. Di conseguenza, il proprietario rappresenta il dominio dei dati quando incontra i team dedicati ai consumatori di dati o i team centralizzati (piattaforma di infrastruttura dei dati e governance dei dati).

Analisi dei dati

Architettura dei dati

Gestione dei prodotti
  • Il prodotto dati genera valore per i consumatori. Offre una gestione solida del ciclo di vita di un prodotto dati, oltre a decidere quando ritirare un prodotto o rilasciare una nuova versione.
  • C'è coordinamento degli elementi di dati universali con altri domini di dati.

Lead tecnico del prodotto dati
  • Funge da principale punto di contatto tecnico per il prodotto.
  • È responsabile dell'implementazione e della pubblicazione delle interfacce dei prodotti.
  • Agisce da punto di contatto per questioni tecniche. Di conseguenza, il lead rappresenta il dominio dei dati quando si incontra con i team dedicati ai consumatori di dati o con i team centralizzati (governance dei dati e piattaforma dell'infrastruttura dei dati).
  • Collabora con il team di governance dei dati per definire e implementare gli standard del mesh di dati nell'organizzazione.
  • Collabora con il team dedicato alla piattaforma dati per sviluppare la piattaforma in tandem con le esigenze tecniche generate dalla produzione e dal consumo.

Data engineering

Architettura dei dati

Software Engineering
  • Il prodotto per i dati soddisfa i requisiti aziendali e aderisce agli standard tecnici del data mesh.
  • I team dedicati ai consumatori di dati utilizzano il prodotto dati e questo compare nei risultati generati dall'esperienza di rilevamento dei prodotti dati.
  • È possibile analizzare l'utilizzo del prodotto dati (ad esempio, il numero di query giornaliere).


Assistenza per i prodotti dati
  • Agisce da punto di contatto per l'assistenza alla produzione.
  • È responsabile del mantenimento dell'accordo sul livello del servizio (SLA) del prodotto.

Ingegneria del software

Site Reliability Engineering (SRE)
  • Il prodotto dati soddisfa lo SLA (accordo sul livello del servizio) dichiarato.
  • Vengono prese in considerazione e risolte le domande dei consumatori sull'utilizzo del prodotto dati.

Esperto in materia (SME) per il dominio dei dati
  • Rappresenta il dominio dei dati quando si incontrano le PMI di altri domini di dati per stabilire le definizioni e i confini degli elementi di dati comuni all'interno dell'organizzazione.
  • Aiuta i nuovi produttori di dati all'interno del dominio a definire gli ambiti dei prodotti.

Analisi dei dati

Architettura dei dati
  • Collabora con altre PMI di tutti i domini di dati per stabilire e mantenere una comprensione esaustiva dei dati nell'organizzazione e dei modelli dei dati che utilizza.
  • Agevola la creazione di prodotti dati interoperabili che corrispondono al modello dei dati complessivo dell'organizzazione.
  • Esistono standard chiari per la creazione e la gestione del ciclo di vita dei prodotti dati.
  • I prodotti dati del dominio dati forniscono valore aziendale.

Proprietario dei dati
  • È responsabile di un'area di contenuti.
  • È responsabile della qualità e dell'accuratezza dei dati.
  • Approva le richieste di accesso.
  • Contribuisce alla documentazione dei dati del prodotto.
  • Qualsiasi competenza, ma è necessario avere piena conoscenza della funzione aziendale.
  • Qualsiasi competenza, ma deve conoscere appieno il significato dei dati e le regole aziendali che li riguardano.
  • Qualsiasi competenza, ma deve essere in grado di determinare la migliore risoluzione possibile ai problemi di qualità dei dati.
  • I dati utilizzati dalle aree interfunzionali sono accurati.
  • Gli stakeholder comprendono i dati.
  • L'utilizzo dei dati è conforme alle norme di utilizzo.

Team consumatori basati sul dominio dei dati

In un data mesh, le persone che utilizzano un prodotto dati sono in genere utenti dati esterni al dominio del prodotto dati. I consumatori utilizzano un catalogo dati centrale per trovare prodotti dati pertinenti alle loro esigenze. Poiché è possibile che più di un prodotto dati possa soddisfare le loro esigenze, i consumatori di dati possono abbonarsi a più prodotti dati.

Se i consumatori di dati non riescono a trovare il prodotto dati richiesto per il loro caso d'uso, è loro responsabilità consultare direttamente il COE del data mesh. Durante la consulenza, i consumatori dei dati possono aumentare le loro esigenze di dati e chiedere consigli su come soddisfarle da uno o più domini.

Quando cercano un prodotto dati, i consumatori dei dati cercano dati che li aiutino a realizzare vari casi d'uso, come dashboard e report di analisi permanente, report sul rendimento individuali e altre metriche sulle prestazioni aziendali. In alternativa, i consumatori di dati potrebbero cercare prodotti da usare nei casi d'uso di intelligenza artificiale AIA) e machine learning (ML). Per ottenere questi vari casi d'uso, i consumatori dei dati richiedono una combinazione di utenti tipo di dati, che sono i seguenti:


Ruolo

Responsabilità

Competenze richieste

Risultati desiderati

Analista di dati

Cerca, identifica, valuta e sottoscrive prodotti di dati a dominio singolo o interdominio per creare le basi per il funzionamento dei framework di business intelligence.

Ingegneria dell'analisi

Analisi dell'attività
  • Fornisce set di dati puliti, curati e aggregati che gli specialisti della visualizzazione dati possono utilizzare.
  • Crea best practice su come utilizzare i prodotti dati.
  • Aggrega e seleziona set di dati interdominio per soddisfare le esigenze analitiche del loro dominio.

Sviluppatore di applicazioni

Sviluppa un framework dell'applicazione per il consumo di dati in uno o più prodotti dati, all'interno o all'esterno del dominio.

Sviluppo di applicazioni

Data engineering
  • Crea, gestisce e gestisce le applicazioni che consumano dati da uno o più prodotti dati.
  • Crea applicazioni di dati per il consumo da parte degli utenti finali.

Esperto della visualizzazione dei dati
  • Traduce il gergo di data engineering e analisi dei dati in informazioni comprensibili per gli stakeholder aziendali.
  • Definisce i processi per compilare i report aziendali dai prodotti dati.
  • Crea e monitora report che descrivono gli obiettivi commerciali strategici.
  • Collabora con gli ingegneri dell'organizzazione per progettare set di dati aggregati dai prodotti dati utilizzati.
  • Implementa soluzioni di reporting.
  • Traduce requisiti aziendali di alto livello in requisiti tecnici.

Analisi dei requisiti

Visualizzazione dei dati
  • Fornisce agli utenti finali set di dati e report validi e precisi.
  • I requisiti aziendali vengono soddisfatti attraverso le dashboard e i report sviluppati.

Data scientist
  • Cerca, identifica, valuta e sottoscrive prodotti dati per casi d'uso di data science.
  • Estrae prodotti dati e metadati da più domini di dati.
  • Addestra modelli predittivi e ne esegue il deployment per ottimizzare i processi aziendali di dominio.
  • Fornisce feedback su possibili tecniche di selezione e annotazione dei dati per più domini di dati.

Ingegneria ML

Ingegneria di analisi
  • Crea modelli predittivi e prescrittivi per ottimizzare i processi aziendali.
  • L'addestramento e il deployment del modello vengono eseguiti in modo tempestivo.

Team centrale per la governance dei dati

Il team per la governance dei dati consente a produttori e consumatori di dati di condividere, aggregare e calcolare in modo sicuro i dati in modo self-service, senza introdurre rischi di conformità per l'organizzazione.

Per soddisfare i requisiti di conformità dell'organizzazione, il team di governance dei dati è un mix di utenti tipo di professionisti dei dati, i quali sono i seguenti:


Ruolo

Responsabilità

Competenze richieste

Risultati desiderati

Esperto di governance dei dati
  • Fornisce supervisione e coordinamento da un'unica vista della conformità.
  • Consiglia norme sulla privacy a livello di mesh per la raccolta, la protezione e conservazione dei dati.
  • Garantisce che gli steward dei dati conoscano i criteri e possano accedervi.
  • Fornisce informazioni e consulenza sulle più recenti normative sulla privacy dei dati, se necessario.
  • Fornisce informazioni e consulenza in merito a domande di sicurezza, se necessario.
  • Esegue audit interni e condivide report regolari sui piani di rischio e controllo.

SME legale

SME per la sicurezza

SME per la privacy dei dati
  • Le normative sulla privacy nelle norme sono aggiornate.
  • I data producer vengono informati in modo tempestivo delle modifiche alle norme.
  • La dirigenza riceve report tempestivi e regolari sulla conformità alle norme per tutti i prodotti dati pubblicati.

Gestore dei dati (si trova all'interno di ciascun dominio)
  • Codifica i criteri creati dagli esperti di governance dei dati.
  • Definisce e aggiorna la tassonomia utilizzata da un'organizzazione per annotare i prodotti di dati, le risorse di dati e gli attributi di dati con metadati relativi al rilevamento e alla privacy.
  • Coordina i vari stakeholder all'interno e all'esterno del rispettivo dominio.
  • Garantisce che i prodotti dati nel proprio dominio soddisfino gli standard di metadati e le norme sulla privacy dell'organizzazione.
  • Offre indicazioni ai data governance engineer su come progettare e definire le priorità delle funzionalità delle piattaforme dati.

Architettura dei dati

Stewardship dei dati
  • I metadati obbligatori sono stati creati per tutti i prodotti dati nel dominio e i prodotti dati per il dominio sono descritti accuratamente.
  • Il team self-service dedicato alla piattaforma dei dati sta creando gli strumenti giusti per automatizzare le annotazioni dei metadati dei prodotti dati, la creazione e la verifica di criteri.

Data Governance Engineer
  • Sviluppa strumenti che generano automaticamente annotazioni sui dati e che possono essere utilizzati da tutti i domini di dati, quindi utilizza queste annotazioni per l'applicazione dei criteri.
  • Implementa il monitoraggio per verificare la coerenza di annotazioni e avvisi in caso di problemi.
  • Garantisce che i dipendenti dell'organizzazione siano informati sullo stato dei prodotti dati implementando avvisi, report e dashboard.

Ingegneria del software
  • Le annotazioni sulla governance dei dati vengono verificate automaticamente.
  • I prodotti dati sono conformi alle norme di governance dei dati.
  • Le violazioni dei prodotti di dati vengono rilevate in modo tempestivo.

Team centrale della piattaforma self-service per l'infrastruttura dati

Il team della piattaforma self-service per l'infrastruttura dati, o solo il team della piattaforma dati, è responsabile della creazione di un set di componenti dell'infrastruttura dati. I team nei domini dei dati distribuiti utilizzano questi componenti per creare i propri prodotti dati ed eseguirne il deployment. Il team della piattaforma dati promuove anche best practice e introduce strumenti e metodologie che aiutano a ridurre il carico cognitivo per i team distribuiti al momento di adottare nuove tecnologie.

L'infrastruttura della piattaforma deve integrarsi facilmente con gli strumenti operativi per l'osservabilità, la strumentazione e l'automazione della conformità a livello globale. In alternativa, l'infrastruttura dovrebbe facilitare questa integrazione per preparare team distribuiti per il successo.

Il team della piattaforma dati utilizza un modello di responsabilità condivisa con i team dei domini distribuiti e il team dell'infrastruttura sottostante. Il modello mostra quali responsabilità ci si aspetta dai consumatori della piattaforma e quali componenti della piattaforma sono supportati dal team della piattaforma dati.

Poiché la piattaforma dati è di per sé un prodotto interno, non supporta tutti i casi d'uso. il team della piattaforma dati rilascia continuamente nuovi servizi e funzionalità in base a una roadmap prioritaria,

Il team della piattaforma dati potrebbe avere un insieme standard di componenti in atto e in fase di sviluppo. Tuttavia, i team nel dominio dei dati potrebbero scegliere di utilizzare un insieme univoco di componenti diverso se le esigenze di un team non sono in linea con quelle fornite dalla piattaforma dati. Se i team del dominio dei dati scelgono un approccio diverso, devono assicurarsi che l'infrastruttura della piattaforma che creano e gestiscono sia conforme ai criteri e ai sistemi di protezione a livello di organizzazione per la sicurezza e la governance dei dati. Per l'infrastruttura della piattaforma dati sviluppata al di fuori del team della piattaforma dati centrale, il team della piattaforma dati potrebbe scegliere di co-investire o incorporare i propri ingegneri nei team di dominio. La scelta del team della piattaforma dati di co-investire o di incorporare ingegneri potrebbe dipendere dall'importanza strategica dell'infrastruttura della piattaforma del dominio dati per l'organizzazione. Rimanendo coinvolti nello sviluppo dell'infrastruttura da parte dei team dei domini dei dati, le organizzazioni possono fornire l'allineamento e le competenze tecniche necessarie per riformulare qualsiasi nuovo componente dell'infrastruttura della piattaforma in fase di sviluppo per il riutilizzo futuro.

Potresti dover limitare l'autonomia nelle prime fasi della creazione di un data mesh se il tuo obiettivo iniziale è ottenere l'approvazione degli stakeholder per lo scale up del data mesh. Tuttavia, limitare l'autonomia rischia di creare un collo di bottiglia per il team della piattaforma dati centrale. Questo collo di bottiglia può impedire la scalabilità del data mesh. Pertanto, tutte le decisioni di centralizzazione devono essere prese con attenzione. Per i produttori di dati, potrebbe essere preferibile prendere le loro scelte tecniche da un insieme limitato di opzioni disponibili anziché valutare e scegliere personalmente da un elenco illimitato di opzioni. Promuovere l'autonomia dei produttori di dati non equivale a creare un panorama tecnologico non esteso. L'obiettivo è favorire la conformità e l'adozione della piattaforma trovando il giusto equilibrio tra libertà di scelta e standardizzazione.

Infine, un buon team dedicato alla piattaforma dati è una fonte centrale di istruzione e best practice per il resto dell'azienda. Ecco alcune delle attività di maggior impatto che consigliamo ai team delle piattaforme dati centrali di eseguire:

  • Promuovere revisioni periodiche della progettazione dell'architettura per nuovi progetti funzionali e proporre metodi di sviluppo comuni per i team di sviluppo.
  • Condividere conoscenze ed esperienze e definire collettivamente best practice e linee guida sull'architettura.
  • Garantire agli ingegneri di disporre degli strumenti giusti per convalidare e verificare la presenza di insidie comuni, come problemi relativi al codice, bug e riduzioni delle prestazioni.
  • Organizzazione di hackathon interni in modo che i team di sviluppo possano far emergere i requisiti per le esigenze relative agli strumenti interni.

I ruoli e le responsabilità di esempio per il team della piattaforma dati centrale potrebbero includere quanto segue:

Role Responsabilità
Competenze richieste
Risultati desiderati

Proprietario del prodotto della piattaforma dati
  • Crea un ecosistema di soluzioni e infrastruttura dati per consentire a team distribuiti di creare prodotti dati. Riduce l'ostacolo tecnico all'ingresso, garantisce l'integrazione della governance e riduce al minimo il debito tecnico collettivo per l'infrastruttura dei dati.
  • Si interagisce con dirigenza, proprietari di domini dati, team di governance dei dati e proprietari di piattaforme tecnologiche per impostare la strategia e la roadmap per la piattaforma dati.

Strategia e operazioni sui dati

Gestione dei prodotti

Gestione degli stakeholder
  • Crea un ecosistema di prodotti dati di successo.
  • Esistono un numero elevato di prodotti dati in produzione.
  • Si riduce il tempo minimo necessario per il prodotto e i tempi di produzione per le release dei prodotti dati.
  • Viene messo a punto un portafoglio di infrastruttura e componenti generalizzati che risponde alle esigenze più comuni di produttori e consumatori di dati.
  • C'è un alto punteggio di soddisfazione da parte dei produttori e dei consumatori di dati.

Data Platform Engineer
  • Crea soluzioni e infrastrutture dati riutilizzabili e self-service per l'importazione, l'archiviazione, l'elaborazione e il consumo dei dati tramite modelli, progetti di architettura di cui è possibile eseguire il deployment, guide per gli sviluppatori e altra documentazione. Inoltre, crea modelli Terraform, pipeline di dati, modelli di container e strumenti di orchestrazione.
  • Sviluppa e gestisce servizi di dati e framework centralizzati per standardizzare i processi per problemi interfunzionali come condivisione dei dati, orchestrazione delle pipeline, logging e monitoraggio, governance dei dati, integrazione continua e deployment continuo (CI/CD) con guardrail integrati, reporting di sicurezza e conformità e reporting FinOps.

Data engineering

Software Engineering
  • Esistono componenti e soluzioni di infrastruttura standardizzati e riutilizzabili che consentono ai produttori di dati di eseguire l'importazione, l'archiviazione, l'elaborazione, la selezione e la condivisione dei dati, oltre alla documentazione necessaria.
  • Le release di componenti, soluzioni e documentazione per l'utente finale sono in linea con la roadmap.
  • Gli utenti riferiscono un alto livello di soddisfazione del cliente.
  • Nel mesh di dati sono presenti solidi servizi condivisi per tutte le funzioni.
  • I servizi condivisi prevedono un tempo di attività elevato.
  • Il tempo di risposta dell'assistenza è breve.

Ingegnere di piattaforma e di sicurezza (rappresentante dei team IT centrali come networking e sicurezza, membro del team della piattaforma dati)
  • Garantisce che le astrazioni delle piattaforme dati siano allineate ai framework e alle decisioni tecnologici a livello aziendale.
  • Supporta le attività di ingegneria creando nel team principale soluzioni e servizi tecnologici necessari per la distribuzione della piattaforma dati.

Ingegneria dell'infrastruttura

Ingegneria del software
  • I componenti dell'infrastruttura della piattaforma sono sviluppati per la piattaforma dati.
  • Le release di componenti, soluzioni e documentazione per l'utente finale sono in linea con la roadmap.
  • I tecnici delle piattaforme dati centrali riferiscono un alto livello di soddisfazione del cliente.
  • L'integrità della piattaforma dell'infrastruttura migliora per i componenti utilizzati dalla piattaforma dati (ad esempio il logging).
  • I componenti tecnologici sottostanti hanno un tempo di attività elevato.
  • Quando i tecnici delle piattaforme dati riscontrano problemi, i tempi di risposta dell'assistenza sono brevi.

Enterprise Architect
  • Allinea il data mesh e l'architettura delle piattaforme dati alla strategia per i dati e la tecnologia di livello aziendale.
  • Fornisce consulenza e autorità di progettazione e garanzia per le architetture della piattaforma dati e dei prodotti dati, al fine di garantire l'allineamento con la strategia e le best practice a livello aziendale.

Architettura dei dati

iterazione della soluzione e risoluzione dei problemi

Creazione del consenso
  • Viene creato un ecosistema di successo che include un numero elevato di prodotti dati per i quali viene ridotto il tempo sia per la creazione di prodotti minimi funzionanti che per il rilascio in produzione.
  • Sono stati definiti standard di architettura per i percorsi critici dei dati, ad esempio standard comuni per la gestione dei metadati e l'architettura di condivisione dei dati.

Considerazioni aggiuntive per un data mesh

Una piattaforma di dati di analisi offre architetture diverse, ognuna con prerequisiti diversi. Per abilitare ogni architettura di data mesh, ti consigliamo che la tua organizzazione segua le best practice descritte in questa sezione.

Acquisisci finanziamenti della piattaforma

Come spiegato nel post del blog, "If you you want to transform start with finance", la piattaforma non è mai finita: funziona sempre secondo una roadmap prioritaria. Di conseguenza, la piattaforma deve essere finanziata come un prodotto, non come un progetto con un endpoint fisso.

Il costo è a carico del primo utente del data mesh. Di solito, il costo è condiviso tra l'attività che costituisce il primo dominio dati ad avviare il data mesh e il team tecnologico centrale, che in genere ospita il team della piattaforma dati centrale.

Per convincere i team finanziari ad approvare il finanziamento per la piattaforma centrale, ti consigliamo di creare un business case per il valore della piattaforma centralizzata realizzato nel tempo. Questo valore deriva dal reimplementazione degli stessi componenti nei singoli team di distribuzione.

Definire la piattaforma minima utilizzabile per il data mesh

Per aiutarti a definire la piattaforma minima utilizzabile per il data mesh, ti consigliamo di eseguire un progetto pilota e di eseguire l'iterazione con uno o più business case. Per il tuo pilota, trova i casi d'uso necessari e dove c'è un consumatore pronto ad adottare il prodotto dati risultante. I casi d'uso dovrebbero già disporre di fondi per sviluppare i prodotti dati, ma dovrebbe essere necessario il contributo dei team tecnici.

Assicurati che il team che implementa il progetto pilota comprenda il modello operativo del data mesh come segue:

  • L'azienda (ossia il team del produttore di dati) è proprietaria del backlog, dell'assistenza e della manutenzione.
  • Il team centrale definisce i pattern self-service e aiuta l'azienda a creare il prodotto dati, ma lo passa all'azienda affinché venga eseguito e posseduto quando è completo.
  • L'obiettivo principale è dimostrare il modello operativo aziendale (prodotti dei domini, uso dei domini). L'obiettivo secondario è dimostrare il modello operativo tecnico (pattern self-service sviluppati dal team centrale).
  • Poiché le risorse dei team della piattaforma sono limitate, utilizza il modello team di trunk e filiali per raccogliere conoscenze, ma consenti comunque lo sviluppo di servizi e prodotti della piattaforma specializzati.

Ti consigliamo inoltre di procedere come segue:

  • Pianifica le roadmap anziché lasciare che i servizi e le funzionalità si evolvano in modo organico.
  • Definire funzionalità di piattaforma minime attuabili che comprendono importazione, archiviazione, elaborazione, analisi e ML.
  • Integra la governance dei dati in ogni fase, non come un flusso di lavoro separato.
  • Implementa le funzionalità minime per governance, piattaforma, flusso di valore e gestione dei cambiamenti. Le funzionalità minime sono quelle che soddisfano l'80% dei casi aziendali.

Pianifica la coesistenza del data mesh con una piattaforma dati esistente

Molte organizzazioni che desiderano implementare un data mesh probabilmente dispongono già di una piattaforma dati esistente, ad esempio un data lake, un data warehouse o una combinazione di entrambi. Prima di implementare un data mesh, queste organizzazioni devono fare un piano su come la loro piattaforma dati esistente può evolversi con la crescita del data mesh.

Queste organizzazioni devono prendere in considerazione fattori quali:

  • Le risorse di dati più efficaci nel data mesh.
  • Gli asset che devono rimanere all'interno della piattaforma dati esistente.
  • Indica se gli asset devono essere spostati o se possono essere mantenuti sulla piattaforma esistente e continuare a partecipare al data mesh.

Passaggi successivi