Uma fonte da verdade por atributo

🌐 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 Dados mestres e identidade, capítulo 6 do curso Data Architect. Cada módulo se sustenta sozinho. Próximo: As quatro formas de gerenciar dados mestres

A pergunta que este módulo responde: O que “fonte única da verdade” realmente significa?

Há uma frase que ouço o tempo todo: “Precisamos de uma fonte única da verdade.” Certo. Da verdade sobre o quê? O cliente? Isso não é específico o bastante. Pegue uma conta. Quem é dono do nome do cliente, do endereço de cobrança, do limite de crédito, do executivo de contas, do nível de suporte, das preferências de marketing? Essas respostas não apontam para o mesmo sistema. O ERP pode controlar a razão social, o endereço de cobrança e a situação de crédito; o Salesforce, o dono do relacionamento e os atributos de vendas; outra plataforma, o consentimento. Então, quando alguém me diz “o Salesforce é a nossa fonte única da verdade sobre o cliente”, minha próxima pergunta é: qual verdade?

A verdade pertence a um atributo

O primeiro princípio dos dados mestres é este: a autoridade é atribuída por atributo, não por registro. Uma conta pode viver no Salesforce sem que o Salesforce tenha autoridade sobre cada campo dela. Sete campos num registro, duas autoridades:

Atributo	Sistema com autoridade
Razão social, endereço de cobrança, ID de cliente do ERP, limite de crédito	ERP
Executivo de contas, sinalizador de conta estratégica, nível de sucesso	Salesforce

Um registro; a verdade está distribuída. Isso é normal. “Sistema de registro = Salesforce” não descreve isso. Um modelo de autoridade, sim.

Criado, editado, referenciado, e com que rapidez?

Quando ensino dados mestres, volto sempre às mesmas perguntas para cada dado importante: onde ele é criado, onde é editado, onde é referenciado, e qual é a latência das mudanças dele? Elas expõem a arquitetura rapidinho. (Você conheceu as três primeiras no capítulo 4, ao classificar os tipos de dados; é aqui que elas fazem o trabalho de verdade.)

Pegue um ativo. Um cliente encomenda três bicicletas. O Salesforce tem a oportunidade e os itens de linha dela, e o pedido vai para o ERP. O ERP atende o pedido, e é lá que os ativos são criados: três bicicletas, três números de série, enviados de volta ao Salesforce. Meses depois, o cliente liga por causa de uma delas, e o suporte referencia o ativo num caso. Agora alguém precisa corrigir um atributo. Quais o Salesforce pode editar, e quais pertencem ao ERP que os criou? E quando o ERP muda um deles, com que rapidez o Salesforce precisa saber? Um ativo, quatro perguntas, e as respostas não são as mesmas para todos os campos.

Digamos que a razão social é criada no ERP e referenciada no Salesforce, e um vendedor percebe que ela está errada. Ele deve corrigi-la no Salesforce? Se o ERP é dono do campo, alterar a cópia não conserta nada. Na melhor das hipóteses, a próxima sincronização a sobrescreve; na pior, os dois sistemas agora discordam e ninguém sabe em qual confiar. Se o negócio quer que o vendedor inicie a correção, é diferente: o Salesforce oferece a experiência, envia uma solicitação ao ERP, o ERP faz ou aprova a mudança, e o valor com autoridade volta. É uma arquitetura muito diferente de deixar o Salesforce editar o campo por conta própria.

A latência também faz parte da verdade. O ERP muda a situação de crédito de um cliente às 10h; o Salesforce sincroniza toda noite; às 15h um vendedor olha o Salesforce. O valor está errado? Está desatualizado. Se o valor muda uma vez por ano e um dia de atraso não custa nada, toda noite serve. Se ele decide se você aceita um pedido de um milhão de dólares hoje, não serve. A autoridade diz de onde vem a verdade; a latência diz com que rapidez os outros precisam saber que ela mudou. Duas decisões separadas.

Sistema de registro, de engajamento, de referência

