Las cuatro formas de gestionar datos maestros
También en 28 idiomas
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Français (Canada) · Deutsch (Schweiz)
Módulo 2 de 6 del capítulo Datos maestros e identidad, capítulo 6 del curso Data Architect. Cada módulo se sostiene por sí solo. Anterior: Una fuente de verdad por atributo · Siguiente: Emparejar, fusionar y la supervivencia
La pregunta que responde este módulo: ¿Cómo gestionan las organizaciones sus datos maestros, y qué estilo encaja?
El módulo 1 dijo que la autoridad se asigna atributo por atributo. Ahora: ¿qué hacemos cuando esos atributos viven en varios sistemas a la vez? Información del cliente en Salesforce, en el ERP, en facturación, en soporte, quizá en Data 360, quizá en un almacén de datos, cada uno con su propia versión. Ese es el problema que intenta resolver la gestión de datos maestros (MDM), y el MDM no es una sola arquitectura. Oirás hablar de cuatro patrones: registro, consolidación, coexistencia y centralizado. No son ajustes de un producto. Son cuatro respuestas a una sola pregunta: ¿cuánta autoridad tiene la capa de datos maestros?
Empieza por el problema, no por el producto
Sección titulada «Empieza por el problema, no por el producto »La gente oye MDM y sale a comprar un producto de MDM. Yo empezaría por el problema. ¿Solo necesitamos saber que varios registros son el mismo cliente? ¿Necesitamos una vista combinada para análisis? ¿Necesitamos decidir qué valores tienen la autoridad y devolverlos a otros sistemas? ¿O queremos que un sistema central cree los datos maestros para todos? Requisitos muy distintos, arquitecturas muy distintas.
Registro: dime quién es quién
Sección titulada «Registro: dime quién es quién »El patrón más ligero. Un registro (registry) no reemplaza las fuentes. El ERP conserva su cliente, Salesforce su cuenta, facturación su cliente, y el registro determina que estos registros representan la misma entidad: la cuenta de Salesforce 001…, el cliente del ERP SAP-43821 y el cliente de facturación BILL-9127 pertenecen a un solo cliente. Las fuentes se quedan donde están y no se sobrescriben. Ahora “muéstrame todo lo que sabemos de este cliente” tiene respuesta.
Pero fíjate en lo que un registro no responde. Salesforce dice 123 Main Street, el ERP 125, facturación “123 Main St., Suite 200”. El registro sabe que van juntos. No decide cuál debería cambiar. Vincular no es gestionar como maestro.
Según mi experiencia, el registro es lo habitual en los proyectos de Salesforce, seguido de la consolidación y la coexistencia; el MDM centralizado puro es raro. El registro es común porque no es invasivo. No rediseñas cada sistema operativo antes de obtener valor. Salesforce sigue haciendo lo que hace, el ERP sigue haciendo lo que hace, y añades una capa de identidad. Es un cambio mucho menor que decirle a cada sistema: “ya no controlas los datos del cliente; ahora los controla este nuevo sistema central”.
El registro responde: ¿qué registros pertenecen a la misma entidad?
Consolidación: reúne los datos
Sección titulada «Consolidación: reúne los datos »La consolidación toma datos de varias fuentes y los combina en una representación central, para informes, análisis, segmentación e inteligencia de clientes. Un almacén de datos es el ejemplo conocido: Salesforce envía el cliente, el ERP los datos financieros, facturación los pagos, y por fin el negocio puede analizar al cliente entre sistemas. Las fuentes siguen existiendo y pueden seguir teniendo la autoridad. La dirección importa: los datos fluyen hacia el sistema consolidado, que normalmente no devuelve cambios gestionados como maestros. Una imagen mejor del cliente, sin convertirse en su autoridad operativa.
El registro y la consolidación se confunden con facilidad. La diferencia está en qué se centraliza: el registro centraliza la identidad (“estos van juntos”); la consolidación centraliza más de los datos (“reúne los atributos para que podamos usarlos”). Ninguno de los dos dice “este sistema central es ahora el maestro y todas las aplicaciones deben aceptar sus valores”.
La consolidación reúne los datos sin quitarles la propiedad a las fuentes.
Coexistencia: decide y devuélvelo
Sección titulada «Coexistencia: decide y devuélvelo »En la coexistencia, la capa de datos maestros recibe autoridad real. Los datos siguen viviendo en varios sistemas operativos, pero el proceso de MDM decide el valor maestro y lo vuelve a publicar. Salesforce, el ERP y facturación tienen cada uno un nombre legal distinto; el proceso de MDM determina el gobernado y lo distribuye a los tres. Los sistemas coexisten, pero convergen en el valor maestro.
Es una forma de MDM mucho más fuerte. No dice “estos van juntos”; dice “para este atributo, este es el valor que usa la empresa”. Eso requiere más que emparejar: reglas de negocio, dueños, supervivencia, integración en dos sentidos, manejo de errores y gobierno de datos, porque alguien tiene que decidir por qué gana un valor.
La coexistencia no se limita a vincular los registros. Decide los valores maestros y los devuelve.
Centralizado: el maestro crea la verdad
Sección titulada «Centralizado: el maestro crea la verdad »El patrón más fuerte. En el MDM centralizado, los datos maestros gobernados se crean y se mantienen en el maestro central y se distribuyen a todos los demás. En lugar de que cada sistema cree su propio cliente y el MDM los reconcilie después, creas el cliente gobernado en el maestro y luego lo envías a Salesforce, al ERP y a facturación. Un gobierno muy fuerte, y un cambio muy grande: los procesos existentes crean sus propios clientes, los usuarios tienen sus flujos de trabajo, las integraciones suponen la creación local, y puede que las unidades de negocio ni siquiera se pongan de acuerdo sobre qué es un cliente. Por eso es raro en los entornos de Salesforce que veo. Puede ser lo correcto. Es una decisión mucho más grande que instalar una herramienta.
El MDM centralizado traslada la creación y la autoridad al maestro.
Los cuatro lado a lado
Sección titulada «Los cuatro lado a lado »| Estilo | Qué se centraliza | ¿Siguen las fuentes? | ¿Devuelve los valores gobernados? |
|---|---|---|---|
| Registro | Identidad y vínculos | Sí | Normalmente no |
| Consolidación | Identidad más datos combinados | Sí | Normalmente no |
| Coexistencia | Identidad, datos y decisiones de datos maestros | Sí | Sí |
| Centralizado | Creación y autoridad | Sí, como consumidores | Sí |
Bajando por la tabla, la capa de datos maestros recibe más autoridad, y la organización normalmente tiene que cambiar más.
Conocimiento para el examen. Conoce los cuatro estilos de implementación de MDM: registro (vincula identidades; las fuentes conservan sus datos), consolidación (reúne los datos, normalmente para análisis), coexistencia (decide los valores maestros y los vuelve a publicar en las fuentes) y centralizado (el maestro crea los datos; las fuentes los consumen).
Así que no existe un “lo centralizado es lo más maduro, así que todos deberían llegar ahí”. Elige el patrón más ligero que resuelva el problema. ¿Necesitas saber que unos registros van juntos? Piensa en un registro. ¿Una vista combinada para análisis? Consolidación. ¿Valores gobernados sincronizados de vuelta en varios sistemas operativos? Coexistencia. ¿Un solo proceso que crea y controla los datos maestros para todos? Centralizado.
¿Dónde encaja Data 360?
Sección titulada «¿Dónde encaja Data 360? »Data 360 construye perfiles unificados a partir de muchas fuentes, lo que se parece mucho al MDM, y sí resuelve parte del problema. Su resolución de identidades empareja perfiles de origen en una identidad unificada y conserva los vínculos con los registros de origen (Data 360 Architecture (opens in a new tab), en inglés). Eso lo acerca más a un registro. También puede mostrar valores reconciliados en el perfil unificado. Pero eso no lo convierte en un sistema centralizado de golden records que reescribe las fuentes. Una vista unificada no es automáticamente un registro maestro de la empresa. El módulo 4 trata por completo de esa diferencia.
Un modelo común no es una verdad común
Sección titulada «Un modelo común no es una verdad común »También oirás hablar del modelo de datos canónico. El Account de Salesforce, el business partner del ERP y el cliente de facturación se mapean a un único concepto empresarial acordado, Customer, con identificadores y atributos acordados, para que cada integración no tenga que entender la forma de cada uno de los demás sistemas. El modelo de datos de Data 360 es un ejemplo de armonizar fuentes en conceptos comunes. Pero un modelo canónico responde ¿cómo representamos esto de forma coherente? El MDM responde ¿cómo lo identificamos, lo gobernamos y lo gestionamos como maestro entre sistemas? Mapea los tres sistemas perfectamente a una sola forma de Customer, y Salesforce sigue diciendo 123 Main Street mientras el ERP dice 125. Resolviste la estructura, no la autoridad. Armonizar y gestionar como maestro no son intercambiables.
Un negocio, varios patrones
Sección titulada «Un negocio, varios patrones »Así que “Steve Trucking necesita MDM” no es un requisito. ¿Para qué? Socios minoristas (Retail Partners), centros de distribución, equipos, camiones y destinatarios (Recipients) son dominios distintos con autoridades distintas: los socios minoristas gobernados en Salesforce y en el ERP de finanzas, la identidad del camión desde FleetLink, cada destinatario aportado por un socio para cada entrega. Dominios distintos pueden adoptar patrones distintos, y dentro de un dominio, los atributos pueden tener autoridades distintas. Así que no dibujes una caja con la etiqueta MDM en medio del diagrama para darlo por resuelto. Pregunta qué hace la caja.
El estilo también cambia la integración. El registro necesita vínculos de identidad; la consolidación, flujos de entrada fiables; la coexistencia, datos en las dos direcciones; el centralizado, distribución desde el maestro más controles que impidan que otros sistemas creen una verdad rival. A medida que crece la autoridad, crece la coordinación, y también el manejo de fallos: ¿qué pasa si el MDM cambia el nombre legal y el ERP lo rechaza? Por eso la coexistencia y el centralizado no son “un registro con más funciones”. Conllevan responsabilidades operativas distintas.
El MDM es una decisión de negocio
Sección titulada «El MDM es una decisión de negocio »Lo más importante: en el fondo, el MDM no es una decisión tecnológica. Es una decisión sobre la autoridad. Quién crea el cliente, quién puede cambiarlo, quién decide qué valor gana, qué sistemas deben aceptarlo, qué pasa cuando no coinciden. Una herramienta puede implementar esas decisiones; no puede hacer que la organización se ponga de acuerdo en ellas. Por eso un proyecto de MDM puede tener una tecnología excelente y aun así fracasar: el equipo técnico resolvió el emparejamiento, y el negocio nunca resolvió quién es dueño.
La lección general que aprendí a la fuerza: cuando varios sistemas gestionan como maestros los mismos datos, Salesforce no puede reconciliar aquello en lo que ellos no se ponen de acuerdo. Cuando una empresa usa dos ERP, pregunto cómo los mantienen sincronizados. Si ellos no pueden, Salesforce tampoco. El módulo 5 cuenta esa historia (Un cliente, dos ERP).
Lo que decide aquí un arquitecto
Sección titulada «Lo que decide aquí un arquitecto »- Si el problema necesita vínculos de identidad, datos combinados, valores maestros devueltos o creación central.
- Qué patrón encaja con cada dominio de datos, en lugar de un patrón para toda la empresa.
- Cuánta autoridad recibe la capa de datos maestros, y qué sistemas deben aceptar sus decisiones.
- Si hace falta un modelo canónico, sin confundir la armonización con la autoridad.
- Cómo el patrón elegido cambia la dirección de la integración, los dueños y el manejo de fallos.
Cuando alguien ponga una caja de MDM en un diagrama, pregunta qué hace. ¿Sabe qué registros van juntos? ¿Combina sus datos? ¿Decide qué valores ganan? ¿Devuelve esas decisiones? ¿Crea los datos desde el principio? Las respuestas te dicen qué arquitectura tienes de verdad, y dónde vive la autoridad.
Explora
Sección titulada «Explora »- Salesforce Architects, Data 360 Architecture (opens in a new tab) (en inglés), consultado el 2026-10-14.