Los sistemas alrededor de Salesforce

🌐 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 3 de 6 del capítulo Entender los datos de la empresa, capítulo 4 del curso Data Architect. Cada módulo se sostiene por sí solo. Anterior: Los tipos de datos de la empresa · Siguiente: Dibuja el panorama de sistemas

La pregunta que responde este módulo: ¿Qué rodea a Salesforce, y qué rol cumple cada sistema?

El módulo anterior clasificó los datos. Ahora quiero ponerlos en algún lugar, y aquí es donde los arquitectos de Salesforce se meten en problemas. Conocemos Salesforce, así que los datos de clientes son la cuenta, los datos de pedidos son el pedido, los documentos son Archivos, la analítica son los informes. Pero la empresa no compró Salesforce para reemplazar todo lo demás que tiene. Puede haber un ERP que lleva las finanzas y el cumplimiento de pedidos, un almacén de datos con años de historial, una plataforma de integración, un proveedor de identidad, sistemas de socios, una plataforma de eventos, una plataforma de MDM y Data 360 conectando varios de ellos. El trabajo no es memorizar tecnologías. Es entender qué trabajo tiene cada sistema.

No empieces por el nombre del producto

“Tenemos SAP” no me dice lo suficiente. Tampoco Snowflake, MuleSoft, Tableau ni Data 360. Quiero saber qué hace ese sistema en esta arquitectura: de qué datos es dueño, qué lee, qué cambia, quién lo usa, qué depende de él, qué pasa cuando está caído. Dos empresas pueden tener exactamente los mismos productos y arquitecturas completamente distintas.

Así que etiqueto los sistemas por su rol. Cuatro roles cubren casi todo:

• Sistema de registro: donde se mantiene la versión de referencia de algo.
• Sistema de interacción: donde la gente hace el trabajo.
• Sistema de consulta: adonde va un sistema a buscar información que necesita pero de la que no es dueño.
• Sistema de conocimiento: donde los datos se juntan para medir, analizar y predecir.

Una plataforma puede cumplir varios roles, y los roles cambian según los datos. Salesforce puede ser el sistema de registro de los casos, el sistema de interacción de los agentes de servicio y un consumidor de los datos de producto de los que es dueño el ERP. Así que cuando alguien dice “Salesforce es nuestro sistema de registro”, termina la frase: ¿sistema de registro de qué?

El ERP: el back office tiene gravedad

El ERP es el sistema que encontrarás junto a Salesforce con más frecuencia, llevando las finanzas, el inventario, las compras, el cumplimiento de pedidos y la facturación. El patrón del módulo 1 (clientes y productos que entran, pedidos que salen) significa que el ERP es dueño de los productos, pero los vendedores igual los necesitan en Salesforce. Bien: tráelos. Pero copiar los datos no transfiere la propiedad. Una copia no es autoridad.

Mi posición: los datos que son propiedad del ERP se leen localmente y se escriben bajo control. Los usuarios de Salesforce tienen los datos donde trabajan, pero Salesforce no puede cambiar aquello de lo que es dueño el ERP. Y lo hago visible en el esquema: los campos del ERP llevan un prefijo erp_, como erp_Product_Number__c, para que cualquiera que lea el objeto sepa quién es dueño de cada campo y tenga cuidado al cambiarlo. El prefijo no hace cumplir nada; eso lo hacen los permisos, la validación y el patrón de integración. Comunica la intención, y es el mapa de autoridad hecho visible.

El almacén de datos, el lago y el lakehouse

Los sistemas operativos hacen funcionar el negocio; los sistemas analíticos ayudan a entenderlo. “Muéstrame mis oportunidades abiertas” es un informe de Salesforce. “Muéstrame cinco años de ventas, cumplimiento, devoluciones, casos, inventario y finanzas en todos los canales” es otro problema.

Te encontrarás con tres tipos de almacén analítico. Un almacén de datos (data warehouse) guarda datos estructurados preparados para el análisis. Un lago de datos (data lake) guarda muchos más datos en más formas, a menudo sin procesar. Un lakehouse combina los dos: almacenamiento al estilo de un lago con análisis al estilo de un almacén. Conócelos, porque aparecen en los panoramas. Pero mi experiencia es que los lakehouses y la malla de datos (data mesh) siguen siendo un nicho en los proyectos de Salesforce. El panorama típico es CRM, ERP, un almacén de datos y una capa de integración, con otras plataformas donde el negocio de verdad las necesita. Aprende la arquitectura; no persigas el vocabulario.

