Registry, Consolidation, Coexistence… os nomes variam, mas a dúvida por trás é sempre a mesma: onde o dado vai” viver” e como ele vai “circular”. E aqui vale um alerta: essa decisão não é só técnica. Ela define o quanto a sua iniciativa vai ser viável, ou não. Na prática, essas três abordagens representam níveis diferentes de ambição (e de impacto na organização).
 

O modelo mais leve é o Registry.

Nele, você não tenta centralizar o dado de fato. Cada sistema continua com sua própria versão, e o MDM atua como uma camada que conecta essas versões. Ele identifica quais registros representam a mesma entidade e cria uma visão consolidada “virtual”.

Funciona bem quando o problema principal é falta de visibilidade. Você quer saber que aquele cliente no CRM é o mesmo do ERP, mas não quer ou não pode mexer nos sistemas agora.

O ganho vem rápido, porque a mudança é pequena. Mas também tem um limite claro: você não resolve o problema na origem. Os dados continuam inconsistentes, só que agora você consegue enxergar isso melhor.
 

O segundo modelo, Consolidation, já dá um passo além.

Aqui, você traz os dados para um repositório central, trata qualidade, resolve duplicidade e constrói um Golden Record de forma mais estruturada. Esse dado consolidado passa a ser a referência, principalmente para analytics e relatórios.

É um modelo que costuma funcionar muito bem quando o objetivo é melhorar consistência de informação, especialmente em empresas com muitos sistemas e muita divergência entre eles. Mas ainda existe uma limitação importante: os sistemas de origem continuam existindo com suas próprias versões. Ou seja, você melhora bastante a leitura do dado, mas nem sempre muda a operação.
 

E é aí que entra o modelo mais completo e mais desafiador: Coexistence.

Nesse cenário, o MDM deixa de ser só um ponto de consolidação e passa a ser parte ativa da operação. Ele não só cria o Golden Record, como também distribui essa informação de volta para os sistemas e, em alguns casos, passa a ser o ponto de criação e manutenção do dado. É aqui que a ideia de “single source of truth” realmente se materializa.

Só que isso vem com um custo. Não só técnico, mas organizacional. Você está mexendo em processos, responsabilidades e, muitas vezes, na autonomia das áreas. Por isso, o erro mais comum é tentar começar por esse modelo.

A intenção é boa, já ir direto para o “ideal”. Mas, na prática, isso costuma gerar projetos longos, complexos e com dificuldade de mostrar valor no curto prazo.
 

Uma abordagem mais pragmática costuma funcionar melhor.

Começar com algo mais próximo de um Registry ou uma Consolidação leve, resolver um problema concreto (como duplicidade de cliente ou inconsistência de produto), gerar resultado visível, e então evoluir.

Com o tempo, conforme a organização ganha confiança e maturidade, faz sentido aumentar o nível de centralização e controle. Nem toda empresa precisa chegar no modelo mais avançado. E tudo bem.

O ponto principal aqui é que arquitetura de MDM não é sobre escolher o modelo “mais completo”. É sobre escolher o modelo que a sua organização consegue absorver agora, sem travar a operação.

Porque, no fim, o melhor desenho não é o mais sofisticado. É o que sai do papel, melhora o dado e continua funcionando depois que o projeto acaba.