La governance si progetta dentro la org

🌐 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)

Immagine generata con l'IA

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

Modulo 1 di 6 del capitolo Qualità e governance dei dati, capitolo 5 del corso Data Architect. Ogni modulo si regge da solo. Successivo: Tenere fuori i dati cattivi

La domanda a cui risponde questo modulo: Cosa significa la governance dei dati per un architetto, e chi fa cosa?

Quando le persone sentono governance dei dati, pensano alle riunioni: comitati, politiche, standard, un documento che spiega chi dovrebbe fare cosa con i dati. Tutto questo può far parte di un programma di governance. Da architetto mi interessa un’altra domanda: dove viene applicata la politica?

Se la politica dice che solo la Finanza può modificare un campo, cosa lo fa rispettare? Se dice che l’ERP possiede il record legale del cliente, cosa impedisce a qualcuno in Salesforce di modificarlo? Se dice che le squadre vedono l’indirizzo di un Destinatario solo per le proprie tappe, solo quel giorno, cosa lo rende davvero vero? Se dice di conservare qualcosa per sette anni, cosa lo archivia o lo rimuove dopo sette? Una politica senza un punto di applicazione è per lo più un desiderio. La governance diventa architettura quando quelle decisioni sono costruite dentro il sistema.

La governance non è mai finita

Togliamoci subito il pensiero: la governance non si finisce. L’ho vista andare avanti a ondate. Un’azienda dedica vera attenzione alla qualità dei dati, e le cose migliorano. L’attenzione si sposta altrove, e la qualità scivola. Entra in funzione una nuova integrazione, una business unit cambia il suo processo, qualcuno importa un file, l’azienda ne acquisisce un’altra, un agente inizia a scrivere record, e il problema cambia di nuovo. L’obiettivo non è un mitico stato in cui ogni record è perfetto per sempre. È mantenere i dati abbastanza affidabili per il business e tenere fuori il peggio dei dati cattivi. È un lavoro continuo.

Quando Salesforce è quasi da sola, governance significa ripulire i dati in un solo posto. Quando è un nodo del panorama del capitolo 4, diventa più difficile, e più necessaria. Ora il cliente vive in Salesforce, nell’ERP, nel data warehouse, nei sistemi dei partner, in Data 360. Chi lo possiede? Chi può modificarlo? Quale copia è autorevole, quali attributi possono spostarsi, per quanto tempo vengono conservati, e chi risponde quando sono sbagliati? Non sono domande di configurazione. Sono domande di governance che diventano configurazione.

Il titolare del record non è il responsabile dei dati

Comincia dalla parola owner, perché Salesforce la rende ambigua. Apri un account e vedi un Titolare: un commerciale, diciamo. Il commerciale possiede i dati del cliente? Non necessariamente. Su Salesforce, un record di un oggetto con titolare appartiene a un utente o a una coda; il titolare ha accesso completo, e determina assegnazione e condivisione attraverso la gerarchia dei ruoli e le regole di condivisione (Sharing and Record Access Features (opens in a new tab)). Questa è la titolarità del record: un meccanismo della piattaforma.

Il responsabile dei dati (data owner) è un’altra cosa: la persona o la funzione che risponde dei dati come patrimonio dell’azienda. La Finanza può essere responsabile delle informazioni legali del cliente, le Operazioni dello stato delle consegne, le Risorse umane dei dati dei dipendenti. Salesforce ti dà perfino un posto dove registrarlo: il campo di classificazione Data Owner su ogni campo (Data Classification Metadata Fields (opens in a new tab)).

In Steve Trucking, l’account di un Partner retail può avere come titolare il dirigente commerciale che gestisce quel partner. Ma l’identità legale del partner è governata dalla Finanza e gestita come dato master nell’ERP finanziario. Vendite, assistenza, operazioni e il portale dei partner hanno tutti bisogno dell’account; niente di questo significa che il dirigente commerciale debba modificare l’identità legale del partner una volta che la Finanza l’ha stabilita. Ho visto team guardare il campo Titolare e pensare di aver risolto la responsabilità dei dati. Non l’hanno fatto. L’assegnazione di un record non è la responsabilità di business.

Responsabile, data steward, custode

Tre ruoli di governance, tre lavori diversi.

Il responsabile dei dati fissa la politica. Risponde a cosa significano i dati, chi può crearli e modificarli, quanto devono essere accurati, per quanto tempo vengono conservati, chi può vederli, quale sistema è autorevole, e cosa succede quando sono sbagliati. L’architetto non dovrebbe inventare quelle risposte. È una delle mie posizioni più ferme: i responsabili fissano le politiche; gli architetti le fanno rispettare. Se la Finanza dice che la ragione sociale può cambiare solo attraverso il processo dell’ERP una volta che il cliente è attivo, è una decisione di governance. Renderla meccanicamente vera è il mio lavoro.

