A governança é projetada dentro da org

🌐 Também em 28 idiomas

English · Español · 日本語 · Français · Deutsch · Italiano · 한국어 · 简体中文 · 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)

Imagem gerada com IA

Traduzido por IA. Ainda não revisado pela comunidade. Ler em inglês

Módulo 1 de 6 do capítulo Qualidade e governança de dados, capítulo 5 do curso Data Architect. Cada módulo se sustenta sozinho. Próximo: Mantendo dados ruins do lado de fora

A pergunta que este módulo responde: O que a governança de dados significa para um arquiteto, e quem faz o quê?

Quando as pessoas ouvem governança de dados, pensam em reuniões: comitês, políticas, padrões, um documento explicando quem deve fazer o que com os dados. Tudo isso pode fazer parte de um programa de governança. Como arquiteto, me interessa outra pergunta: onde a política é aplicada?

Se a política diz que só o Financeiro pode alterar um campo, o que aplica isso? Se diz que o ERP é dono do registro legal do cliente, o que impede alguém no Salesforce de alterá-lo? Se diz que as equipes veem o endereço de um Destinatário só nas suas próprias paradas, só no dia, o que realmente torna isso verdade? Se diz guarde isto por sete anos, o que o arquiva ou remove depois de sete? Uma política sem ponto de aplicação é, em boa parte, um desejo. A governança vira arquitetura quando essas decisões são construídas dentro do sistema.

A governança nunca termina

Deixe-me tirar isto do caminho logo: você não termina a governança. Já a vi ir e vir. Uma empresa dá atenção real à qualidade dos dados, e as coisas melhoram. A atenção vai para outro lugar, e a qualidade escorrega. Uma nova integração entra no ar, uma unidade de negócio muda seu processo, alguém importa um arquivo, a empresa adquire outra, um agente começa a gravar registros, e o problema muda de novo. O objetivo não é um estado mítico em que todo registro é perfeito para sempre. É manter os dados confiáveis o bastante para o negócio e manter do lado de fora o pior dos dados ruins. É trabalho contínuo.

Quando o Salesforce está praticamente sozinho, governança significa limpar dados num só lugar. Quando ele é um nó do panorama do capítulo 4, fica mais difícil, e mais necessária. Agora o cliente vive no Salesforce, no ERP, no data warehouse, nos sistemas dos parceiros, no Data 360. Quem é o dono? Quem pode alterá-lo? Qual cópia tem autoridade, quais atributos podem se mover, por quanto tempo são guardados, e quem responde quando estão errados? Essas não são perguntas de configuração. São perguntas de governança que viram configuração.

O proprietário do registro não é o proprietário dos dados

Comece pela palavra proprietário, porque o Salesforce a torna confusa. Abra uma conta e você vê um Proprietário: um vendedor, digamos. O vendedor é dono dos dados do cliente? Não necessariamente. No Salesforce, um registro de um objeto com proprietário pertence a um usuário ou a uma fila; o proprietário recebe acesso total, e determina a atribuição e o compartilhamento pela hierarquia de papéis e pelas regras de compartilhamento (Sharing and Record Access Features (opens in a new tab), em inglês). Isso é propriedade do registro: um mecanismo da plataforma.

O proprietário dos dados é outra coisa: a pessoa ou a função responsável pelos dados como um ativo do negócio. O Financeiro pode ser dono das informações legais do cliente, Operações do status das entregas, o RH dos dados dos funcionários. O Salesforce até lhe dá um lugar para registrar isso: o campo de classificação Data Owner em cada campo (Data Classification Metadata Fields (opens in a new tab), em inglês).

Na Steve Trucking, a conta de um Parceiro varejista pode ter como proprietário o executivo de vendas que cuida daquele parceiro. Mas a identidade legal do parceiro é governada pelo Financeiro e mestre no ERP financeiro. Vendas, atendimento, operações e o portal do parceiro precisam todos da conta; nada disso significa que o executivo de vendas deva alterar a identidade legal do parceiro depois que o Financeiro a estabeleceu. Já vi equipes olharem para o campo Proprietário e acharem que resolveram a propriedade dos dados. Não resolveram. Atribuição de registro não é responsabilidade de negócio.

Proprietário, data steward, custodiante

Três papéis de governança, três trabalhos diferentes.

