As quatro formas de gerir dados mestres
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 2 de 6 do capítulo Dados mestres e identidade, capítulo 6 do curso Data Architect. Cada módulo sustenta-se sozinho. Anterior: Uma fonte da verdade por atributo · Próximo: Correspondência, fusão e sobrevivência
A pergunta que este módulo responde: Como gerem as organizações os dados mestres, e que estilo serve?
O módulo 1 disse que a autoridade é atribuída atributo a atributo. Agora: o que fazemos quando esses atributos vivem em vários sistemas ao mesmo tempo? Informação de cliente no Salesforce, no ERP, na faturação, no atendimento, talvez no Data 360, talvez num data warehouse, cada um com a sua própria versão. Esse é o problema que a gestão de dados mestres (MDM) tenta resolver, e o MDM não é uma só arquitetura. Vai ouvir falar de quatro padrões: registry, consolidação, coexistência e centralizado. Não são configurações de produto. São quatro respostas a uma pergunta: quanta autoridade tem a camada de dados mestres?
Comece pelo problema, não pelo produto
Seção intitulada “Comece pelo problema, não pelo produto ”As pessoas ouvem MDM e vão a correr comprar um produto de MDM. Eu começaria pelo problema. Só precisamos de saber que vários registos são o mesmo cliente? Precisamos de uma visão combinada para análise? Precisamos de decidir que valores têm autoridade e devolvê-los a outros sistemas? Ou queremos um sistema central a criar os dados mestres para todos? Requisitos muito diferentes, arquiteturas muito diferentes.
Registry: diga-me quem é quem
Seção intitulada “Registry: diga-me quem é quem ”O padrão mais leve. Um registry (um registo central de identidades) não substitui as fontes. O ERP mantém o seu cliente, o Salesforce a sua conta, a faturação o seu cliente, e o registry descobre que esses registos representam a mesma entidade: a conta Salesforce 001…, o cliente do ERP SAP-43821 e o cliente da faturação BILL-9127 pertencem a um cliente. As fontes ficam onde estão e não são sobrescritas. Agora «mostre-me 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, a faturação «R. Principal, 123, sala 200». O registry sabe que pertencem uns aos outros. Não decide qual deve mudar. Associar não é gerir dados mestres.
Na minha experiência, o registry é a norma em projetos Salesforce, seguido da consolidação e da coexistência; o MDM centralizado puro é raro. O registry é comum porque não é invasivo. Não reprojeta cada sistema operacional antes de obter valor. O Salesforce continua a fazer o que faz, o ERP continua a fazer o que faz, e acrescenta uma camada de identidade. É uma mudança muito menor do que dizer a cada sistema «já não controla os dados de cliente; é este novo sistema central que os controla».
O registry responde: que registos pertencem à mesma entidade?
Consolidação: junte os dados
Seção intitulada “Consolidação: junte os dados ”A consolidação pega em dados de várias fontes e combina-os 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, a faturação os pagamentos, e o negócio consegue finalmente analisar o cliente entre sistemas. As fontes continuam a existir e podem continuar a ter 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 se tornar a sua autoridade operacional.
Registry e consolidação são fáceis de confundir. A diferença é o que fica centralizado: o registry centraliza a identidade («estes pertencem uns aos outros»); a consolidação centraliza mais dos dados («junte os atributos para os podermos usar»). Nenhum dos dois diz «este sistema central é agora o mestre e todas as aplicações têm de aceitar os seus valores».
A consolidação junta os dados sem tirar a propriedade às 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 a viver em vários sistemas operacionais, mas o processo de MDM decide o valor mestre e publica-o de volta. O Salesforce, o ERP e a faturação têm, cada um, uma denominação social diferente; o processo de MDM determina a governada e distribui-a aos três. Os sistemas coexistem, mas convergem para o valor mestre.
É uma forma muito mais forte de MDM. Não está a dizer «estes pertencem uns aos outros»; está a dizer «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 nos dois sentidos, tratamento de erros e governação, porque alguém tem de decidir porque é que um valor ganha.
A coexistência não se limita a associar os registos. Decide os valores mestres e envia-os 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 o seu próprio cliente e o MDM reconciliá-los depois, cria o cliente governado no mestre, e depois envia-o ao Salesforce, ao ERP e à faturação. Governação muito forte, e mudança muito significativa: os processos existentes criam os seus próprios clientes, os utilizadores têm os 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 é 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 associações | 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 na tabela, a camada de dados mestres ganha mais autoridade, e a organização normalmente tem de mudar mais.
Conhecimento para o exame. Conheça os quatro estilos de implementação de MDM: registry (associa identidades; as fontes ficam com os seus dados), consolidação (junta os dados, normalmente para análise), coexistência (decide os valores mestres e publica-os de volta para as fontes) e centralizado (o mestre cria os dados; as fontes consomem-nos).
Por isso não existe «centralizado é o mais maduro, toda a gente devia lá chegar». Escolha o padrão mais leve que resolve o problema. Precisa de saber que registos pertencem uns aos outros? Pense em registry. Uma visão combinada para análise? Consolidação. Valores governados sincronizados de volta para vários sistemas operacionais? Coexistência. Um processo a criar e controlar os dados mestres para todos? Centralizado.
Onde encaixa o Data 360?
Seção intitulada “Onde encaixa o Data 360? ”O Data 360 constrói perfis unificados a partir de muitas fontes, o que soa bastante a MDM, e de facto resolve parte do problema. A sua resolução de identidade faz corresponder os perfis de origem numa identidade unificada e mantém as associações aos registos de origem (Data 360 Architecture (opens in a new tab), em inglês). Isso põe-no mais perto de um registry. 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 registo empresarial 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 ”Também vai ouvir falar de modelo de dados canónico. A Conta do Salesforce, o parceiro de negócio do ERP e o cliente da faturação mapeiam-se todos para um conceito empresarial acordado, Cliente, com identificadores e atributos acordados, para que cada integração não precise de 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 a como representamos isto de forma consistente? O MDM responde a como identificamos, governamos e gerimos isto como dado mestre entre sistemas? Mapeie os três sistemas perfeitamente numa forma de Cliente, e o Salesforce continua a dizer Rua Principal, 123 enquanto o ERP diz 125. Resolveu a estrutura, não a autoridade. Harmonizar e gerir 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 ”Por isso «a Steve Trucking precisa de MDM» não é um requisito. Para quê? Parceiros retalhistas, centros de distribuição, equipas, camiões, Destinatários são domínios diferentes, com autoridades diferentes: os Parceiros retalhistas governados no Salesforce e no ERP financeiro, a identidade dos camiõ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, os atributos podem ter autoridades diferentes. Por isso não desenhe uma caixa rotulada MDM no meio do diagrama e dê o assunto por resolvido. Pergunte o que a caixa faz.
O estilo também muda a integração. O registry precisa de associações de identidade; a consolidação, de fluxos de entrada fiáveis; a coexistência, de dados nos dois sentidos; o centralizado, de distribuição a partir do mestre mais controlos 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 denominação social e o ERP a rejeita? É por isso que a coexistência e o centralizado não são «registry com mais funcionalidades». Trazem responsabilidades operacionais diferentes.
MDM é uma decisão de negócio
Seção intitulada “MDM é uma decisão de negócio ”O ponto mais importante: o MDM não é, no fundo, uma decisão de tecnologia. É uma decisão sobre autoridade. Quem cria o cliente, quem o pode alterar, quem decide que valor ganha, que sistemas o têm de aceitar, o que acontece quando discordam. Uma ferramenta pode implementar essas decisões; não pode pôr a organização de acordo com elas. É por isso que um projeto de MDM pode ter uma tecnologia excelente e mesmo assim fracassar: a equipa técnica resolveu a correspondência, e o negócio nunca resolveu a propriedade.
A lição geral que aprendi da forma mais 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 tem dois ERPs, pergunto como 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 associações de identidade, de dados combinados, de valores mestres devolvidos ou de criação central.
- Que padrão serve cada domínio de dados, em vez de um padrão para a empresa inteira.
- Quanta autoridade recebe a camada de dados mestres, e que sistemas têm de aceitar as suas decisões.
- Se é preciso um modelo canónico, 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 puser uma caixa de MDM num diagrama, pergunte o que ela faz. Sabe que registos pertencem uns aos outros? Combina os seus dados? Decide que valores ganham? Devolve essas decisões? Cria os dados, à partida? As respostas dizem que arquitetura tem realmente, 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.