Una fuente de verdad por atributo

🌐 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)

Imagen generada con IA

Traducido con IA. Aún no revisado por la comunidad. Leer en inglés

Módulo 1 de 6 del capítulo Datos maestros e identidad, capítulo 6 del curso Data Architect. Cada módulo se sostiene por sí solo. Siguiente: Las cuatro formas de gestionar datos maestros

La pregunta que responde este módulo: ¿Qué significa de verdad “única fuente de verdad”?

Hay una frase que oigo constantemente: “Necesitamos una única fuente de verdad.” De acuerdo. ¿Para qué? ¿Para el cliente? Eso no es lo bastante concreto. Toma una cuenta. ¿Quién es dueño del nombre del cliente, la dirección de facturación, el límite de crédito, el ejecutivo de cuenta, el nivel de soporte, las preferencias de marketing? Esas respuestas no apuntan al mismo sistema. El ERP puede controlar el nombre legal, la dirección de facturación y el estado de crédito; Salesforce, el responsable de la relación y los atributos de ventas; otra plataforma, el consentimiento. Así que cuando alguien me dice “Salesforce es nuestra única fuente de verdad para el cliente”, mi siguiente pregunta es: ¿qué verdad?

La verdad pertenece a un atributo

El primer principio de los datos maestros es este: la autoridad se asigna por atributo, no por registro. Una cuenta puede vivir en Salesforce sin que Salesforce tenga la autoridad sobre cada uno de sus campos. Siete campos en un registro, dos autoridades:

Atributo	Sistema con la autoridad
Nombre legal, dirección de facturación, ID de cliente del ERP, límite de crédito	ERP
Ejecutivo de cuenta, indicador de cuenta estratégica, nivel de éxito	Salesforce

Un registro; la verdad está repartida. Eso es normal. “Sistema de referencia = Salesforce” no lo describe. Un modelo de autoridad sí.

¿Dónde se crea, se edita, se referencia, y con qué rapidez?

Cuando enseño datos maestros, vuelvo siempre a las mismas preguntas para cada dato importante: ¿dónde se crea, dónde se edita, dónde se referencia, y cuál es su latencia de cambio? Ponen la arquitectura al descubierto rápidamente. (Las tres primeras ya las viste en el capítulo 4, al clasificar los tipos de datos; aquí es donde hacen su verdadero trabajo).

Toma un activo. Un cliente pide tres bicicletas. Salesforce tiene la oportunidad y sus productos, y el pedido va al ERP. El ERP lo surte, y ahí es donde se crean los activos: tres bicicletas, tres números de serie, enviados de vuelta a Salesforce. Meses después, el cliente llama por una de ellas, y soporte referencia el activo en un caso. Ahora alguien necesita corregir un atributo. ¿Cuáles puede editar Salesforce, y cuáles pertenecen al ERP que los creó? Y cuando el ERP cambia uno, ¿con qué rapidez necesita enterarse Salesforce? Un activo, cuatro preguntas, y las respuestas no son las mismas para todos los campos.

Supón que el nombre legal se crea en el ERP y se referencia en Salesforce, y un representante de ventas nota que está mal. ¿Debería corregirlo en Salesforce? Si el ERP es dueño del campo, cambiar la copia no arregla nada. En el mejor de los casos, la próxima sincronización lo sobrescribe; en el peor, los dos sistemas ahora no coinciden y nadie sabe en cuál confiar. Si el negocio quiere que el representante inicie la corrección, es distinto: Salesforce ofrece la experiencia, envía una solicitud al ERP, el ERP hace o aprueba el cambio, y el valor con autoridad vuelve. Esa es una arquitectura muy distinta de dejar que Salesforce edite el campo por su cuenta.

La latencia también es parte de la verdad. El ERP cambia el estado de crédito de un cliente a las 10 de la mañana; Salesforce lo sincroniza cada noche; a las 3 de la tarde, un representante mira Salesforce. ¿El valor está mal? Está desactualizado. Si el valor cambia una vez al año y un día de retraso no cuesta nada, cada noche está bien. Si decide si aceptas hoy un pedido de un millón de dólares, no lo está. La autoridad dice de dónde viene la verdad; la latencia dice con qué rapidez los demás deben enterarse de que cambió. Son dos decisiones separadas.