O proprietário dos dados define a política. Ele responde o que os dados significam, quem pode criá-los e alterá-los, quão precisos precisam ser, por quanto tempo são guardados, quem pode vê-los, qual sistema tem autoridade, e o que acontece quando estão errados. O arquiteto não deve inventar essas respostas. Essa é uma das minhas posições mais firmes: os donos definem a política; os arquitetos a aplicam. Se o Financeiro diz que a razão social só pode mudar pelo processo do ERP depois que o cliente está ativo, essa é uma decisão de governança. Torná-la mecanicamente verdadeira é o meu trabalho.

O data steward (curador dos dados) mantém tudo funcionando. O steward está perto da saúde diária dos dados: acompanha sinais de qualidade, investiga duplicatas, resolve exceções, coordena correções, mantém definições, identifica o processo que não para de produzir dados ruins. Mais duas tarefas ficam com o steward. Quando duas equipes discordam sobre o que um campo significa, quem é dono dele ou quem pode vê-lo, o steward leva a disputa ao proprietário e acompanha a decisão até o fim. E o steward constrói a alfabetização em dados (data literacy): ajuda as pessoas que inserem e usam os dados a entender o que eles significam e por que as regras existem. Um steward precisa de mais do que um nome num organograma. Precisa de tempo, visibilidade, um processo e autoridade para fazer os problemas serem corrigidos. Senão “data steward” vira a oitava responsabilidade de alguém, olhada uma vez por trimestre.

O custodiante opera o sistema. Administradores, equipes de plataforma, equipes de segurança: quem opera a tecnologia que armazena e processa os dados. O proprietário diz que só estes papéis podem vê-los; o custodiante opera os controles que fazem isso acontecer. Os nomes importam menos do que deixar clara cada responsabilidade, e numa organização pequena uma pessoa pode acumular dois chapéus.

Como o programa funciona

Os programas de governança costumam ter três formatos. Centralizado: uma equipe escreve as políticas e os padrões para todos os domínios. É consistente, e pode virar um gargalo, longe das pessoas que fazem o trabalho. Federado (descentralizado): cada domínio, como finanças, vendas ou operações, governa os próprios dados dentro de algumas regras compartilhadas. Fica perto do trabalho, e as definições se distanciam entre os domínios. Híbrido: uma pequena equipe central é dona dos padrões e das definições compartilhadas, e os proprietários e stewards de cada domínio cuidam dos próprios dados. A maioria das empresas que já vi acaba em algum ponto do híbrido. Para o arquiteto, o formato responde a uma pergunta prática: quem aprova uma política antes que eu a aplique, e onde ficam as definições compartilhadas?

Conhecimento para o exame. Conheça as três formas de conduzir um programa de governança, centralizada, federada (descentralizada) e híbrida, e o que cada uma significa para quem define a política e onde ficam as definições compartilhadas.

Faça a matriz RACI merecer seu lugar

Uma RACI (quem é Responsável, quem Aprova, quem é Consultado e quem é Informado) ajuda, mas não uma planilha gigante feita porque a governança “exige uma”. Quero que ela responda a perguntas de arquitetura, começando pelas três do capítulo 4 (As quatro perguntas por trás das categorias): onde os dados são criados, onde são editados, e onde são referenciados? Muitas vezes são sistemas diferentes. Pegue um produto: o ERP o cria, o Salesforce o referencia, o portal o mostra, o data warehouse o analisa. Agora o negócio muda o que “produto ativo” significa. Onde a mudança começa, quem a aprova, como ela se espalha, e quais cópias são somente leitura? Se você não consegue responder, ainda não tem governança. Tem cópias. Uma boa RACI expõe exatamente essa ambiguidade.

A governança precisa virar mecânica

O negócio diz que só o Financeiro pode alterar a razão social do cliente. Não quero que a resposta da arquitetura seja “vamos cobrir isso no treinamento”. Treinamento ajuda; não é aplicação. Talvez seja acesso no nível do campo, uma regra de validação, um campo que só a integração grava, ou um processo controlado em vez de edições diretas. O mecanismo depende do requisito, mas precisa existir um:

