Salesforce es un sistema entre muchos

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

La pregunta que responde este módulo: ¿Por qué un arquitecto de datos dibuja lo que rodea a la organización antes de diseñar la organización?

Cuando enseño a candidatos a CTA, la tarea después del primer día es siempre la misma. Lee el escenario. Empieza el panorama de sistemas desde un lienzo en blanco. Solo entonces haz un primer intento con el modelo de datos. No los objetos, no las integraciones en detalle: el panorama. Quiero ver lo que rodea a Salesforce antes de decidir qué pertenece dentro.

Es un cambio de perspectiva para muchos profesionales de Salesforce. Si has pasado tu carrera como administrador o desarrollador, Salesforce es naturalmente el centro de tu mundo. Abres Setup, creas objetos, construyes flujos, escribes Apex e integras otros sistemas en Salesforce. Todo parece empezar por la organización. Un arquitecto tiene que alejar la cámara, porque en una empresa Salesforce es un sistema entre muchos, y muy a menudo no es el que es dueño de los datos.

Dibuja primero el panorama

El capítulo 2 construyó el modelo lógico, y el capítulo 3 preguntó cómo vive en Salesforce. Ahora voy a hacer el problema más grande. Antes de decidir de qué debería ser dueño Salesforce, quiero entender la empresa que lo rodea. ¿Qué sistemas existen ya? ¿Dónde se crean los clientes, se definen los productos, se inician los pedidos, se generan las facturas? ¿Dónde vive la identidad? ¿Dónde ocurre la analítica, dónde se guardan los documentos, dónde está el historial? ¿Qué sistemas necesitan los datos de Salesforce, y de cuáles depende Salesforce?

Esas preguntas cambian la arquitectura. Así que empiezo desde un lienzo en blanco, pongo a Salesforce en el centro y dibujo todo lo que lo rodea. El módulo 4 muestra exactamente cómo lo dispongo. Por ahora, la lección es simplemente: no diseñes la organización antes de entender el mundo en el que tiene que vivir.

A menudo Salesforce no es el sistema de registro

Toma una empresa muy común: Salesforce más un ERP, un sistema de planificación de recursos empresariales como SAP u Oracle, que lleva las finanzas, los productos, el inventario, las compras y el cumplimiento de pedidos. Ahora haz una pregunta sencilla: ¿dónde vive el cliente?

Podría ser Salesforce, el ERP o ambos, y ahí es donde se pone interesante. Los vendedores pueden trabajar los prospectos como cuentas en Salesforce, mientras que el ERP emite el número de cliente oficial cuando se convierten en clientes que pagan. ¿Productos y precios? Probablemente el ERP. ¿Inventario? Casi nunca Salesforce. Los pedidos podrían capturarse en Salesforce y cumplirse en el ERP; las facturas vienen del ERP; el servicio vive en Salesforce; la analítica se reparte entre los informes de Salesforce y un almacén de datos. De pronto, nuestro bonito modelo de datos de Salesforce no es el modelo de datos de la empresa. Es una parte de él.

La integración que veo una y otra vez

La integración más común que veo es así: los clientes, los productos y los precios entran en Salesforce desde el ERP, y los pedidos salen. Cambia el ERP por SAP, Oracle o cualquier otro; la forma es la misma. El ERP es dueño del golden record del cliente y del producto, así que esos flujos vienen de la derecha, hacia Salesforce. Ventas cierra el trato en Salesforce, así que el pedido empieza ahí y vuelve al ERP para que se cumpla, se facture y se contabilice.

Esos flujos no son solo integraciones. Me dicen dónde cree la empresa que vive la verdad.

Las flechas de un solo sentido me ponen nervioso

Cada vez que veo una integración que solo tiene un flujo, empiezo a preocuparme. A alto nivel, alguien dibuja una sola flecha: pedidos de Salesforce al ERP. Bien. Ahora mira más a fondo. ¿Cómo puedo enviar un pedido al ERP si no conozco sus clientes, sus productos ni sus precios? El pedido tiene que estar ligado a un cliente que el ERP ya tiene, y cada línea tiene que ser un SKU que el ERP ya vende. No puedo enviar una partida de un producto que no existe del otro lado. Así que, antes de que esa flecha de pedidos pueda funcionar, tienen que existir flujos de vuelta, en el sentido contrario.

Esa es la pregunta que le hago a cada flecha: ¿de qué depende este flujo? La flecha de alto nivel que ves suele necesitar flujos de vuelta que todavía no has dibujado.