Sistema de referencia, de interacción y de consulta

El vocabulario del capítulo 4 ayuda aquí. Un sistema de registro (system of record) mantiene la versión con autoridad. Un sistema de interacción (system of engagement) es donde la gente trabaja con ella. Un sistema de consulta (system of reference) aporta datos que otro sistema usa pero de los que no es dueño. Salesforce puede ser el sistema de interacción para la relación con el cliente mientras el ERP sigue siendo el sistema de registro para sus atributos legales y financieros. Eso no es una debilidad de la arquitectura; es la arquitectura. El error es fingir que un solo sistema debe ser dueño de todo para que el diagrama se vea más simple.

El golden record híbrido

Eso cambia lo que significa “golden record”. El capítulo 5 presentó la idea al hablar de mantener fuera los datos malos; aquí es el corazón del diseño. La gente se imagina un registro mágico con cada campo gestionado como maestro en un solo lugar. A veces ese es el diseño. En Salesforce, lo que veo más a menudo es un híbrido: una parte de la cuenta se gestiona como maestra en otro lugar y se copia (nombre legal, número de cliente del ERP, dirección de facturación, estado de crédito), y otra parte existe solo porque Salesforce la necesita (ejecutivo de cuenta, estrategia de oportunidades, nivel de éxito, notas de la relación). Los campos del ERP entran para que la gente pueda usarlos. Los campos de Salesforce nunca vuelven, porque al ERP no le importan. Es perfectamente razonable, siempre que todos sepan cuál es cuál.

Haz visible la autoridad

Por eso hago evidente la autoridad externa en el esquema. Si SAP controla un campo, lleva un prefijo: sap_Customer_Number, sap_Credit_Status, sap_Legal_Name. Es la misma idea que el prefijo erp_ del capítulo 4. Usa el nombre del sistema cuando esa autoridad es concreta y estable, y un prefijo genérico cuando el significado importa más que el proveedor de hoy. La idea es que, seis meses después, quien lea el modelo pueda ver: este no es un campo más de Salesforce; otro sistema es dueño de este valor. No hagas que la gente redescubra la autoridad haciendo ingeniería inversa de las integraciones.

Construye un mapa de autoridad

Para los datos maestros importantes, quiero un mapa de autoridad: para cada atributo clave, quién lo crea, quién es dueño de la decisión de negocio, qué sistema tiene la autoridad, y quién o qué puede cambiarlo. Cuatro preguntas distintas:

Atributo	Lo crea	Dueño de negocio	Sistema con la autoridad	Puede cambiarlo
Nombre legal	Finanzas	Finanzas	ERP	El proceso de Finanzas
Límite de crédito	Finanzas	Finanzas	ERP	El equipo de crédito
Ejecutivo de cuenta	Operaciones de ventas	Ventas	Salesforce	La dirección de ventas
Nivel de soporte	Operaciones de servicio	Servicio	Salesforce	La dirección de servicio
Consentimiento	El cliente	Privacidad	Plataforma de consentimiento	El cliente, un proceso aprobado

Fíjate en que el dueño de negocio y el sistema con la autoridad no son lo mismo. Un sistema no es dueño de la política; las personas sí. El sistema guarda y hace cumplir el resultado. Es otra vez el capítulo 5: los dueños fijan la política; los arquitectos la hacen cumplir.

Click to enlarge

Un cliente. Muchos atributos. Una autoridad para cada uno.

La autoridad cambia a lo largo del ciclo de vida

Una representante conoce a un prospecto del que el ERP nunca ha oído hablar y crea la cuenta en Salesforce. En ese momento, Salesforce tiene la autoridad sobre el nombre, la dirección, los contactos y la calificación. El prospecto se convierte en cliente; el ERP crea el cliente oficial y asigna el número de cliente, el nombre legal, la dirección de facturación y el crédito. La autoridad se movió. Salesforce no estaba equivocado antes; cambió el ciclo de vida. Es el patrón de provisional a gobernado del capítulo 5: antes de la conversión, Salesforce es dueño del prospecto; después, el ERP es dueño de los atributos gobernados, y Salesforce sigue siendo dueño de los suyos. Así que “¿qué sistema es dueño de la cuenta?” es una pregunta débil. Pregunta: ¿qué sistema es dueño de este atributo, en este punto del ciclo de vida?