O vocabulário do capítulo 4 ajuda aqui. Um sistema de registro mantém a versão com autoridade. Um sistema de engajamento é onde as pessoas trabalham com ela. Um sistema de referência fornece dados que outro sistema usa, mas dos quais não é dono. O Salesforce pode ser o sistema de engajamento do relacionamento com o cliente enquanto o ERP continua sendo o sistema de registro dos atributos legais e financeiros dele. Isso não é uma fraqueza da arquitetura; é a arquitetura. O erro é fingir que um sistema precisa ser dono de tudo para o diagrama parecer mais simples.

O golden record híbrido

Isso muda o que “golden record” significa. O capítulo 5 apresentou a ideia ao falar de manter os dados ruins do lado de fora; aqui ela é o coração do design. As pessoas imaginam um registro mágico com cada campo gerenciado num só lugar. Às vezes esse é o design. No Salesforce, com mais frequência vejo um híbrido: parte da conta é mestre em outro lugar e copiada para dentro (razão social, número de cliente do ERP, endereço de cobrança, situação de crédito), e parte só existe porque o Salesforce precisa dela (executivo de contas, estratégia de oportunidades, nível de sucesso, observações de relacionamento). Os campos do ERP entram para que as pessoas possam usá-los. Os campos do Salesforce nunca voltam, porque o ERP não se importa com eles. Perfeitamente razoável, desde que todo mundo saiba qual é qual.

Torne a autoridade visível

Então deixo a autoridade externa óbvia no esquema. Se o SAP controla um campo, ele ganha um prefixo: sap_Customer_Number, sap_Credit_Status, sap_Legal_Name. É a mesma ideia do prefixo erp_ do capítulo 4. Use o nome do sistema quando essa autoridade for específica e estável, e um prefixo genérico quando o significado importar mais do que o fornecedor de hoje. O ponto é que, seis meses depois, alguém lendo o modelo consiga ver: este não é só mais um campo do Salesforce; outro sistema é dono deste valor. Não obrigue as pessoas a redescobrir a autoridade fazendo engenharia reversa das integrações.

Construa um mapa de autoridade

Para dados mestres importantes, quero um mapa de autoridade: para cada atributo-chave, quem o cria, quem é dono da decisão de negócio, qual sistema tem autoridade, e quem ou o que pode alterá-lo. Quatro perguntas diferentes:

Atributo	Criado por	Dono do negócio	Sistema com autoridade	Pode alterá-lo
Razão social	Financeiro	Financeiro	ERP	O processo financeiro
Limite de crédito	Financeiro	Financeiro	ERP	A equipe de crédito
Executivo de contas	Operações de vendas	Vendas	Salesforce	A gestão de vendas
Nível de suporte	Operações de atendimento	Atendimento	Salesforce	A gestão de atendimento
Consentimento	O cliente	Privacidade	Plataforma de consentimento	O cliente, um processo aprovado

Repare que dono do negócio e sistema com autoridade não são a mesma coisa. Um sistema não é dono da política; as pessoas são. O sistema guarda e aplica o resultado. É o capítulo 5 de novo: os donos definem a política; os arquitetos a aplicam.

Click to enlarge

Um cliente. Muitos atributos. Uma autoridade para cada um.

A autoridade muda ao longo do ciclo de vida

Um vendedor conhece um prospect de quem o ERP nunca ouviu falar e cria a conta no Salesforce. Nesse momento, o Salesforce tem autoridade sobre o nome, o endereço, os contatos e a qualificação. O prospect vira cliente; o ERP cria o cliente oficial e atribui o número de cliente, a razão social, o endereço de cobrança e o crédito. A autoridade mudou. O Salesforce não estava errado antes; o ciclo de vida mudou. É o padrão de provisório para governado do capítulo 5: antes da conversão, o Salesforce é dono do prospect; depois, o ERP é dono dos atributos governados, e o Salesforce continua dono dos seus. Então “qual sistema é dono da conta?” é uma pergunta fraca. Pergunte: qual sistema é dono deste atributo, neste ponto do ciclo de vida?

