I responsabili fissano le politiche, gli architetti le fanno rispettare

🌐 Disponibile anche in 28 lingue

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Tradotto con l'IA. Non ancora rivisto dalla comunità. Leggi in inglese

Capitolo 5 di Data Architect, Parte 1: Diventare un architetto dei dati. Precedente: Capire i dati aziendali.

Di’ “governance dei dati” e le persone immaginano riunioni: comitati, politiche, un documento che nessuno legge. Io faccio ogni volta una domanda diversa: dove viene applicata la politica?

Se la politica dice che solo la Finanza può cambiare la ragione sociale del cliente, cosa impedisce a chiunque altro di farlo? Se dice che le squadre vedono l’indirizzo di un Destinatario solo per le proprie tappe, solo quel giorno, cosa lo rende vero? Se dice di conservare qualcosa per sette anni, cosa lo rimuove dopo sette? Una politica senza un punto di applicazione è per lo più un desiderio. La mia posizione è semplice: i responsabili fissano le politiche; gli architetti le fanno rispettare. Il responsabile dei dati decide. Il sistema progettato dall’architetto lo rende meccanicamente vero.

E non aspettarti di finire. La governance non è mai finita. Va avanti a ondate, tenendo fuori il peggio dei dati cattivi. È semplice quando Salesforce è da sola, e più difficile, e più necessaria, quando Salesforce è un nodo del panorama che abbiamo disegnato nel capitolo 4. Ecco perché quel capitolo è venuto prima: il panorama ti dice fin dove deve arrivare la governance.

Immagine generata con l’IA.

Le posizioni di questo capitolo

• Gestisci il programma nel modo in cui funziona l’azienda: centralizzato, federato o ibrido; l’architetto deve sapere chi approva una politica.
• Il titolare del record non è il responsabile dei dati. Il campo Titolare determina assegnazione e accesso; la responsabilità dei dati resta al business.
• Creazione aperta o bloccata dipende dalla governance intorno ai dati. Aperta va bene per la maggior parte delle org piccole e medie; bloccala quando gli account sono gestiti come dati master in un ERP o sincronizzati con esso; la via di mezzo è un tipo di record provvisorio con una conversione controllata verso quello governato.
• Se l’ERP gestisce un campo come dato master, non lo stai cambiando, stai chiedendo di cambiarlo. Il golden record è ibrido: i campi master dell’ERP entrano, i campi propri di Salesforce non tornano mai indietro, e i flussi bidirezionali hanno bisogno di una regola per le collisioni.
• Classifica i campi sensibili, non tutti i campi. Documenta in modo ampio; classifica in modo deliberato; tieni sia i metadati di business sia quelli tecnici.
• Insegna le normative. Molti architetti non hanno mai sentito parlare delle leggi fuori dalla propria regione, e queste leggi danno forma alla progettazione dei sistemi.
• Usa il modello di consenso standard ovunque puoi, invece di ricostruirlo.
• Per il diritto all’oblio, controlla prima dove vanno i dati personali. La cancellazione è rara e difficile; progetta in modo che i dati personali finiscano in pochi posti, poi stana ogni copia: cronologia dei campi, archivi, le copie per le analisi, indici di ricerca e conversazioni degli agenti, prima che scada il tempo.
• Shield è la risposta per i requisiti normativi chiave come la crittografia dei dati a riposo, con trade-off per cui si progetta.
• Field Audit Trail quando c’è regolamentazione. La cronologia standard dei campi è l’impostazione predefinita.
• Configura Event Monitoring prima che ti serva, e invia gli eventi in streaming a un repository come Splunk. Non vuoi incontrare un problema e scoprire solo allora che non li stavi raccogliendo.

Il ciclo di vita governato dei dati

Click to enlarge

Sette domande lungo la vita dei dati. Gli strumenti sostengono la politica; non la definiscono.

Il percorso di questo capitolo

Sei moduli, ognuno dei quali si regge da solo.

1. La governance si progetta dentro la org. Responsabili, data steward e custodi; centralizzato, federato o ibrido; titolare del record e responsabile dei dati; trasformare ogni politica in un punto di applicazione.
2. Tenere fuori i dati cattivi. “Abbastanza buono” come definizione di business; creazione aperta o bloccata, il record provvisorio e un tipo di record per ogni flusso; il golden record ibrido e i bidirezionali; una decisione sulla qualità a ogni confine dei dati.
3. Conosci i tuoi dati: dizionario, lineage e classificazione. Metadati di business e tecnici; cosa significano i dati, da dove vengono, come vanno trattati, e perché la classificazione senza applicazione è decorazione.
4. Le leggi sulla privacy danno forma al progetto. Le leggi da riconoscere, cosa hanno in comune (diritti, trasferimenti, notifica delle violazioni, responsabilizzazione), e le domande che durano più di loro; anonimizzato o pseudonimizzato; la conformità non è un prodotto.
5. Il consenso e il diritto all’oblio. Il consenso come dato, il modello di consenso standard, il tempo che corre su ogni richiesta, e progettare la cancellazione prima che arrivi la prima.
6. Proteggere, conservare e dimostrare. I trade-off della crittografia, le sandbox, la conservazione, la cronologia dei campi e Field Audit Trail, ed Event Monitoring configurato in anticipo.

Quando hai finito, mettiti alla prova con la guida allo studio del capitolo: una checklist per l’esame, le abitudini che vanno oltre, le parole da conoscere e qualche domanda.

Cosa decide qui un architetto

• Chi è responsabile di ogni dominio di dati importante, e cosa fa rispettare la politica di ogni responsabile.
• Quali dati cattivi vengono tenuti fuori, e quali vengono intercettati, messi in quarantena e corretti più tardi.
• Quali campi sono sensibili, e cosa cambia quella classificazione.
• Dove vanno i dati personali, per cosa possono essere usati, e come vengono rimossi da ogni copia.
• Per quanto tempo si conservano i dati e il loro storico, e quali prove esistono per dimostrare cosa è successo.

Questo capitolo è una guida di architettura, non una consulenza legale. Sono i team legali e di conformità a decidere quali leggi si applicano e cosa richiedono; l’architetto trasforma quei requisiti in progetto.

Oltre l’esame: la governance ha un nuovo consumatore, l’agente. La classificazione decide cosa può recuperare, il consenso decide per cosa può usare i dati, e lineage e audit devono arrivare fino a ciò che ha detto e fatto. Ogni modulo si chiude con ciò che l’IA cambia per la sua parte del ciclo di vita.

Per approfondire

• Guida di Salesforce, Data Classification Metadata Fields (opens in a new tab) (in inglese), consultato il 2026-10-14.
• Guida di Salesforce, Understand the Salesforce Consent Data Model (opens in a new tab) (in inglese), consultato il 2026-10-14.
• Regolamento (UE) 2016/679 (GDPR) (opens in a new tab), EUR-Lex, consultato il 2026-10-14.

Successivo: Dati master e identità