Uma fonte da verdade por atributo
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)
Módulo 1 de 6 do capítulo Dados mestres e identidade, capítulo 6 do curso Data Architect. Cada módulo sustenta-se sozinho. Próximo: As quatro formas de gerir dados mestres
A pergunta que este módulo responde: O que significa realmente «fonte única da verdade»?
Há uma frase que ouço constantemente: «Precisamos de uma fonte única da verdade.» Certo. Da verdade sobre quê? O cliente? Isso não é suficientemente específico. Pegue numa conta. Quem é dono do nome do cliente, da morada de faturação, do limite de crédito, do gestor de conta, do nível de suporte, das preferências de marketing? Essas respostas não apontam para o mesmo sistema. O ERP pode controlar a denominação social, a morada de faturação e a situação de crédito; o Salesforce, o dono da relação e os atributos de vendas; outra plataforma, o consentimento. Por isso, quando alguém me diz «o Salesforce é a nossa fonte única da verdade sobre o cliente», a minha pergunta seguinte é: que verdade?
A verdade pertence a um atributo
Seção intitulada “A verdade pertence a um atributo ”O primeiro princípio dos dados mestres é este: a autoridade é atribuída por atributo, não por registo. Uma conta pode viver no Salesforce sem que o Salesforce tenha autoridade sobre cada um dos seus campos. Sete campos num registo, duas autoridades:
| Atributo | Sistema com autoridade |
|---|---|
| Denominação social, morada de faturação, ID de cliente do ERP, limite de crédito | ERP |
| Gestor de conta, indicador de conta estratégica, nível de sucesso | Salesforce |
Um registo; a verdade está distribuída. Isso é normal. «Sistema de registo = Salesforce» não descreve isto. Um modelo de autoridade, sim.
Criado, editado, referenciado, e com que rapidez?
Seção intitulada “Criado, editado, referenciado, e com que rapidez? ”Quando ensino dados mestres, volto sempre às mesmas perguntas para cada dado importante: onde é criado, onde é editado, onde é referenciado, e qual é a latência das suas mudanças? Expõem a arquitetura num instante. (Conheceu as três primeiras no capítulo 4, ao classificar os tipos de dados; é aqui que fazem o verdadeiro trabalho.)
Pense num ativo. Um cliente encomenda três bicicletas. O Salesforce tem a oportunidade e os seus itens de linha, e a encomenda vai para o ERP. O ERP satisfaz a encomenda, 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 telefona por causa de uma delas, e o suporte referencia o ativo num caso. Agora alguém precisa de corrigir um atributo. Quais pode o Salesforce editar, e quais pertencem ao ERP que os criou? E quando o ERP muda um deles, com que rapidez precisa o Salesforce de saber? Um ativo, quatro perguntas, e as respostas não são as mesmas para todos os campos.
Digamos que a denominação social é criada no ERP e referenciada no Salesforce, e um comercial repara que está errada. Deve corrigi-la no Salesforce? Se o ERP é dono do campo, alterar a cópia não corrige nada. Na melhor das hipóteses, a próxima sincronização sobrescreve-a; na pior, os dois sistemas passam a discordar e ninguém sabe em qual confiar. Se o negócio quer que o comercial inicie a correção, é diferente: o Salesforce oferece a experiência, envia um pedido 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 todas as noites; às 15h um comercial olha para 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, todas as noites serve. Se decide se aceita hoje uma encomenda de um milhão de dólares, não serve. A autoridade diz de onde vem a verdade; a latência diz com que rapidez os outros precisam de saber que ela mudou. Duas decisões separadas.
Sistema de registo, de envolvimento, de referência
Seção intitulada “Sistema de registo, de envolvimento, de referência ”O vocabulário do capítulo 4 ajuda aqui. Um sistema de registo mantém a versão com autoridade. Um sistema de envolvimento é 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 envolvimento da relação com o cliente enquanto o ERP continua a ser o sistema de registo dos seus atributos legais e financeiros. Isso não é uma fraqueza da arquitetura; é a arquitetura. O erro é fingir que um sistema tem de ser dono de tudo para o diagrama parecer mais simples.
O golden record híbrido
Seção intitulada “O golden record híbrido ”Isso muda o que «golden record» significa. O capítulo 5 apresentou a ideia a propósito de manter os dados maus fora; aqui é o coração do design. As pessoas imaginam um registo mágico com cada campo gerido num só lugar. Às vezes esse é o design. No Salesforce, com mais frequência vejo um híbrido: parte da conta é mestre noutro lugar e copiada para dentro (denominação social, número de cliente do ERP, morada de faturação, situação de crédito), e parte só existe porque o Salesforce precisa dela (gestor de conta, estratégia de oportunidades, nível de sucesso, notas da relação). Os campos do ERP entram para que as pessoas os possam usar. Os campos do Salesforce nunca voltam, porque o ERP não se importa com eles. Perfeitamente razoável, desde que toda a gente saiba qual é qual.
Torne a autoridade visível
Seção intitulada “Torne a autoridade visível ”Por isso torno óbvia no esquema a autoridade externa. Se o SAP controla um campo, este 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, quem leia 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 inversa das integrações.
Construa um mapa de autoridade
Seção intitulada “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, que sistema tem autoridade, e quem ou o que o pode alterar. Quatro perguntas diferentes:
| Atributo | Criado por | Dono do negócio | Sistema com autoridade | Pode alterá-lo |
|---|---|---|---|---|
| Denominação social | Finanças | Finanças | ERP | O processo financeiro |
| Limite de crédito | Finanças | Finanças | ERP | A equipa de crédito |
| Gestor de conta | Operações de vendas | Vendas | Salesforce | A direção de vendas |
| Nível de suporte | Operações de atendimento | Atendimento | Salesforce | A direçã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 é que são. O sistema guarda e aplica o resultado. É outra vez o capítulo 5: os donos definem a política; os arquitetos aplicam-na.
Um cliente. Muitos atributos. Uma autoridade para cada um.
A autoridade muda ao longo do ciclo de vida
Seção intitulada “A autoridade muda ao longo do ciclo de vida ”Um comercial 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, a morada, os contactos e a qualificação. O prospect torna-se cliente; o ERP cria o cliente oficial e atribui o número de cliente, a denominação social, a morada de faturação 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. Por isso «que sistema é dono da conta?» é uma pergunta fraca. Pergunte: que sistema é dono deste atributo, neste ponto do ciclo de vida?
Uma cópia não é autoridade
Seção intitulada “Uma cópia não é autoridade ”Copiamos dados do ERP para o Salesforce porque as pessoas precisam deles constantemente. Isso faz do Salesforce uma cópia local conveniente, não o mestre, e a arquitetura deve comportar-se em conformidade: só de leitura para os utilizadores, atualizada pela integração, rotulada com a sua origem, alterada só através de um pedido, conferida por reconciliação quando a cópia se desvia. A cópia é útil. A autoridade não se mexeu.
A confiança precisa de mais do que um valor
Seção intitulada “A confiança precisa de mais do que um valor ”«Morada de faturação: Rua Principal, 123.» Deve confiar nela? Quero sinais de confiança: de onde veio, quando foi confirmada pela última vez, que sistema a forneceu, e quem ou o que a alterou por último: uma pessoa, uma integração, um agente? Agora o ERP diz Rua Principal, 123, o Salesforce diz 125, e o ficheiro de um parceiro diz «R. Principal, 123, sala 200». Qual está certa? Não responda «use a mais recente». Talvez. Mas «a mais recente» é em si uma regra que presume que quem alterou por último merece ganhar. Isso pode ser verdade, ou terrível. O módulo 3 enfrenta isso. A confiança vem da autoridade e da proveniência, não de encontrar um campo preenchido.
Steve Trucking: de quem é a verdade?
Seção intitulada “Steve Trucking: de quem é a verdade? ”Um Parceiro retalhista envia uma entrega, e várias verdades se escondem nessa única transação. A referência de encomenda do parceiro é do parceiro; a Steve Trucking guarda-a para fazer corresponder as atualizações, mas não se torna o seu mestre. O estado da entrega (chegou, entregue, instalada, uma exceção) é da Steve Trucking; o parceiro recebe-o, mas receber um estado não dá ao parceiro autoridade sobre o que aconteceu no camião. E o Destinatário é cliente do parceiro. O parceiro fornece o nome, a morada, o telefone e as notas 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.
Uma entrega, duas autoridades.
Onde vivem os dados e quem é dono da sua verdade são perguntas diferentes. O Salesforce pode guardar o número de cliente do ERP sem ser dono dele; o Snowflake pode guardar o estado das entregas sem ser o seu mestre operacional; 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ê uma morada de faturação errada e sabe: «isto vem do SAP; não devo alterar aqui». Um agente instruído a «atualizar a morada de faturação do cliente» não vai saber, a menos que projetemos para isso. 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
Seção intitulada “O que um arquiteto decide aqui ”- Que sistema tem autoridade sobre cada atributo importante, em vez de um sistema para um registo inteiro.
- Onde cada atributo é criado, editado e referenciado, e com que rapidez as suas mudanças precisam de viajar.
- Quem define a política de cada atributo, e que pessoas, integrações ou agentes o podem alterar.
- 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 se torna cliente governado pelo ERP.
Uma fonte única da verdade não significa uma org, um ERP, uma plataforma de MDM ou um registo 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
Seção intitulada “Para saber mais ”- Salesforce Architects, Data 360 Architecture (opens in a new tab) (em inglês), consultado em 2026-10-14.