La analítica vive donde viven los datos

Esta es una de mis posiciones más firmes: dónde vive la analítica depende de dónde viven los datos. Si el informe solo necesita cuentas, oportunidades y vendedores, todo está en el núcleo: informes y tableros estándar. Luego el negocio pide agregar las facturas del ERP. Luego el costo del producto. Luego cinco años de pedidos del almacén de datos. Luego la actividad del sitio web. En algún momento, arrastrar todo eso al CRM operativo solo para hacer informes deja de tener sentido. Cuando intervienen otros almacenes de datos, se vuelve necesaria una plataforma de analítica: Tableau (incluido Tableau Next, construido sobre Data 360), o CRM Analytics donde ya se usa. Es esencial cuando los datos de Salesforce se combinan con un almacén de datos. El requisito no solo se complicó; el panorama cambió dónde debería responderse la pregunta. Así que nunca empiezo por “¿qué herramienta de analítica?”. Empiezo por ¿dónde están los datos?

A los candidatos a CTA les pregunto lo mismo: “¿Cuál de mis diagramas resuelve esto de maravilla? El panorama”. Si todo está en el núcleo, usa informes. Si tienes datos en otros repositorios, quiero ver una plataforma de analítica. El panorama responde la pregunta de los informes antes de que nadie abra un generador de informes. (Los nombres de los productos cambian; el capítulo de Data 360 cubre dónde está hoy la analítica de Salesforce).

MDM: ¿quién es realmente este cliente?

Ahora supón que la información de los clientes vive en Salesforce, el ERP, el comercio electrónico, una plataforma de fidelización y un sistema de socios, y cada uno cree que sabe quién es el cliente. Ahí entra la gestión de datos maestros (MDM): establecer y gobernar la identidad de referencia de los datos clave entre sistemas. Pero el MDM no es “una base de datos maestra de clientes”. Las preguntas difíciles son qué sistema puede crear el cliente, de qué atributos es dueño cada sistema, cómo se encuentran los duplicados, qué identificador sobrevive y qué pasa cuando los sistemas no coinciden. El capítulo 6 trata justamente de eso. Aquí, reconoce el rol: si existe una plataforma de MDM, puede ser una autoridad crítica entre Salesforce y el resto de la empresa.

La capa de integración y los eventos

Conecta cada sistema directamente con todos los demás y el panorama se convierte rápido en un plato de espaguetis. Por eso las empresas tienen una capa de integración: un ESB (bus de servicios empresarial) o un iPaaS (plataforma de integración como servicio). MuleSoft es el que más encontrarás en los panoramas de Salesforce. Hace de intermediario, para que cada aplicación no tenga que entender a todas las demás.

Pero una caja de MuleSoft en el medio no hace buena la integración. Igual quiero saber qué pasa por ella y qué no, quién transforma los datos, quién es dueño del contrato, qué pasa cuando el destino está caído, si es síncrona o asíncrona y cómo sabemos que un mensaje tuvo éxito. El curso Integration Architect profundiza; aquí, reconócela como un rol propio.

Y no toda integración es el sistema A llamando al sistema B. A veces pasa algo (se crea un pedido, una entrega cambia de estado, un camión entra en una región), se publica un evento y responde quien esté interesado. Los eventos en movimiento también tienen infraestructura: las propias capacidades de eventos de Salesforce, un bus de eventos de la empresa, otra mensajería. Dibuja los mecanismos que transportan los datos, no solo las bases de datos.

El sistema que olvidan los desarrolladores: la identidad

Hay una caja que siempre quiero en el panorama y en la que los desarrolladores rara vez piensan: el proveedor de identidad. Los desarrolladores entran directamente a sus sandboxes con un nombre de usuario y una contraseña, así que la identidad es invisible durante la construcción. Luego llegan las pruebas de aceptación o producción y, de repente, está el inicio de sesión único de la empresa para los empleados, quizá un segundo proveedor para los socios, el inicio de sesión social para los clientes. La identidad siempre fue parte de la arquitectura. Solo que el desarrollador todavía no la veía.