Política de governança	Quem decide	Possível ponto de aplicação
O ERP é dono da identidade legal do cliente	Financeiro	Campos só da integração, permissões, validação
Só quem precisa vê os dados pessoais	Privacidade, segurança	Compartilhamento, permissões, acesso a campos
Os identificadores de cliente são únicos	Dono do negócio	ID externo único, regras de duplicidade
Registros governados não são criados à mão	Proprietário dos dados	Permissões, automação, integração
Dados sensíveis têm um prazo de retenção definido	Privacidade, jurídico	Um processo de retenção ou exclusão
Mudanças importantes precisam ser comprováveis	Conformidade	Histórico de campos, trilha de auditoria
A origem dos dados continua identificável	Proprietário dos dados	Um campo de origem, metadados de linhagem

Digo possível ponto de aplicação de propósito. Esta não é uma tabela para escolher recursos. É a ordem do raciocínio: qual é a política, quem é o dono dela, e o que na arquitetura a torna verdadeira?

Click to enlarge

Os proprietários definem a política; os arquitetos a aplicam.

Não conte com o bom comportamento

“Nunca altere o ID de cliente do ERP.” Todo mundo sabe, até que alguém altera: por acidente, numa carga de dados, por automação, por uma integração, por um agente. Se alterá-lo prejudicaria os dados da empresa, “por favor, não” não é o controle. Construa o controle. Confie, mas verifique. Pessoas, integrações, automação e IA, todos erram, então a arquitetura deve presumir que um dia algo vai tentar o que a política proíbe. E aí, o que acontece?

A governança atravessa as fronteiras entre sistemas

De volta ao panorama. O ERP é dono do cliente; o Salesforce, o data warehouse e uma plataforma de dados do cliente (customer data platform) guardam cópias; um parceiro recebe parte dele. A qual sistema a política se aplica? A todos. O Salesforce pode bloquear corretamente uma mudança de razão social enquanto uma integração deixa um sistema mais adiante sobrescrevê-la. O Salesforce pode excluir dados pessoais que o data warehouse ainda guarda. Um campo classificado como sensível no Salesforce pode cair num campo de texto sem classificação em outro lugar. A governança não pode parar na borda da org, porque os dados não param. Foi por isso que o capítulo 4 veio primeiro: o panorama diz até onde a governança precisa chegar.

Governe o bastante, não tudo

A falha oposta é igualmente real. Descobrimos que a governança importa, então travamos tudo: ninguém pode criar, toda mudança precisa de aprovação. Os dados estão governados, e ninguém consegue trabalhar. Governança significa o controle adequado para os dados: apertado para alguns, leve para outros. Alguns registros podem ser criados livremente, outros precisam de aprovação; alguns campos quase qualquer um pode editar, outros só a integração. O próximo módulo fica prático exatamente sobre isso.

E, como a governança nunca termina, a aplicação precisa de retorno. As duplicatas estão subindo? Os campos obrigatórios estão se enchendo de lixo? As integrações estão falhando, os usuários encontrando gambiarras, as exceções crescendo, os stewards passando o dia inteiro num só problema? Esses sinais dizem se o design está funcionando e, às vezes, que o controle, ou a política, precisa mudar.

Além do exame: o que a IA muda. A governança tem um novo consumidor: o agente. O proprietário dos dados ainda decide o que pode ser usado e para quê; o arquiteto ainda torna isso aplicável. O que muda é a velocidade e a escala. Um agente lê, combina e age sobre dados governados muito mais rápido do que uma pessoa, então uma política que existe só num documento protege ainda menos.

O que um arquiteto decide aqui

• Quem é responsável por cada domínio de dados importante, e como isso difere da propriedade do registro.
• Quem é o data steward dos dados e quem os opera como custodiante.
• Onde os dados importantes são criados, editados, referenciados e mestres ao longo do panorama.
• Que ponto de aplicação torna cada política importante mecanicamente verdadeira.
• Como a arquitetura mostra se a governança está funcionando, ou começando a escorregar.

Quando ouço um requisito de governança, eu o traduzo. “O ERP é dono disto.” “Só estas pessoas podem ver isto.” “Precisamos provar quem alterou isto.” “Guarde isto por sete anos.” Toda vez: me mostre o ponto de aplicação. O arquiteto não decide a política. Projetamos o sistema que a aplica. É aí que a governança deixa de ser um documento e vira arquitetura.

Para saber mais

• Salesforce Help, Sharing and Record Access Features (opens in a new tab) (em inglês), consultado em 2026-10-14.
• Salesforce Help, Data Classification Metadata Fields (opens in a new tab) (em inglês), consultado em 2026-10-14.