Mira aún más a fondo y encontrarás el viaje de vuelta. Salesforce envía un pedido. ¿Y luego? ¿Se aceptó o se rechazó? ¿Se envió, se envió en parte, se canceló? ¿Se facturó? ¿Alguien en Salesforce necesita saberlo? Quizá no. Pero alguien debería haberlo preguntado. Si no vuelve nada, perfecto. Dime por qué.

La empresa no llegó toda de golpe

Los panoramas se complican en parte porque nadie los construyó todos de una vez. Los datos han llegado en oleadas. Primero los archivos: registros de formato fijo, luego archivos delimitados como CSV. Luego las bases de datos relacionales para los datos operativos. Luego los almacenes de datos para juntarlo todo y analizarlo. Luego las bases de datos NoSQL para documentos, pares clave-valor y grafos que no caben bien en tablas. Luego los lagos de datos (data lakes) para cantidades enormes de datos sin procesar y semiestructurados, y los lakehouses que combinan los dos. Los flujos de eventos, como Kafka o el bus de eventos de Salesforce, mueven los datos a medida que ocurren en lugar de en lotes nocturnos. Y ahora la federación, en la que los datos no tienen que copiarse a un solo lugar antes de que otra plataforma pueda usarlos.

La tecnología no es todavía lo importante. Esto sí: la nueva oleada rara vez hace desaparecer la anterior. Entra en una gran empresa y las encontrarás todas a la vez: bases de datos relacionales, el ERP, Salesforce, un almacén de datos, un lago, envíos por SFTP, API, flujos de eventos, la hoja de cálculo que alguien sigue enviando por correo cada viernes, y el sistema que todos temen tocar porque la persona que lo construyó se jubiló hace seis años. Esa es la empresa que estás diseñando, no la del folleto del producto.

Distintos sistemas existen por distintas razones

Por eso nunca empiezo con “¿cómo metemos todos los datos en Salesforce?”. ¿Por qué querría tenerlos todos ahí? Salesforce puede ser el mejor lugar para que la gente de ventas y de servicio trabaje con los clientes. Eso no lo convierte en el sistema de finanzas, el almacén de datos de la empresa, el almacén de telemetría, el archivo de documentos, ni en el hogar de cada clic, cada lectura de GPS y cada transacción histórica que la empresa haya producido.

El capítulo 3 preguntó ¿dónde deberían vivir estos datos? para una organización. A nivel de empresa, la misma pregunta se hace más grande: a veces Salesforce es dueño de los datos, a veces guarda una copia, a veces solo una referencia, y a veces no debería tenerlos en absoluto.

El núcleo, fuera del núcleo e Hyperforce

Hay otra frontera que entender: ni siquiera “Salesforce” es un solo entorno de ejecución y una sola base de datos. En el capítulo 3, en el núcleo (on core) significaba dónde están los datos: en tu escritorio, en los propios objetos de la organización. Aquí las mismas palabras describen dónde se ejecuta un producto. Oirás a los arquitectos usar los dos sentidos.

Históricamente, el entorno Core alojaba la mayor parte de la plataforma. Hoy Salesforce describe una plataforma de cientos de servicios independientes basados en metadatos, en la que Core sigue siendo el único sistema de registro de los metadatos de la aplicación (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab), en inglés). Por eso oirás a los arquitectos decir que una capacidad se ejecuta en el núcleo (on core) o fuera del núcleo (off core).

Esto importaba mucho antes de que la plataforma se dividiera en servicios. Cuando le pregunto a una clase por qué Salesforce compró SteelBrick para las cotizaciones en lugar de Apttus, la respuesta que busco es sencilla: SteelBrick estaba construido 100% en el núcleo. Los flujos y los triggers viven en el núcleo, así que un producto construido ahí obtiene con él los metadatos, las personalizaciones y la automatización de la plataforma. Ese producto de cotizaciones ha dado paso desde entonces a Revenue Cloud, pero la lección no. Luego está lo que está cerca del núcleo (near-core), y Data 360 es el ejemplo que uso. Data 360 no es el núcleo. Su tenant está fuera del núcleo: los datos y los mecanismos que los procesan se ejecutan en su propio lakehouse, junto a la base de datos relacional de la organización y no dentro de ella (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab), en inglés). Pero las pantallas que usas para configurarlo y controlarlo se muestran en el núcleo, en la organización. Así que la forma más precisa en que puedo decirlo es: se gestiona en el núcleo y se aloja fuera del núcleo. Ninguno de los datos ni del procesamiento se ejecuta realmente en Core; la interfaz en Core controla el tenant que está fuera del núcleo. Y luego, por supuesto, está todo lo que está fuera del núcleo porque no es Salesforce en absoluto.