Un proveedor de identidad (IdP) es el sistema que autentica a un usuario y establece la identidad en la que confía Salesforce. Pertenece al panorama desde el primer día, aunque se configure más adelante en el proceso de despliegue, porque quién puede entrar decide quién puede llegar a los datos.

También hay un matiz práctico: la configuración de identidad se puede desplegar, pero no del todo. La configuración del inicio de sesión único SAML y los proveedores de autenticación son tipos de la Metadata API, así que viajan por el proceso de despliegue (SamlSsoConfig (opens in a new tab), en inglés). Pero los secretos de consumidor de los proveedores de autenticación ya no se devuelven en las respuestas de la Metadata API (Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab), en inglés), y los certificados suelen ser distintos en cada entorno. Planifica para las partes que viajan y las que no.

Click to enlarge

Lee el panorama por papeles, no por logotipos: de qué es dueño cada sistema, qué lee o qué decide.

¿Dónde se ubica Data 360?

Data 360 plantea una bonita pregunta de dibujo. Lo pongo a la derecha, debajo del ESB o de MuleSoft. La razón son sus conexiones: los usuarios nunca se conectan a él directamente, mientras que él se conecta directamente con muchos sistemas de back-end. Así que pertenece a la fontanería de los datos, donde esas líneas se mantienen cortas, no afuera con los usuarios. Dibújalo como otra pantalla en la que la gente inicia sesión y estarás contando la historia equivocada.

Los administradores y los equipos de datos sí abren las pantallas de Data 360, pero esas pantallas están en la organización, en el núcleo. El tenant que hace el trabajo, sus datos y su procesamiento, se ejecuta fuera del núcleo. Por eso digo que está cerca del núcleo (near-core): se gestiona en el núcleo y se aloja fuera del núcleo (el módulo 1 explica los términos). El dibujo sigue al tenant: va con la fontanería, con una línea de vuelta a la organización que lo gestiona.

Lo que hace, en palabras de Salesforce, incluye el zero copy: una tecnología de federación de datos que permite a una empresa acceder a los datos y consultarlos sin copiarlos (Zero Copy (opens in a new tab), en inglés). Las capacidades y los conectores cambian rápido, así que el capítulo de Data 360 los cubre como corresponde en lugar de convertir este módulo en un recorrido por el producto.

Lee el panorama como responsabilidades

Cuando mires un panorama, no leas los logotipos; lee las responsabilidades. El ERP: ¿de qué es dueño? El almacén de datos: ¿qué preguntas responde? La plataforma de integración: ¿qué mueve? El IdP: ¿a quién autentica? El MDM: ¿qué identidad gobierna? Data 360: ¿qué conecta, y para qué? Salesforce: ¿de qué es realmente responsable? Una vez que puedes responder eso, las cajas significan algo, y las flechas entre ellas se vuelven mucho más interesantes. A continuación, las dibujamos de forma deliberada.

Lo que decide aquí un arquitecto

• Qué rol cumple cada sistema, más allá del nombre de su producto.
• Qué sistema es la referencia para cada conjunto de datos importante, y dónde Salesforce guarda solo una copia local.
• Si los datos que son propiedad del ERP están disponibles en Salesforce con las escrituras controladas, y cómo se ve esa propiedad en el esquema.
• Dónde pertenece la analítica, según dónde viven los datos.
• Dónde se ubican en el panorama la identidad, la integración, los eventos y la autoridad sobre los datos maestros.

Un panorama con diez rectángulos no es arquitectura; es inventario. La arquitectura empieza cuando puedes señalar cada rectángulo y decir por qué está ahí, de qué es dueño, quién lo usa, qué necesita Salesforce de él y qué se rompe si malinterpretas su rol.

Explora

• Salesforce Developers, Metadata API Developer Guide, SamlSsoConfig (opens in a new tab) (en inglés), consultado el 2026-10-14.
• Ayuda de Salesforce, notas de la versión Winter ‘23, Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab) (en inglés), consultado el 2026-10-14.
• Salesforce, Zero Copy (opens in a new tab) (página del producto, en inglés), consultado el 2026-10-14.
• Zhamak Dehghani, How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh (opens in a new tab) (en inglés), martinfowler.com, 2019.