Una copia no es autoridad

Copiamos datos del ERP a Salesforce porque la gente los necesita constantemente. Eso convierte a Salesforce en una copia local cómoda, no en el maestro, y la arquitectura debería comportarse en consecuencia: solo lectura para los usuarios, actualizada por la integración, etiquetada con su origen, cambiada solo mediante una solicitud, y verificada con una reconciliación cuando la copia se desvía. La copia es útil. La autoridad no se ha movido.

La confianza necesita más que un valor

“Dirección de facturación: 123 Main Street.” ¿Deberías confiar en ella? Quiero señales de confianza: de dónde vino, cuándo se confirmó por última vez, qué sistema la aportó, y quién o qué la cambió por última vez: ¿una persona, una integración, un agente? Ahora el ERP dice 123 Main Street, Salesforce dice 125, y un archivo de un socio dice “123 Main St., Suite 200”. ¿Cuál es el correcto? No respondas “usa el más reciente”. Quizá. Pero “el más reciente” es en sí una regla que supone que quien lo cambió último merece ganar. Eso puede ser cierto, o terrible. El módulo 3 se ocupa de esto. La confianza viene de la autoridad y la procedencia, no de encontrar un campo que esté lleno.

Steve Trucking: ¿de quién es la verdad?

Un socio minorista (Retail Partner) envía una entrega, y en esa sola transacción se esconden varias verdades. La referencia de pedido del socio es del socio; Steve Trucking la guarda para emparejar las actualizaciones, pero no se convierte en su maestro. El estado de la entrega (llegada, entregada, instalada, una excepción) es de Steve Trucking; el socio lo recibe, pero recibir un estado no le da al socio la autoridad sobre lo que pasó en el camión. Y el destinatario (Recipient) es el cliente del socio. El socio aporta el nombre, la dirección, el teléfono y las notas de entrega porque Steve Trucking los necesita para entregar. Eso no convierte a Steve Trucking en el maestro de la identidad de esa persona, y esa distinción decide el diseño del destinatario en el checkpoint.

Click to enlarge

Una entrega, dos autoridades.

Dónde viven los datos y quién es dueño de su verdad son preguntas distintas. Salesforce puede guardar el número de cliente del ERP sin ser su dueño; Snowflake puede guardar el estado de la entrega sin ser su maestro operativo; una plataforma de datos de clientes puede unificar identidades sin ser dueña de cada atributo. Un agente puede leer los tres, y eso desde luego no le permite decidir cuál es el verdadero.

Más allá del examen: lo que cambia la IA. Los agentes convierten la autoridad por atributo en una regla de ejecución. Una persona ve una dirección de facturación equivocada y sabe: “eso viene de SAP; no debería cambiarlo aquí”. Un agente al que se le pide “actualiza la dirección de facturación del cliente” no lo sabrá a menos que diseñemos para ello. Necesita el mismo mapa de autoridad que tiene el arquitecto: tener acceso a un campo no lo convierte en el lugar correcto donde escribir.

Lo que decide aquí un arquitecto

• Qué sistema tiene la autoridad sobre cada atributo importante, en lugar de un sistema para todo un registro.
• Dónde se crea, se edita y se referencia cada atributo, y con qué rapidez deben viajar sus cambios.
• Quién fija la política de cada atributo, y qué personas, integraciones o agentes pueden cambiarlo.
• Cómo se refleja la autoridad externa en el modelo: prefijos en los nombres, permisos, comportamiento de la integración.
• Cómo se desplaza la autoridad a lo largo del ciclo de vida, como cuando un prospecto se convierte en un cliente gobernado por el ERP.

Una única fuente de verdad no significa una org, un ERP, una plataforma de MDM o un registro gigante. Significa que, para cada dato gobernado, la arquitectura puede decir dónde está el valor con autoridad, y cada uno de los demás sistemas sabe cómo comportarse gracias a ello. Eso no es una única fuente de verdad. Es una arquitectura de la verdad.

Explora

• Salesforce Architects, Data 360 Architecture (opens in a new tab) (en inglés), consultado el 2026-10-14.