A governação é projetada dentro da org

🌐 Também em 28 idiomas

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · 繁體中文 · 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 com IA. Ainda não revisto pela comunidade. Ler em inglês

Módulo 1 de 6 do capítulo Qualidade e governação de dados, capítulo 5 do curso Data Architect. Cada módulo sustenta-se sozinho. Próximo: Manter os dados maus lá fora

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

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

Se a política diz que só as Finanças podem alterar um campo, o que aplica isso? Se diz que o ERP é dono do registo legal do cliente, o que impede alguém no Salesforce de o alterar? Se diz que as equipas veem a morada de um Destinatário só nas suas próprias paragens, só no dia, o que torna isso realmente verdade? Se diz guarde isto durante sete anos, o que o arquiva ou remove passados os sete? Uma política sem ponto de aplicação é, em boa parte, um desejo. A governação torna-se arquitetura quando essas decisões são construídas dentro do sistema.

A governação nunca termina

Deixe-me tirar isto já do caminho: não se termina a governação. 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 lado, e a qualidade escorrega. Uma nova integração entra em produção, uma unidade de negócio muda o seu processo, alguém importa um ficheiro, a empresa adquire outra, um agente começa a gravar registos, e o problema muda outra vez. O objetivo não é um estado mítico em que cada registo é perfeito para sempre. É manter os dados suficientemente fiáveis para o negócio e manter lá fora o pior dos dados maus. É trabalho contínuo.

Quando o Salesforce está praticamente sozinho, governação significa limpar dados num só lugar. Quando é 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 o pode alterar? Que cópia tem autoridade, que atributos se podem mover, durante quanto tempo são guardados, e quem responde quando estão errados? Estas não são perguntas de configuração. São perguntas de governação que se tornam configuração.

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

Comece pela palavra proprietário, porque o Salesforce a torna confusa. Abra uma conta e vê um Proprietário: um comercial, digamos. O comercial é dono dos dados do cliente? Não necessariamente. No Salesforce, um registo de um objeto com proprietário pertence a um utilizador ou a uma fila; o proprietário recebe acesso total, e determina a atribuição e a partilha através da hierarquia de funções e das regras de partilha (Sharing and Record Access Features (opens in a new tab), em inglês). Isso é propriedade do registo: 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. As Finanças podem ser donas da informação legal do cliente, as Operações do estado das entregas, os RH dos dados dos colaboradores. O Salesforce até lhe dá um sítio para registar 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 retalhista pode ter como proprietário o gestor comercial que acompanha esse parceiro. Mas a identidade legal do parceiro é governada pelas Finanças e mestre no ERP financeiro. Vendas, atendimento, operações e o portal do parceiro precisam todos da conta; nada disso significa que o gestor comercial deva alterar a identidade legal do parceiro depois de as Finanças a terem estabelecido. Já vi equipas olharem para o campo Proprietário e acharem que resolveram a propriedade dos dados. Não resolveram. Atribuição de registo não é responsabilidade de negócio.

Proprietário, data steward, custodiante

Três papéis de governação, três trabalhos diferentes.

O proprietário dos dados define a política. Responde ao que os dados significam, quem os pode criar e alterar, quão precisos têm de ser, durante quanto tempo são guardados, quem os pode ver, que sistema tem autoridade, e o que acontece quando estão errados. O arquiteto não deve inventar essas respostas. Esta é uma das minhas posições mais firmes: os donos definem a política; os arquitetos aplicam-na. Se as Finanças dizem que a denominação social só pode mudar através do processo do ERP depois de o cliente estar ativo, essa é uma decisão de governação. Torná-la mecanicamente verdadeira é o meu trabalho.

O data steward (curador dos dados) mantém tudo a funcionar. O steward está perto da saúde diária dos dados: acompanha sinais de qualidade, investiga duplicados, resolve exceções, coordena correções, mantém definições, identifica o processo que não para de produzir dados maus. Há mais duas tarefas que cabem ao steward. Quando duas equipas discordam sobre o que um campo significa, quem é o dono dele ou quem o pode ver, o steward leva a disputa ao proprietário e acompanha a decisão até ao fim. E o steward desenvolve a literacia de dados (data literacy): ajuda as pessoas que introduzem e usam os dados a entender o que significam e porque é que as regras existem. Um steward precisa de mais do que um nome num organograma. Precisa de tempo, visibilidade, um processo e autoridade para pôr os problemas a ser corrigidos. Caso contrário, «data steward» passa a ser a oitava responsabilidade de alguém, vista uma vez por trimestre.

