As quatro formas de gerenciar dados mestres
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)
Módulo 2 de 6 do capítulo Dados mestres e identidade, capítulo 6 do curso Data Architect. Cada módulo se sustenta sozinho. Anterior: Uma fonte da verdade por atributo · Próximo: Correspondência, mesclagem e sobrevivência
A pergunta que este módulo responde: Como as organizações gerenciam dados mestres, e qual estilo serve?
O módulo 1 disse que a autoridade é atribuída atributo por atributo. Agora: o que fazemos quando esses atributos vivem em vários sistemas ao mesmo tempo? Informações de cliente no Salesforce, no ERP, no faturamento, no atendimento, talvez no Data 360, talvez num data warehouse, cada um com sua própria versão. Esse é o problema que o gerenciamento de dados mestres (MDM) tenta resolver, e o MDM não é uma arquitetura só. Você vai ouvir quatro padrões: registry, consolidação, coexistência e centralizado. Não são configurações de produto. São quatro respostas para uma pergunta: quanta autoridade a camada de dados mestres tem?
Comece pelo problema, não pelo produto
Seção intitulada “Comece pelo problema, não pelo produto ”As pessoas ouvem MDM e saem comprando um produto de MDM. Eu começaria pelo problema. Só precisamos saber que vários registros são o mesmo cliente? Precisamos de uma visão combinada para análise? Precisamos decidir quais valores têm autoridade e devolvê-los a outros sistemas? Ou queremos um sistema central criando os dados mestres para todos? Requisitos muito diferentes, arquiteturas muito diferentes.
Registry: me diga quem é quem
Seção intitulada “Registry: me diga quem é quem ”O padrão mais leve. Um registry (um registro central de identidades) não substitui as fontes. O ERP mantém seu cliente, o Salesforce sua conta, o faturamento seu cliente, e o registry descobre que esses registros representam a mesma entidade: a conta Salesforce 001…, o cliente do ERP SAP-43821 e o cliente do faturamento BILL-9127 pertencem a um cliente. As fontes ficam onde estão e não são sobrescritas. Agora “me mostre tudo o que sabemos sobre este cliente” tem resposta.
Mas repare no que um registry não responde. O Salesforce diz Rua Principal, 123, o ERP 125, o faturamento “R. Principal, 123, sala 200”. O registry sabe que eles pertencem juntos. Ele não decide qual deve mudar. Vincular não é gerenciar dados mestres.
Na minha experiência, o registry é a norma em projetos Salesforce, depois a consolidação e a coexistência; o MDM centralizado puro é raro. O registry é comum porque não é invasivo. Você não reprojeta cada sistema operacional antes de obter valor. O Salesforce continua fazendo o que faz, o ERP continua fazendo o que faz, e você acrescenta uma camada de identidade. É uma mudança muito menor do que dizer a cada sistema “você não controla mais os dados de cliente; este novo sistema central controla”.
O registry responde: quais registros pertencem à mesma entidade?
Consolidação: junte os dados
Seção intitulada “Consolidação: junte os dados ”A consolidação pega dados de várias fontes e os combina numa representação central, para relatórios, análise, segmentação, inteligência de cliente. Um data warehouse é o exemplo conhecido: o Salesforce envia o cliente, o ERP os dados financeiros, o faturamento os pagamentos, e o negócio finalmente consegue analisar o cliente entre sistemas. As fontes continuam existindo e podem continuar tendo autoridade. A direção importa: os dados fluem para dentro do sistema consolidado, que normalmente não devolve mudanças mestres. Uma imagem melhor do cliente, sem virar a autoridade operacional dele.
Registry e consolidação são fáceis de confundir. A diferença é o que fica centralizado: o registry centraliza a identidade (“estes pertencem juntos”); a consolidação centraliza mais dos dados (“junte os atributos para podermos usá-los”). Nenhum dos dois diz “este sistema central agora é o mestre e toda aplicação precisa aceitar seus valores”.
A consolidação junta os dados sem tirar a propriedade das fontes.
Coexistência: decida, e devolva
Seção intitulada “Coexistência: decida, e devolva ”Na coexistência, a camada de dados mestres ganha autoridade real. Os dados continuam vivendo em vários sistemas operacionais, mas o processo de MDM decide o valor mestre e o publica de volta. O Salesforce, o ERP e o faturamento têm, cada um, uma razão social diferente; o processo de MDM determina a governada e a distribui aos três. Os sistemas coexistem, mas convergem para o valor mestre.
É uma forma muito mais forte de MDM. Ela não está dizendo “estes pertencem juntos”; está dizendo “para este atributo, este é o valor que a empresa usa”. Isso exige mais do que correspondência: regras de negócio, propriedade, sobrevivência, integração de mão dupla, tratamento de erros e governança, porque alguém precisa decidir por que um valor vence.
A coexistência não só vincula os registros. Ela decide os valores mestres e os envia de volta.
Centralizado: o mestre cria a verdade
Seção intitulada “Centralizado: o mestre cria a verdade ”O padrão mais forte. No MDM centralizado, os dados mestres governados são criados e mantidos no mestre central e distribuídos a todos os outros. Em vez de cada sistema criar seu próprio cliente e o MDM reconciliá-los depois, você cria o cliente governado no mestre, e então o envia ao Salesforce, ao ERP e ao faturamento. Governança muito forte, e mudança muito significativa: os processos existentes criam seus próprios clientes, os usuários têm seus fluxos de trabalho, as integrações presumem criação local, e as unidades de negócio talvez nem concordem sobre o que é um cliente. É por isso que ele é raro nos panoramas Salesforce que vejo. Pode ser o certo. É uma decisão muito maior do que instalar uma ferramenta.
O MDM centralizado leva a criação e a autoridade para dentro do mestre.
Os quatro lado a lado
Seção intitulada “Os quatro lado a lado ”| Estilo | O que é centralizado | As fontes continuam? | Devolve os valores governados? |
|---|---|---|---|
| Registry | Identidade e vínculos | Sim | Normalmente não |
| Consolidação | Identidade mais dados combinados | Sim | Normalmente não |
| Coexistência | Identidade, dados e decisões mestres | Sim | Sim |
| Centralizado | Criação e autoridade | Sim, como consumidoras | Sim |
Descendo a tabela, a camada de dados mestres ganha mais autoridade, e a organização normalmente precisa mudar mais.
Conhecimento para o exame. Conheça os quatro estilos de implementação de MDM: registry (vincula identidades; as fontes ficam com seus dados), consolidação (junta os dados, normalmente para análise), coexistência (decide os valores mestres e os publica de volta para as fontes) e centralizado (o mestre cria os dados; as fontes os consomem).
Então não existe “centralizado é o mais maduro, todo mundo deveria chegar lá”. Escolha o padrão mais leve que resolve o problema. Precisa saber que registros pertencem juntos? Pense em registry. Uma visão combinada para análise? Consolidação. Valores governados sincronizados de volta a vários sistemas operacionais? Coexistência. Um processo criando e controlando os dados mestres para todos? Centralizado.
Onde o Data 360 se encaixa?
Seção intitulada “Onde o Data 360 se encaixa? ”O Data 360 constrói perfis unificados a partir de muitas fontes, o que soa bastante como MDM, e ele de fato resolve parte do problema. A resolução de identidade dele casa os perfis de origem numa identidade unificada e mantém os vínculos de volta aos registros de origem (Data 360 Architecture (opens in a new tab), em inglês). Isso o deixa mais perto de um registry. Ele também consegue mostrar valores reconciliados no perfil unificado. Mas isso não faz dele um sistema centralizado de golden records que reescreve as fontes. Uma visão unificada não é automaticamente um registro corporativo mestre. O módulo 4 é todo sobre essa diferença.
Um modelo comum não é uma verdade comum
Seção intitulada “Um modelo comum não é uma verdade comum ”Você também vai ouvir falar de modelo de dados canônico. A Conta do Salesforce, o parceiro de negócios do ERP e o cliente do faturamento se mapeiam todos para um conceito corporativo acordado, Cliente, com identificadores e atributos acordados, para que cada integração não precise entender a forma de cada outro sistema. O modelo de dados do Data 360 é um exemplo de harmonizar fontes em conceitos comuns. Mas um modelo canônico responde como representamos isto de forma consistente? O MDM responde como identificamos, governamos e gerenciamos isto como dado mestre entre sistemas? Mapeie os três sistemas perfeitamente numa forma de Cliente, e o Salesforce ainda diz Rua Principal, 123 enquanto o ERP diz 125. Você resolveu a estrutura, não a autoridade. Harmonizar e gerenciar dados mestres não são intercambiáveis.
Um negócio, vários padrões
Seção intitulada “Um negócio, vários padrões ”Então “a Steve Trucking precisa de MDM” não é um requisito. Para quê? Parceiros varejistas, centros de distribuição, equipes, caminhões, Destinatários são domínios diferentes, com autoridades diferentes: os Parceiros varejistas governados no Salesforce e no ERP financeiro, a identidade dos caminhões vinda do FleetLink, cada Destinatário fornecido por um parceiro a cada entrega. Domínios diferentes podem seguir padrões diferentes e, dentro de um domínio, atributos podem ter autoridades diferentes. Então não desenhe uma caixa rotulada MDM no meio do diagrama e dê por resolvido. Pergunte o que a caixa faz.
O estilo também muda a integração. O registry precisa de vínculos de identidade; a consolidação, de fluxos de entrada confiáveis; a coexistência, de dados nas duas direções; o centralizado, de distribuição a partir do mestre mais controles que impeçam outros sistemas de criar uma verdade rival. À medida que a autoridade cresce, cresce também a coordenação, e o tratamento de falhas: e se o MDM muda a razão social e o ERP a rejeita? É por isso que a coexistência e o centralizado não são “registry com mais recursos”. Carregam responsabilidades operacionais diferentes.
MDM é uma decisão de negócio
Seção intitulada “MDM é uma decisão de negócio ”O ponto mais importante: MDM não é, no fundo, uma decisão de tecnologia. É uma decisão sobre autoridade. Quem cria o cliente, quem pode alterá-lo, quem decide qual valor vence, quais sistemas precisam aceitá-lo, o que acontece quando discordam. Uma ferramenta pode implementar essas decisões; não pode fazer a organização concordar com elas. É por isso que um projeto de MDM pode ter uma tecnologia excelente e ainda assim fracassar: a equipe técnica resolveu a correspondência, e o negócio nunca resolveu a propriedade.
A lição geral que aprendi do jeito difícil: quando vários sistemas são mestres dos mesmos dados, o Salesforce não consegue reconciliar aquilo em que eles não concordam. Quando uma empresa roda dois ERPs, eu pergunto como ela os mantém sincronizados. Se ela não consegue, o Salesforce também não consegue. O módulo 5 conta essa história (Um cliente, dois ERPs).
O que um arquiteto decide aqui
Seção intitulada “O que um arquiteto decide aqui ”- Se o problema precisa de vínculos de identidade, de dados combinados, de valores mestres devolvidos ou de criação central.
- Qual padrão serve a cada domínio de dados, em vez de um padrão para a empresa inteira.
- Quanta autoridade a camada de dados mestres recebe, e quais sistemas precisam aceitar as decisões dela.
- Se um modelo canônico é necessário, sem confundir harmonização com autoridade.
- Como o padrão escolhido muda a direção da integração, a propriedade e o tratamento de falhas.
Quando alguém colocar uma caixa de MDM num diagrama, pergunte o que ela faz. Ela sabe quais registros pertencem juntos? Combina os dados deles? Decide quais valores vencem? Devolve essas decisões? Cria os dados, para começo de conversa? As respostas dizem que arquitetura você realmente tem, e onde vive a autoridade.
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.