Il data steward (curatore dei dati) la fa funzionare. Lo steward è vicino alla salute quotidiana dei dati: osserva i segnali di qualità, indaga sui duplicati, risolve le eccezioni, coordina le correzioni, mantiene le definizioni, individua il processo che continua a produrre dati cattivi. Allo steward spettano altri due compiti. Quando due team non sono d’accordo su cosa significa un campo, su chi ne è responsabile o su chi può vederlo, lo steward porta la controversia al responsabile e segue la decisione fino in fondo. E lo steward costruisce la data literacy (alfabetizzazione sui dati): aiuta le persone che inseriscono e usano i dati a capire cosa significano e perché esistono le regole. Uno steward ha bisogno di più di un nome in un organigramma. Ha bisogno di tempo, visibilità, un processo e l’autorità per far correggere i problemi. Altrimenti “data steward” diventa l’ottava responsabilità di qualcuno, guardata una volta a trimestre.

Il custode gestisce il sistema. Amministratori, team di piattaforma, team di sicurezza: chiunque gestisca la tecnologia che memorizza ed elabora i dati. Il responsabile dice che solo questi ruoli possono vederli; il custode gestisce i controlli che lo rendono vero. I nomi contano meno del rendere chiara ogni responsabilità, e in un’organizzazione piccola una persona può avere due cappelli.

Come funziona il programma

I programmi di governance tendono ad assumere tre forme. Centralizzato: un solo team scrive le politiche e gli standard per ogni dominio. È coerente, ma può diventare un collo di bottiglia, lontano dalle persone che fanno il lavoro. Federato (decentralizzato): ogni dominio, come finanza, vendite o operazioni, governa i propri dati entro poche regole condivise. È vicino al lavoro, ma le definizioni si allontanano tra un dominio e l’altro. Ibrido: un piccolo team centrale è responsabile degli standard e delle definizioni condivise, e i responsabili e gli steward dei domini gestiscono i propri dati. La maggior parte delle aziende che ho visto finisce da qualche parte nell’ibrido. Per l’architetto, la forma risponde a una domanda pratica: chi approva una politica prima che io la applichi, e dove vivono le definizioni condivise?

Da sapere per l’esame. Conosci i tre modi di gestire un programma di governance, centralizzato, federato (decentralizzato) e ibrido, e cosa significa ciascuno per chi stabilisce le politiche e dove vivono le definizioni condivise.

Fai guadagnare alla RACI il suo posto

Una RACI (chi è Responsabile dell’esecuzione, chi ne risponde, chi viene Consultato e chi Informato) aiuta, ma non un foglio di calcolo gigante fatto perché la governance “ne richiede uno”. Voglio che risponda a domande di architettura, a partire dalle tre del capitolo 4 (Le quattro domande dietro le categorie): dove vengono creati i dati, dove vengono modificati e dove vengono referenziati? Spesso sono sistemi diversi. Prendi un prodotto: l’ERP lo crea, Salesforce lo referenzia, il portale lo mostra, il data warehouse lo analizza. Ora il business cambia cosa significa “prodotto attivo”. Dove parte la modifica, chi la approva, come si propaga, e quali copie sono di sola lettura? Se non sai rispondere, non hai ancora la governance. Hai delle copie. Una buona RACI fa emergere proprio quell’ambiguità.

La governance deve diventare meccanica

Il business dice che solo la Finanza può cambiare la ragione sociale del cliente. Non voglio che la risposta dell’architettura sia “lo copriremo con la formazione”. La formazione aiuta; non è applicazione. Forse è l’accesso a livello di campo, una regola di convalida, un campo scritto solo dall’integrazione, o un processo controllato invece delle modifiche dirette. Il meccanismo dipende dal requisito, ma ce ne deve essere uno:

Politica di governance	Chi decide	Possibile punto di applicazione
L’ERP possiede l’identità legale del cliente	Finanza	Campi scritti solo dall’integrazione, autorizzazioni, convalida
Solo chi ne ha bisogno vede i dati personali	Privacy, sicurezza	Condivisione, autorizzazioni, accesso ai campi
Gli identificatori dei clienti sono unici	Responsabile di business	ID esterno univoco, regole duplicati
I record governati non si creano a mano	Responsabile dei dati	Autorizzazioni, automazione, integrazione
I dati sensibili hanno un periodo di conservazione stabilito	Privacy, ufficio legale	Un processo di conservazione o di cancellazione
Le modifiche importanti devono essere dimostrabili	Conformità	Cronologia dei campi, audit trail
L’origine dei dati resta identificabile	Responsabile dei dati	Un campo di origine, metadati di lineage