Me importa menos memorizar qué producto se ejecuta dónde este año, porque eso cambia, que el hábito: una frontera puede afectar el movimiento de datos, la latencia, la identidad, la integración y la residencia de los datos. Así que no supongas que, porque un producto dice Salesforce, sus datos están justo al lado de tus registros de cuenta. Mira la arquitectura real.

Luego está Hyperforce: la infraestructura de Salesforce construida para la nube pública y definida como código, en lugar de sus centros de datos propios tradicionales, que da a los clientes más opciones sobre dónde residen sus datos (Salesforce Hyperforce: General Information and FAQ (opens in a new tab), en inglés). Eso importa, y el módulo 5 vuelve a ello. Pero la arquitectura de infraestructura no es arquitectura de datos de la empresa. Mover una organización a la nube pública no te dice quién es dueño del cliente, dónde vive el inventario, dónde se ejecuta la analítica ni qué datos pueden cruzar una frontera. Hyperforce puede dar forma a algunas de esas decisiones, sobre todo la residencia. No reemplaza conocer el panorama.

El panorama va antes que la caja

Así que este es el hábito. Alguien te da un escenario. No empieces a construir la solución de Salesforce. Primero encuentra los sistemas: el ERP, el proveedor de identidad, el almacén de datos, la plataforma de integración, los sistemas de los socios, los canales de los clientes, los repositorios de documentos. Luego encuentra los datos que se mueven entre ellos: clientes, productos, pedidos, facturas, documentos, eventos, identidades. Luego pregunta quién es dueño de cada uno. Solo entonces decide qué pertenece a Salesforce. Si no, estás diseñando una caja sin saber con qué se conecta.

Click to enlarge

Paso 1 de 3: la organización que diseñamos, sola. Desde aquí parece el mundo entero.

Click to enlarge

Paso 2 de 3: aleja la vista. Salesforce es un sistema entre muchos (el módulo 4 enseña esta disposición).

Click to enlarge

Paso 3 de 3: las primeras flechas. Clientes, productos y precios que entran desde el ERP, pedidos que salen: dicen dónde cree la empresa que vive la verdad.

El panorama cambia el modelo de datos

Por eso le importa a un arquitecto de datos. El capítulo 2 dice que el cliente es una entidad importante. Bien. Luego el panorama dice que el ERP es la referencia para el cliente. Eso cambia el modelo físico. Salesforce puede seguir guardando una cuenta local, porque la gente la usa todos los días, pero ahora necesitamos el identificador del ERP como ID externo; necesitamos saber qué campos puede cambiar Salesforce (marco los campos del ERP con un prefijo erp_, como veremos en el módulo 3); con qué rapidez llegan los cambios del ERP; si Salesforce puede crear un cliente antes de que el ERP lo sepa; y qué pasa cuando los dos no coinciden. No son preguntas de integración para más adelante. Son preguntas de arquitectura de datos, y el panorama las dejó al descubierto.

Así es como muerde uno de ellos. Un vendedor convierte un prospecto de una gran empresa de bebidas, crea la cuenta, gana el trato y el cliente pasa al ERP. Pero la compañía lleva años haciendo negocios con esa empresa de bebidas, y el ERP ya la tiene. Ahora hay dos. ¿Debería el vendedor haber podido crear esa cuenta en primer lugar? Los capítulos 5 y 6 vuelven a esto; el panorama es donde lo ves venir.

Lo que decide aquí un arquitecto

• Qué sistemas rodean a Salesforce, y qué rol cumple cada uno.
• Qué sistema es dueño de cada tipo importante de dato, antes de decidir cuánto conserva Salesforce.
• Qué entra en Salesforce, qué sale y qué vuelve.
• De qué datos debería ser dueño Salesforce, cuáles debería copiar, referenciar, federar, archivar o dejar en paz.
• Qué fronteras de plataforma y de infraestructura importan, en lugar de suponer que todo lo que lleva la marca Salesforce vive en un solo lugar.

El paso de desarrollador a arquitecto a menudo no consiste en aprender otra función. Consiste en aprender cuándo dejar de mirar Salesforce: alejar la cámara, seguir los datos, encontrar quién es dueño de la verdad, y luego volver y decidir cuál debería ser el trabajo de Salesforce.

Explora

• Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (opens in a new tab) (en inglés), consultado el 2026-10-14.
• Ayuda de Salesforce, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab) (en inglés), consultado el 2026-10-14.