O custodiante opera o sistema. Administradores, equipas de plataforma, equipas de segurança: quem opera a tecnologia que armazena e processa os dados. O proprietário diz que só estas funções os podem ver; o custodiante opera os controlos 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 governação costumam ter três formatos. Centralizado: uma equipa escreve as políticas e os padrões para todos os domínios. É consistente, e pode tornar-se um ponto de estrangulamento, longe das pessoas que fazem o trabalho. Federado (descentralizado): cada domínio, como finanças, vendas ou operações, governa os seus próprios dados dentro de algumas regras partilhadas. Fica perto do trabalho, e as definições afastam-se entre os domínios. Híbrido: uma pequena equipa central é dona dos padrões e das definições partilhadas, e os proprietários e stewards de cada domínio cuidam dos seus próprios dados. A maioria das empresas que já vi acaba algures no híbrido. Para o arquiteto, o formato responde a uma pergunta prática: quem aprova uma política antes de eu a aplicar, e onde ficam as definições partilhadas?

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

Faça a matriz RACI merecer o seu lugar

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

A governação tem de se tornar mecânica

O negócio diz que só as Finanças podem alterar a denominação social do cliente. Não quero que a resposta da arquitetura seja «vamos tratar disso na formação». A formação ajuda; não é aplicação. Talvez seja acesso ao 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 tem de existir um:

Política de governação	Quem decide	Possível ponto de aplicação
O ERP é dono da identidade legal do cliente	Finanças	Campos só da integração, permissões, validação
Só quem precisa vê os dados pessoais	Privacidade, segurança	Partilha, permissões, acesso a campos
Os identificadores de cliente são únicos	Dono do negócio	ID externo único, regras de duplicados
Os registos governados não são criados à mão	Proprietário dos dados	Permissões, automação, integração
Os dados sensíveis têm um prazo de retenção definido	Privacidade, jurídico	Um processo de retenção ou eliminação
As mudanças importantes têm de ser comprováveis	Conformidade	Histórico de campos, registo 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 funcionalidades. É a ordem do raciocínio: qual é a política, quem é o seu dono, e o que na arquitetura a torna verdadeira?

Click to enlarge

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

Não conte com o bom comportamento

«Nunca altere o ID de cliente do ERP.» Toda a gente sabe, até alguém o alterar: 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 controlo. Construa o controlo. Confie, mas verifique. Pessoas, integrações, automação e IA, todos erram, por isso a arquitetura deve presumir que um dia algo vai tentar o que a política proíbe. E então, o que acontece?

A governação atravessa as fronteiras entre sistemas

De volta ao panorama. O ERP é dono do cliente; o Salesforce, o data warehouse e uma plataforma de dados de clientes (customer data platform) guardam cópias; um parceiro recebe parte deles. A que sistema se aplica a política? A todos. O Salesforce pode bloquear corretamente uma mudança de denominação social enquanto uma integração deixa um sistema a jusante sobrescrevê-la. O Salesforce pode eliminar 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 noutro sítio. A governação não pode parar na fronteira da org, porque os dados não param. Foi por isso que o capítulo 4 veio primeiro: o panorama diz até onde a governação tem de chegar.

Governe o suficiente, não tudo

A falha oposta é igualmente real. Descobrimos que a governação importa, por isso trancamos tudo: ninguém pode criar, cada mudança precisa de aprovação. Os dados estão governados, e ninguém consegue trabalhar. Governação significa o controlo adequado aos dados: apertado para alguns, leve para outros. Alguns registos podem ser criados livremente, outros precisam de aprovação; alguns campos quase qualquer pessoa pode editar, outros só a integração. O próximo módulo fica prático exatamente sobre isto.

E, como a governação nunca termina, a aplicação precisa de retorno. Os duplicados estão a subir? Os campos obrigatórios estão a encher-se de lixo? As integrações estão a falhar, os utilizadores a encontrar formas de contornar, as exceções a crescer, os stewards a passar o dia inteiro num só problema? Esses sinais dizem se o design está a funcionar e, às vezes, que o controlo, ou a política, tem de mudar.

Além do exame: o que a IA muda. A governação tem um novo consumidor: o agente. O proprietário dos dados continua a decidir o que pode ser usado e para quê; o arquiteto continua a torná-lo aplicável. O que muda é a velocidade e a escala. Um agente lê, combina e age sobre dados governados muito mais depressa do que uma pessoa, por isso 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 registo.
• 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 mostra a arquitetura se a governação está a funcionar, ou a começar a escorregar.

Quando ouço um requisito de governação, traduzo-o. «O ERP é dono disto.» «Só estas pessoas podem ver isto.» «Temos de provar quem alterou isto.» «Guarde isto durante sete anos.» Sempre: mostre-me o ponto de aplicação. O arquiteto não decide a política. Projetamos o sistema que a aplica. É aí que a governação deixa de ser um documento e se torna 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.