Dibuja el panorama antes que la organización

🌐 También en 28 idiomas

English · 日本語 · 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 · Español (México) · Français (Canada) · Deutsch (Schweiz)

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

Capítulo 4 de Data Architect, Parte 1: Convertirse en Data Architect. Anterior: Arquitectura de datos de Salesforce.

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. Luego, y solo luego, haz un primer intento con el modelo de datos.

A la gente le sorprende el orden. Somos arquitectos de datos; ¿no deberíamos empezar por el modelo de datos? Esta es la razón por la que no lo hago. Si dibujo primero el modelo de datos, ya he decidido qué pertenece a Salesforce. Si dibujo primero el panorama, puedo ver todo lo que debería dar forma a esa decisión: el ERP que es dueño de los clientes y los productos, el almacén de datos que responde las preguntas a cinco años, el proveedor de identidad que decide quién entra, el socio que envía un archivo cada tarde, el sistema heredado que todos dicen que se va a retirar.

Los capítulos 2 y 3 diseñaron la organización: cómo debería ser el modelo y cómo vive en Salesforce. Este capítulo aleja la cámara y dibuja lo que rodea a la organización, antes de diseñarla. Salesforce es un sistema entre muchos, y muy a menudo no es el que es dueño de los datos.

Imagen generada con IA.

Las ideas de este capítulo

• El panorama va primero. Encuentra los sistemas, luego los datos que se mueven entre ellos, luego quién es dueño de cada pieza. Solo entonces decide cuál es el trabajo de Salesforce.
• Una flecha depende de otras flechas. Los pedidos que salen hacia el ERP necesitan que antes hayan entrado los clientes, los productos y los precios. Cada vez que veo una integración con un solo flujo, empiezo a preocuparme.
• Los datos vienen en tipos y en cargas de trabajo. Los datos maestros, de referencia, transaccionales, metadatos, analíticos y no estructurados cambian, crecen y se usan de forma distinta; las cargas de trabajo operativas (OLTP), analíticas (OLAP) y de streaming necesitan hogares distintos. La organización hace funcionar el negocio; los almacenes y los lagos de datos lo analizan.
• Los sistemas tienen roles, no solo logotipos. Registro, interacción, referencia, conocimiento. “Salesforce es nuestro sistema de registro”: ¿de qué?
• Dónde vive la analítica depende de dónde viven los datos. Todo en el núcleo: informes estándar. Datos en otros almacenes: una plataforma de analítica, y el almacén de datos cuando los datos de Salesforce se combinan con él.
• Data 360 está cerca del núcleo (near-core): se gestiona en el núcleo y se aloja fuera del núcleo. Los usuarios nunca se conectan a él, así que va con la fontanería.
• Los datos que son propiedad del ERP se leen localmente y se escriben bajo control, con un prefijo erp_ para que el esquema muestre quién es dueño de cada campo.
• En un panorama, una flecha empieza en el sistema que abre la conexión, y su etiqueta dice qué se mueve y en qué dirección. Dos flujos son dos flechas; una flecha de dos puntas es solo para un conector.
• Cada flecha tiene un cliente y un servidor, y cada uno es dueño de su mitad. Nada de eso va en el panorama, pero cada flecha lo tiene.
• Cuenta antes de dibujar las flechas. Los ceros van en el inventario, y son ellos los que eligen el mecanismo: por lotes, síncrono o por eventos.
• La estrategia de organizaciones es una decisión del panorama, tomada en los primeros minutos: una organización o varias, y dónde se ejecuta.
• Un estado actual muestra lo que está mal. Rojo para un proceso malo, línea discontinua para lo que se hace a mano, puntos rojos para lo que falta.

La disposición del panorama según Steve

Hay muchas formas de dibujar un panorama de sistemas. Esta es la mía, pulida a lo largo de muchos años, y se lee como una frase: las personas a la izquierda llegan a Salesforce en el centro, con la confianza que dan los sistemas de arriba, atendidas por los canales de abajo y conectadas al back office a la derecha.

