La pregunta que responde este módulo: ¿Cómo dibujo un panorama que muestre adónde van los datos?
Dame un escenario nuevo y una pizarra en blanco, y una de las primeras cosas que dibujaré será el panorama de sistemas. No bonito, no cada API, todavía no el modelo de datos. Quiero ver la empresa: quiénes son los usuarios, qué sistemas intervienen, dónde se ubica Salesforce, qué lo rodea, de dónde vienen los datos y adónde van. Y luego quiero recorrer las flechas. Un buen panorama no es un dibujo de cajas. Es una forma de dejar al descubierto las decisiones de arquitectura.
Hago practicar esto a los candidatos a CTA. Lee el escenario y luego empieza a dibujar. No esperes a haberlo resuelto todo en tu cabeza; el dibujo te ayuda a resolverlo. Por eso la tarea después del primer día es empezar el panorama antes de hacer un primer intento con el modelo de datos. Dibuja primero el modelo de datos y ya habrás supuesto qué pertenece a Salesforce. Dibuja primero el panorama y podrás ver los sistemas que deberían dar forma a esa decisión.
Empieza desde arriba y luego profundiza: primero toda la empresa, después el detalle donde importa.
Hay muchas formas de dibujar un panorama de sistemas. Esta es simplemente la mía, una que he ido afinando durante muchos años, y la comparto para que veas cómo armar uno rápido. La uso para cada panorama de Salesforce, 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.
Las personas a la izquierda, de arriba abajo: usuarios internos, socios, clientes. Todavía no cada perfil; lo suficiente para responder ¿quién intenta llegar a esta arquitectura? Cada grupo apunta a por dónde entra: los usuarios internos a Salesforce, los socios a la comunidad de socios, los clientes a la comunidad de clientes. Los sistemas no existen por sí solos. Alguien, o algo, intenta usarlos.
Paso 2 de 6: ¿quién intenta llegar a esta arquitectura?
Salesforce en el centro. Una caja sencilla. No porque Salesforce sea el centro de la empresa (acabamos de pasar tres módulos diciendo que no lo es), sino porque es el sistema alrededor del que estoy diseñando. Es el ancla.
Las comunidades justo debajo, tocándolo. Una comunidad de socios y una comunidad de clientes son puntos de acceso separados, así que tienen sus propias cajas. Pero van pegadas a Salesforce, porque no hace falta ninguna integración para llegar a ellas: funcionan en la misma organización.
Paso 3 de 6: Salesforce en el centro, las comunidades justo debajo.
La identidad arriba. Los proveedores de identidad van arriba, los que olvidan los desarrolladores: uno para los usuarios internos, quizá otro para los socios. Los paquetes de AppExchange también van ahí, corridos a la derecha, porque son capacidades que se traen a la organización y no sistemas de back office que intercambian datos con ella. Los sitios web públicos van arriba a la izquierda.
Paso 4 de 6: la identidad arriba, la caja que olvidan los desarrolladores.
La integración y luego el back office, a la derecha. La capa de integración, un ESB o un iPaaS (o MuleSoft, cuando tiene nombre), es una barra alta justo a la derecha de Salesforce. Los sistemas internos están detrás de ella: los ERP, finanzas, la gestión de pedidos, los sistemas heredados, el almacén de datos. Ahora la página se lee de izquierda a derecha: personas, Salesforce, integración, back office.
Paso 5 de 6: la integración y luego el back office.
Los canales abajo. Todo lo que tiene una línea directa con los clientes: email-to-case, web-to-lead, teléfono, mensajería.
Los datos que entran y salen, abajo a la derecha. Fuentes de datos externas, archivos históricos, cargas de datos.
Data 360 a la derecha, debajo de la capa de integración. Los usuarios nunca se conectan a él, y su tenant se conecta con muchos sistemas de back-end, así que va con la fontanería, donde esas líneas quedan cortas: junto a los sistemas internos, el almacén de datos y los datos de abajo a la derecha. Los equipos de datos sí abren sus pantallas, pero esas pantallas están en la organización: Data 360 está cerca del núcleo (near-core), se administra en el núcleo y se aloja fuera del núcleo (módulo 1). Una línea de vuelta a Salesforce muestra quién lo administra. Dónde pones la caja debería contar la historia de lo que hace.
Nada de esta geometría es sagrado. El valor de una convención es que no reinvento el lenguaje visual cada vez, y que cualquiera que haya visto uno de mis diagramas puede leer el siguiente más rápido.
Mantén la notación simple. Cada sistema es una tarjeta: su nombre, su rol y un ícono pequeño que dice qué tipo de cosa es: un ERP, una base de datos, un proveedor de identidad, un grupo de personas. Las regiones que acabo de describir se dibujan como zonas tenues con etiqueta, para que la disposición misma sea visible. Una leyenda abajo dice qué significa cada ícono y cada línea.
No metas demasiado dentro de una caja. Solo en un panorama muy complicado abro Salesforce en sus partes (Sales Cloud y Service Cloud dentro de la organización, con flechas entre ellas). Y no inventes quince formas a menos que cada una le diga algo al lector. Quiero que alguien mire el panorama treinta segundos y empiece a entender la arquitectura. Lo vistoso no ayuda. Lo claro, sí.
No esperes al diseño detallado para pensar en el volumen. Una flecha que lleva 500 productos por noche y otra que lleva 200.000 lecturas de GPS al día pueden verse exactamente iguales en el panorama. No son el mismo problema. Así que, antes de dibujar una sola flecha, cuenta lo que se mueve. Empieza el inventario detrás del dibujo con los recuentos: una fila por cada conjunto de datos importante, con su volumen. Puede que los ceros nunca aparezcan en las flechas, pero necesitas saber cuándo entras en números altos: miles o millones en una hora, cientos de miles de transacciones, incluso de decenas a cientos de transacciones por segundo.
Esos números determinan el mecanismo. Unos cientos de registros por noche son un lote. Una llamada que alguien espera puede ser síncrona, si el volumen lo permite. Decenas a cientos por segundo pueden necesitar eventos, como los eventos de plataforma, en lugar de una llamada por registro. La flecha se verá igual; el volumen decide qué la transporta, así que regístralo en el inventario, donde se elige el mecanismo.
El mecanismo puede incluso cambiar la dirección de la flecha. Si envías un par de registros por minuto, Salesforce puede simplemente hacer la llamada saliente: la flecha empieza en Salesforce. Si envías muchos más, puede que Salesforce publique eventos en el bus de eventos; el sistema externo se suscribe y llama para recogerlos, así que ahora la flecha empieza en el otro extremo. Más grande todavía, digamos una sincronización nocturna de millones de registros, y es un proceso por lotes. Así que conoce tus recuentos pronto, cuando empiezas a diseñar los mecanismos, porque los recuentos pueden volver a dibujar las flechas.
El volumen importa en dos lugares, por dos razones. En un modelo de datos, lo necesito para vigilar los grandes volúmenes de datos y planificar el archivado; la Parte 2 lo trata a fondo. En un panorama de sistemas, los números grandes del inventario determinan la elección del patrón y del mecanismo de integración. El módulo 6 pone ceros reales en el panorama de Steve Trucking y en su inventario. Con los recuentos en la mano, dibuja las flechas.
Con los sistemas en su lugar, conéctalos, y el panorama se convierte en arquitectura. Una caja es un sistema; la flecha muestra quién inicia la conexión. Empieza en el sistema que abre la conexión y apunta al que llama: de cliente a servidor. La etiqueta dice qué se mueve y en qué sentido.
Esa regla es para los panoramas de sistemas, donde los sistemas hablan con sistemas. En un diagrama de flujo de datos la flecha sigue a los datos, como esperarías. No lleves la regla del panorama a otros diagramas; solo agrega confusión.
Las flechas, agregadas. Cada caja está donde estaba; cada flecha empieza en el sistema que abre la conexión, y su etiqueta dice qué se mueve y en qué sentido.
Así que, si la capa de integración empuja los productos a Salesforce, la flecha va de la capa de integración a Salesforce, con la etiqueta productos que entran. Si Salesforce hace la llamada para traerlos, la flecha empieza en Salesforce, con la misma etiqueta productos que entran. Los mismos datos, otra conversación, y esa diferencia me dice quién necesita las credenciales y quién tiene que manejar el fallo. Salesforce envía el pedido a través de la capa de integración: pedidos que salen. El cumplimiento del ERP vuelve: estado del pedido que entra. Ahora puedo ver quién empieza cada conversación, dónde entran los datos en Salesforce y dónde salen, qué flujos cruzan fronteras, dónde está probablemente la propiedad y dónde necesito preguntar más.
Y recuerda el módulo 1: cada vez que veo un solo flujo, me preocupo. En el nivel alto, una flecha de pedidos que salen depende de flujos de vuelta: clientes que entran, productos que entran, precios. Mira más a fondo y está el viaje de regreso: aceptación, rechazo, estado, un número de factura, una cancelación. Las flechas me dan algo concreto que cuestionar.
Aquí es donde el panorama deja de ser arte de PowerPoint. En el comité de revisión, cualquier flecha puede provocar tres preguntas, y quiero que tengas las respuestas:
¿Cómo se autentica? ¿OAuth, un certificado, una credencial con nombre, otra cosa?
¿Es síncrona o asíncrona? ¿Salesforce espera al ERP, o publica y sigue? ¿Qué tan rápido necesita el resultado el negocio?
¿Cuál es el mecanismo? ¿Una llamada REST, un evento, un archivo, una cola de mensajes, a través de MuleSoft o directo?
Y luego: ¿qué pasa cuando el otro lado está caído? Cada flecha necesita un mecanismo. Si no puedes explicarlo, la línea es decoración.
Y “enviar y olvidar” no es una respuesta. Normalmente significa “no he diseñado lo que pasa después del envío”. ¿Llegó? ¿Se aceptó? ¿Falló? ¿Se reintentará? ¿Quién sabe que está atascado? ¿Y si el mismo mensaje llega dos veces? Nada de eso va en el panorama, que se volvería ilegible. Pero la flecha debería hacerte saber que esas preguntas existen.
Haz zoom en cualquier flecha y hay un cliente y un servidor, y cada uno es dueño de su mitad. El cliente abre la conexión: necesita el endpoint y el puerto, primero obtiene un token del servidor de autenticación, llama con el protocolo y el contrato que define el servidor y elige si espera. Solo el cliente ve el viaje completo de ida y vuelta, así que solo el cliente puede reintentar. El servidor escucha, define el protocolo, el contrato y la carga útil, valida lo que entra y ve solo su propia parte. Cuando dibujo una flecha, ya sé qué extremo es cuál, y eso me dice quién es dueño de cada una de estas preguntas.
Una flecha, vista de cerca: el cliente maneja, el servidor define. Nada de esto va en el panorama, pero cada flecha lo tiene.
Ahora dale la vuelta a la flecha. Cuando el ERP llama a Salesforce, Salesforce es el servidor: define las API, ejecuta su propio servidor de autorización y decide, mediante una External Client App y un usuario de integración, qué puede hacer quien llama. Las mismas preguntas, desde el otro lado.
Aquí es donde los arquitectos arruinan un buen diagrama: hacen que un solo artefacto responda a todo. El panorama recibe nombres de API, cargas útiles, reintentos, colas de errores, transformaciones, cada devolución de llamada, y pronto nadie puede leerlo. No lo hagas. El panorama es la visión general: los sistemas y los flujos importantes entre ellos.
Cuando necesito explicar una interacción, dibujo un segundo diagrama, pero no para cada integración. Si el sistema A le envía algo a B, o incluso le pregunta y recibe una respuesta, la flecha etiquetada basta. Quiero un carril (swim lane) cuando el proceso se convierte en una conversación: A llama a B, B consulta con C, C responde, B crea algo y vuelve a llamar a A, una persona aprueba, otro sistema continúa. Mi regla general: más de uno o dos intercambios de ida y vuelta, y la secuencia tiene su propio carril. Las flechas en el panorama; la conversación en el carril.
Y fíjate en que ahí una flecha significa otra cosa. En el panorama, una flecha es una conexión: quién la abre y qué se mueve. En un carril, cada flecha es un mensaje de una conversación, leído en orden: una solicitud va en un sentido, una respuesta vuelve en el otro, y sigue el siguiente paso.
Cuando el panorama parece casi terminado, recórrelo, flecha por flecha. Del ERP a Salesforce: ¿qué se mueve, quién es su dueño, cómo se autentica, cuál es el mecanismo, síncrono o asíncrono, qué tan actual tiene que estar? Luego la siguiente flecha, y la siguiente. Aquí aparecen los huecos. “Ah, nunca resolvimos cómo envía eso realmente el socio”. “Enviamos los pedidos al ERP, pero no hemos diseñado cómo vuelven los rechazados”. Bien. Lo encontraste en la pizarra y no en producción.
El dibujo tiene que seguir siendo legible, así que los detalles van en el inventario detrás de él. Lo empezaste con los recuentos; ahora termínalo, una fila por cada conjunto de datos o flujo importante:
Columna
Lo que quiero saber
Conjunto de datos
Cliente, producto, pedido, entrega, factura
Tipo
Maestro, de referencia, transaccional, analítico, no estructurado
Dueño
¿Quién es dueño de su significado y su ciclo de vida?
Sistema de registro
¿Dónde está la versión de referencia?
Carga de trabajo
Operativa, analítica, de streaming
Volumen
El Número de Ceros
Organización
¿Qué organización de Salesforce, si hay varias?
Autenticación
¿Cómo establece la confianza la conexión?
Mecanismo y tiempos
API, evento, archivo, federación; síncrono, asíncrono, por lotes
Enfoque
¿Copiarlo, referenciarlo o federarlo?
Ahora hay dos artefactos: el panorama me deja ver la arquitectura, y el inventario me deja interrogarla.
Por eso me gusta este artefacto: me ayuda a pensar. “¿Cómo haremos informes que crucen Salesforce y el ERP?”. Es la pregunta del módulo 3: ¿cuál de mis diagramas resuelve esto de maravilla? El panorama. Si todo está en el núcleo, informes estándar. Si los datos están en el ERP y en el almacén de datos, lo ves de inmediato. “¿Dónde debería mantenerse este atributo de cliente como dato maestro?”. Mira qué sistemas lo usan y cuál es ya dueño del cliente. “¿Necesita Salesforce cada lectura de GPS?”. ¿Quién la produce, quién la consume, cuál es la carga de trabajo? Quizá Salesforce necesita la posición actual y otra plataforma conserva el historial. El panorama no te da la respuesta. Te da la vista correcta del problema.
Una disciplina más. En una empresa existente, dibuja lo que existe, no lo que te gustaría que existiera. La hoja de cálculo que se envía por correo cada viernes: dibújala. El CSV del socio en un servidor SFTP: dibújalo. La integración que se salta el ESB por razones históricas: dibújala. Personas que vuelven a teclear datos entre dos sistemas: muéstralo. No limpies la realidad mientras la documentas. Necesitas el panorama actual antes de diseñar el objetivo, y eso es lo que hacemos con Steve Trucking en el módulo 6.
Más allá del examen: lo que cambia la IA. El panorama se está convirtiendo en un mapa de agentes. Si un agente responde “¿dónde está mi entrega?”, el panorama tiene que decir si la respuesta viene de Salesforce, de un sistema del socio, de la telemática, del ERP o de una mezcla. Los agentes no eliminan las fronteras entre sistemas; hacen todavía más importante saber qué sistema es la referencia y cómo llegar a él con seguridad.
Qué sistemas y poblaciones de usuarios pertenecen al panorama, y cómo su ubicación muestra su rol.
Qué flujos cruzan las fronteras entre sistemas, en qué dirección y qué vuelve.
Cómo se autentica cada conexión, qué mecanismo la transporta y si es síncrona, asíncrona, por lotes o federada.
Cuándo basta una flecha etiquetada y cuándo una interacción necesita su propio carril.
Qué registra el inventario detrás del dibujo: dueño, carga de trabajo, volumen, organización, tiempos, autenticación, y copiar, referenciar o federar.
El panorama no es algo que dibujo cuando la arquitectura ya está hecha. Es la forma en que encuentro la arquitectura. Y cuando creas que está terminado, no lo admires. Recórrelo. Cada flecha que todavía no puedes explicar te muestra dónde está el trabajo.