Dico possibile punto di applicazione di proposito. Non è una tabella per scegliere funzionalità. È l’ordine del ragionamento: qual è la politica, chi ne è responsabile, e cosa nell’architettura la rende vera?

Click to enlarge

I responsabili fissano le politiche; gli architetti le fanno rispettare.

Non affidarti al buon comportamento

“Non cambiare mai l’ID cliente dell’ERP.” Lo sanno tutti, finché qualcuno non lo fa: per sbaglio, con un caricamento di dati, con un’automazione, con un’integrazione, con un agente. Se cambiarlo danneggerebbe i dati aziendali, “per favore non farlo” non è il controllo. Costruisci il controllo. Fidati, ma verifica. Persone, integrazioni, automazioni e IA sbagliano tutte, quindi l’architettura dovrebbe dare per scontato che prima o poi qualcosa proverà a fare ciò che la politica vieta. Cosa succede allora?

La governance attraversa i confini tra sistemi

Torna al panorama. L’ERP possiede il cliente; Salesforce, il data warehouse e una piattaforma di dati dei clienti (CDP) ne hanno copie; un partner ne riceve una parte. A quale sistema si applica la politica? A tutti. Salesforce può bloccare correttamente una modifica della ragione sociale mentre un’integrazione lascia che un sistema a valle la sovrascriva. Salesforce può eliminare dati personali che il data warehouse conserva ancora. Un campo classificato come sensibile in Salesforce può finire in un campo di testo non classificato altrove. La governance non può fermarsi al bordo della org, perché i dati non si fermano. Ecco perché il capitolo 4 è venuto prima: il panorama ti dice fin dove deve arrivare la governance.

Governa quanto basta, non tutto

Il fallimento opposto è altrettanto reale. Scopriamo che la governance conta, quindi blocchiamo tutto: nessuno può creare, ogni modifica richiede un’approvazione. I dati sono governati, e nessuno riesce a fare il proprio lavoro. Governance significa il controllo appropriato per i dati: stretto per alcuni, leggero per altri. Alcuni record si possono creare liberamente, altri richiedono un’approvazione; alcuni campi li può modificare quasi chiunque, altri solo l’integrazione. Il prossimo modulo affronta proprio questo in modo pratico.

E siccome la governance non è mai finita, l’applicazione ha bisogno di un riscontro. I duplicati aumentano? I campi obbligatori si riempiono di spazzatura? Le integrazioni falliscono, gli utenti trovano scorciatoie, le eccezioni crescono, gli steward passano tutta la giornata su un solo problema? Quei segnali ti dicono se il progetto funziona, e a volte che il controllo, o la politica, deve cambiare.

Oltre l’esame: cosa cambia l’IA. La governance ha un nuovo consumatore: l’agente. Il responsabile dei dati decide ancora cosa si può usare e per cosa; l’architetto lo rende ancora applicabile. Cambiano velocità e scala. Un agente legge, combina e agisce sui dati governati molto più in fretta di una persona, quindi una politica che esiste solo in un documento protegge ancora meno.

Cosa decide qui un architetto

• Chi risponde di ogni dominio di dati importante, e in cosa questo differisce dalla titolarità del record.
• Chi fa da data steward e chi gestisce i dati come custode.
• Dove i dati importanti vengono creati, modificati, referenziati e gestiti come dati master nel panorama.
• Quale punto di applicazione rende meccanicamente vera ogni politica importante.
• Come l’architettura mostra se la governance funziona, o comincia a scivolare.

Quando sento un requisito di governance, lo traduco. “L’ERP possiede questo.” “Solo queste persone possono vedere questo.” “Dobbiamo dimostrare chi ha cambiato questo.” “Conserva questo per sette anni.” Ogni volta: mostrami il punto di applicazione. L’architetto non decide la politica. Progettiamo il sistema che la fa rispettare. È lì che la governance smette di essere un documento e diventa architettura.

Per approfondire

• Guida di Salesforce, Sharing and Record Access Features (opens in a new tab) (in inglese), consultato il 2026-10-14.
• Guida di Salesforce, Data Classification Metadata Fields (opens in a new tab) (in inglese), consultato il 2026-10-14.