Dónde	Qué va ahí
Izquierda	Las personas, de arriba abajo: usuarios internos, socios, clientes
Centro	Salesforce, una caja simple, con sus comunidades tocándola por debajo
Arriba	Los proveedores de identidad sobre Salesforce; AppExchange desplazado a la derecha; los sitios web públicos arriba a la izquierda
Derecha	La capa de integración y, después, los sistemas internos: ERP, finanzas, almacén
Debajo de la capa de integración	Data 360, cerca del núcleo, con la fontanería
Abajo	Los canales del cliente: correo electrónico, formularios web, teléfono, mensajería
Abajo a la derecha	Los datos que entran y salen: archivos históricos, cargas de datos, fuentes externas, socios

Los sistemas son tarjetas en zonas tenues y etiquetadas, cada una con un ícono, y una leyenda dice qué significa cada cosa. Detrás del dibujo hay un inventario: para cada conjunto de datos o flujo, su dueño, su volumen, su mecanismo y sus tiempos, su autenticación, y si copiarlo, referenciarlo o federarlo.

Click to enlarge

El panorama del módulo 4, con sus flechas.

El recorrido de este capítulo

Seis módulos, cada uno se sostiene por sí solo.

1. Salesforce es un sistema entre muchos. Por qué el panorama va antes que la caja, la integración que veo una y otra vez y los flujos de vuelta de los que depende, los datos en oleadas, y el núcleo, lo que está cerca del núcleo e Hyperforce.
2. Los tipos de datos de la empresa. Seis tipos; dónde se crean, se editan y se referencian; OLTP y OLAP; tiempo real, casi tiempo real y por lotes; las cuatro preguntas detrás de las categorías.
3. Los sistemas alrededor de Salesforce. Los roles de los sistemas; el ERP, el almacén de datos y el lakehouse; la analítica sigue a los datos; el MDM; la integración y los eventos; el proveedor de identidad que los desarrolladores olvidan; dónde se ubica Data 360.
4. Dibuja el panorama de sistemas. Mi disposición, construida desde un lienzo en blanco; los ceros antes que las flechas; flechas que empiezan en quien inicia la conexión; el cliente y el servidor detrás de cada flecha, en ambos sentidos; carriles para las conversaciones; el inventario detrás del dibujo.
5. La estrategia de organizaciones es una decisión del panorama. Empieza con una organización; qué justifica otra; la región, no el proveedor; una división en AMER y EMEA impulsada por el RGPD; lo que agrega la segunda organización.
6. El panorama de Steve Trucking. Hoy, antes de una implementación como corresponde, marcado: manifiestos que llegan a RouteDesk, rutas que se vuelven a teclear en Salesforce y de vuelta a mano, una isla de datos de GPS, una hoja de cálculo que alimenta a finanzas y 108.000 llamadas de “¿dónde está mi entrega?” al año.

Cuando termines, ponte a prueba con la guía de estudio del capítulo: una lista de verificación para el examen, los hábitos que van más allá, las palabras que conviene conocer y algunas preguntas.

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.
• Cómo funciona cada conexión: qué se mueve, en qué dirección, cómo se autentica, qué tan rápido y qué vuelve.
• Cuántas organizaciones, y dónde se ejecutan, decidido primero, porque todo lo demás en el panorama depende de ello.
• Si el estado actual se entiende lo bastante bien como para diseñar un estado objetivo.

Más allá del examen: el panorama se está convirtiendo en un mapa de agentes. Antes de que un agente pueda responder “¿dónde está mi entrega?”, alguien tiene que saber qué sistema es la referencia para cada dato, qué tan actual es y cómo puede llegar a él el agente. Cada módulo termina con lo que la IA cambia en su parte del dibujo.

Explora

• Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (opens in a new tab) (en inglés), consultado el 2026-10-14.
• Lectura adicional para candidatos a CTA: Salesforce Architects publica su propia guía para hacer diagramas, How to Build Salesforce Diagrams (opens in a new tab) (en inglés).

Siguiente: Calidad y gobierno de datos