Uma cópia não é autoridade

Copiamos dados do ERP para o Salesforce porque as pessoas precisam deles o tempo todo. Isso faz do Salesforce uma cópia local conveniente, não o mestre, e a arquitetura deve se comportar de acordo: somente leitura para os usuários, atualizada pela integração, rotulada com sua origem, alterada só por meio de uma solicitação, conferida por reconciliação quando a cópia se desvia. A cópia é útil. A autoridade não se moveu.

A confiança precisa de mais do que um valor

“Endereço de cobrança: Rua Principal, 123.” Você deve confiar nele? Quero sinais de confiança: de onde veio, quando foi confirmado pela última vez, qual sistema o forneceu, e quem ou o que o alterou por último: uma pessoa, uma integração, um agente? Agora o ERP diz Rua Principal, 123, o Salesforce diz 125, e o arquivo de um parceiro diz “R. Principal, 123, sala 200”. Qual está certo? Não responda “use o mais recente”. Talvez. Mas “o mais recente” é em si uma regra que presume que quem alterou por último merece vencer. Isso pode ser verdade, ou terrível. O módulo 3 enfrenta isso. A confiança vem da autoridade e da procedência, não de encontrar um campo preenchido.

Steve Trucking: de quem é a verdade?

Um Parceiro varejista envia uma entrega, e várias verdades se escondem nessa única transação. A referência de pedido do parceiro é do parceiro; a Steve Trucking a guarda para casar as atualizações, mas não vira o mestre dela. O status da entrega (chegou, entregue, instalada, uma exceção) é da Steve Trucking; o parceiro o recebe, mas receber um status não dá ao parceiro autoridade sobre o que aconteceu no caminhão. E o Destinatário é cliente do parceiro. O parceiro fornece o nome, o endereço, o telefone e as observações de entrega porque a Steve Trucking precisa deles para entregar. Isso não faz da Steve Trucking a mestre da identidade dessa pessoa, e essa distinção decide o design do Destinatário no checkpoint.

Click to enlarge

Uma entrega, duas autoridades.

Onde os dados vivem e quem é dono da verdade deles são perguntas diferentes. O Salesforce pode guardar o número de cliente do ERP sem ser dono dele; o Snowflake pode guardar o status das entregas sem ser o mestre operacional dele; uma plataforma de dados do cliente (CDP) pode unificar identidades sem ser dona de cada atributo. Um agente pode ler os três, e isso certamente não deixa o agente decidir qual é verdadeiro.

Além do exame: o que a IA muda. Os agentes transformam a autoridade por atributo numa regra de execução. Uma pessoa vê um endereço de cobrança errado e sabe: “isso vem do SAP; não devo alterar aqui”. Um agente instruído a “atualizar o endereço de cobrança do cliente” não vai saber, a menos que projetemos para isso. Ele precisa do mesmo mapa de autoridade que o arquiteto tem: ter acesso a um campo não torna esse campo o lugar certo para gravar.

O que um arquiteto decide aqui

• Qual sistema tem autoridade sobre cada atributo importante, em vez de um sistema para um registro inteiro.
• Onde cada atributo é criado, editado e referenciado, e com que rapidez as mudanças dele precisam viajar.
• Quem define a política de cada atributo, e quais pessoas, integrações ou agentes podem alterá-lo.
• Como a autoridade externa aparece no modelo: prefixos de nomenclatura, permissões, comportamento da integração.
• Como a autoridade muda ao longo do ciclo de vida, como um prospect que vira cliente governado pelo ERP.

Uma fonte única da verdade não significa uma org, um ERP, uma plataforma de MDM ou um registro gigante. Significa que, para cada informação governada, a arquitetura consegue dizer onde está o valor com autoridade, e todos os outros sistemas sabem como se comportar por causa disso. Isso não é uma fonte única da verdade. É uma arquitetura da verdade.

Para saber mais

• Salesforce Architects, Data 360 Architecture (opens in a new tab) (em inglês), consultado em 2026-10-14.