Entender los datos de la empresa
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)

Guía de estudio del capítulo 4 del curso Data Architect. Lee primero los seis módulos; esta página te ayuda a comprobar lo que te quedó.
Sobre esta guía de estudio. Está construida solo con el contenido de este curso y con la lista de objetivos publicada en la guía del examen de Salesforce. Nunca se basa en preguntas reales del examen, y no pretende saber qué hay en el examen. Si ya hiciste el examen, por favor no me envíes preguntas: el acuerdo de certificación prohíbe compartirlas, y memorizar respuestas es, de todos modos, la forma equivocada de convertirse en arquitecto.
La guía del examen dice que no evalúa conceptos de bases de datos ajenos a Salesforce, y la mayor parte de este capítulo trata de la empresa que rodea a Salesforce. Así que, como en el capítulo 1, esta lista de verificación dice qué objetivos apoya cada punto. Pero no te la saltes: muchos escenarios del examen empiezan con un ERP, un almacén de datos o una segunda organización, y la respuesta depende de quién es dueño de los datos.
Para el examen
Sección titulada «Para el examen »Márcalos a medida que avanzas. Cada uno enlaza con el lugar donde se enseña.
Quién es dueño de los datos (apoya SDM-2, SDM-3 y el capítulo de Datos maestros)
- Puedo decir qué sistema es el sistema de registro de cada tipo de dato, y termino la frase: sistema de registro ¿de qué? (A menudo Salesforce no es el sistema de registro, No empieces por el nombre del producto)
- Conozco el patrón habitual: clientes, productos y precios que entran desde el ERP, pedidos que salen, y sé que la flecha de los pedidos depende de las demás; luego pregunto por el viaje de regreso. (La integración que veo una y otra vez, Las flechas de un solo sentido me ponen nervioso)
- Les hago tres preguntas a los datos maestros: ¿dónde se crean, dónde se editan y dónde se referencian? (Las cuatro preguntas detrás de las categorías)
- Sé que una copia no es autoridad: los datos que son propiedad del ERP se leen localmente y se escriben bajo control, con su identificador del ERP guardado como ID externo. (El ERP: el back office tiene gravedad, El panorama cambia el modelo de datos)
Los tipos de datos y sus cargas de trabajo (apoya DM-1, LDV-1 y MDM-4)
- Puedo distinguir los datos maestros, de referencia, transaccionales, metadatos, analíticos y no estructurados, y lo que cada uno significa para dónde vive. (Empieza por el tipo, no por el objeto)
- Sé que los datos de referencia son pequeños, pero son donde se esconden los supuestos de integración (
Delivered,Complete,D). (Datos de referencia) - Puedo distinguir las cargas de trabajo operativas (OLTP), analíticas (OLAP) y de streaming: la organización hace funcionar el negocio, los almacenes de datos y los lagos lo analizan. (El tipo es solo la mitad de la pregunta)
- Distingo lo síncrono (esperar en la puerta), lo asíncrono (seguir y ocuparte cuando vuelve) y lo por lotes (cada hora, cada pocas horas, cada día), sé cuándo basta un lote, y sé que el tiempo real tiene un costo. (¿Qué tan rápido tiene que moverse?)
- Hago las cuatro preguntas a cada conjunto de datos: quién es su dueño, qué tan rápido cambia, qué tan grande se vuelve y cuál es su ciclo de vida. (Las cuatro preguntas detrás de las categorías)
Los sistemas alrededor de Salesforce (apoya SDM-3, LDV-3 y los capítulos de integración)
- Conozco los cuatro roles de los sistemas: registro, interacción, consulta y conocimiento. (No empieces por el nombre del producto)
- Sé que dónde vive la analítica depende de dónde viven los datos: informes del núcleo cuando todo está en Salesforce; una plataforma de analítica (Tableau, incluido Tableau Next, o CRM Analytics donde se use) o el almacén de datos cuando intervienen otros almacenes. (La analítica vive donde viven los datos)
- Sé qué son un almacén de datos, un lago y un lakehouse, y el rol del MDM, un ESB o iPaaS y los eventos. (El almacén de datos, el lago y el lakehouse, La capa de integración y los eventos)
- Pongo el proveedor de identidad en el panorama desde el primer día, y sé que la configuración de SSO se despliega pero los secretos y los certificados no viajan; en el panorama es un certificado compartido (confianza), no una llamada, porque el inicio de sesión pasa por el navegador. (El sistema que olvidan los desarrolladores: la identidad)
- Sé que Data 360 está cerca del núcleo (se administra en el núcleo y se aloja fuera del núcleo), y que su zero copy permite consultar los datos sin copiarlos. (¿Dónde se ubica Data 360?, El núcleo, fuera del núcleo e Hyperforce)
Organizaciones y alojamiento (apoya SDM-4)
- Empiezo con una organización y busco una frontera real (residencia, regulación, separación legal, un modelo operativo distinto, una adquisición) antes de agregar otra. (Empieza con una organización, Busca fronteras reales)
- Sé lo que cuestan varias organizaciones: informes globales, datos maestros, integración, identidad y despliegues, cada uno multiplicado. (Vuelve a recorrer las flechas)
- Sé que Hyperforce permite elegir la región donde residen los datos de una organización (no el proveedor de nube), pero no promete que todos los servicios se queden ahí; y que el RGPD no exige por sí solo una organización separada: fija reglas para los datos personales que salen de la UE, y una empresa puede elegir una organización europea para cumplirlas. (El alojamiento es parte del dibujo, Cuando Europa tiene su propia organización)
Dibujar y leer un panorama (apoya todos los escenarios)
- Puedo dibujar un panorama: las personas a la izquierda, Salesforce en el centro con sus comunidades tocándolo por debajo, la identidad arriba, la integración y el back office a la derecha, Data 360 debajo de la capa de integración, los canales abajo, los datos que entran y salen abajo a la derecha. (La disposición del panorama según Steve)
- En un panorama, una flecha empieza en el sistema que abre la conexión y su etiqueta dice qué se mueve y en qué sentido; en un diagrama de flujo de datos, las flechas siguen a los datos. Dos flujos son dos flechas. (Ahora dibuja las flechas)
- Para cada flecha sé lo que maneja el cliente y lo que define el servidor: dónde, autenticación, protocolo y contrato, carga útil, tiempos, rastreo, errores. Una Named Credential y su External Credential cuando Salesforce hace la llamada saliente; una External Client App y un usuario de integración solo de API cuando algo llama a Salesforce. (Cada flecha necesita un mecanismo)
- Cuento antes de dibujar las flechas: el volumen va en el inventario y determina el mecanismo, y hasta puede cambiar hacia dónde apunta la flecha. (Pon los ceros en el inventario)
- Dibujo un carril solo cuando un proceso tiene más de uno o dos intercambios de ida y vuelta. (Las flechas en el panorama, las conversaciones en un carril)
Más allá del examen
Sección titulada «Más allá del examen »El examen es el piso, no el techo. Estos son los hábitos de este capítulo que necesita un arquitecto, los pregunte o no el examen.
- Dibuja el panorama antes de diseñar la organización. Empieza desde un lienzo en blanco.
- Aleja la cámara. Salesforce es un sistema entre muchos.
- La nueva oleada rara vez hace desaparecer la anterior. Diseña la empresa que existe, no la del folleto.
- Lee el panorama como responsabilidades, no como logotipos.
- Las flechas de un solo sentido me ponen nervioso. ¿De qué depende este flujo y qué vuelve?
- Cada flecha necesita un mecanismo. “Enviar y olvidar” no es una respuesta.
- Las flechas en el panorama, las conversaciones en un carril.
- Cuenta antes de dibujar las flechas. Los ceros van en el inventario, y eligen el mecanismo.
- Dibuja el estado actual antes de arreglarlo: la hoja de cálculo, el envío por SFTP, el sistema “que vamos a retirar”.
- Marca un estado actual con honestidad: rojo para un proceso malo, discontinuo para lo que se hace a mano, puntos rojos para lo que falta. Cada línea roja es un requisito esperando a que lo escriban.
- Dos flujos, dos flechas. Una flecha de doble punta es solo para un conector.
- No hagas de abogado. Pregunta qué requisito concreto estás cumpliendo, y tradúcelo con quienes son sus dueños.
- Separado no es lo mismo que simple.
Palabras que conviene conocer
Sección titulada «Palabras que conviene conocer »| Término | En una línea |
|---|---|
| Panorama de sistemas | Los sistemas alrededor de Salesforce, las personas que los usan y los flujos importantes entre ellos |
| Sistema de registro | Donde se guarda la versión de referencia de un tipo de dato |
| Sistema de interacción | Donde la gente hace el trabajo |
| Sistema de consulta | Donde un sistema busca 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 |
| ERP | El sistema de back office para las finanzas, los productos, el inventario, las compras y el cumplimiento de pedidos |
| Datos maestros | Las cosas duraderas alrededor de las que funciona un negocio: clientes, productos, ubicaciones |
| Datos de referencia | El vocabulario compartido que clasifica otros datos: códigos, estados, categorías |
| Datos transaccionales | Registros de lo que pasó: pedidos, entregas, pagos, casos |
| Datos analíticos | Datos derivados de otros datos para medir y comparar |
| Datos no estructurados | Documentos, imágenes, audio, video, transcripciones |
| Almacén de datos / lago / lakehouse | Almacén analítico estructurado / almacén sin procesar a escala / una mezcla de los dos |
| ESB / iPaaS | Una capa de integración que hace de intermediaria entre sistemas |
| OLTP / OLAP | Trabajo operativo sobre unos pocos registros a la vez / análisis sobre muchos |
| Cerca del núcleo (near-core) | Se administra en el núcleo, se aloja fuera del núcleo: Data 360 |
| Named Credential / External Credential | Donde Salesforce guarda un endpoint saliente / su autenticación |
| External Client App | Cómo se autoriza a un sistema externo a llamar a Salesforce |
| Estado actual | El panorama tal como es hoy, antes del diseño; marcado con lo que está mal |
| Proveedor de identidad (IdP) | El sistema que autentica a los usuarios y establece la identidad en la que confía Salesforce |
| Síncrono / asíncrono / por lotes | Esperar la respuesta / seguir y ocuparse de ella cuando llega / mover los datos en grupo según una programación |
| Hyperforce | Salesforce sobre infraestructura de nube pública, con elección de región |
| Zero copy | Consultar los datos donde viven, sin copiarlos |
Ponte a prueba
Sección titulada «Ponte a prueba »Escenarios cortos al estilo del curso. Decide tu respuesta antes de abrirla.
1. Los vendedores trabajan las cuentas en Salesforce, pero el ERP emite el número de cliente oficial cuando compran. Salesforce envía los pedidos al ERP. ¿Qué necesitas diseñar?
Quién es dueño del cliente en cada etapa; el número del ERP como ID externo en la cuenta; qué campos puede cambiar Salesforce; qué tan rápido llegan los cambios del ERP; y qué vuelve después de enviar un pedido (aceptado, rechazado, enviado, facturado). Vuelve a leer El panorama cambia el modelo de datos.
2. La dirección quiere cinco años de puntualidad por región, cruzados con finanzas. ¿Lo construyes con informes de Salesforce?
Probablemente no. Es una carga de trabajo analítica entre varios almacenes, así que pertenece adonde se juntan los datos: el almacén de datos, con CRM Analytics o Tableau encima. Dónde vive la analítica depende de dónde viven los datos. Vuelve a leer La analítica vive donde viven los datos.
3. Una empresa opera en 30 países y pide una organización por país. ¿Qué preguntas?
Qué requisito viene con cada país: almacenamiento, procesamiento, transferencia entre fronteras, contratos, otro alojamiento. Sin una frontera real, empieza con una organización, porque cada organización extra multiplica los informes, los datos maestros, la integración, la identidad y los despliegues. Vuelve a leer La geografía no es automáticamente una estrategia de organizaciones.
4. Los camiones envían 200.000 lecturas de GPS al día. ¿Debería Salesforce guardarlas todas?
Probablemente no. Son datos de streaming: el despachador necesita la posición actual, mientras que el historial y las tendencias pertenecen a una plataforma construida para ese volumen. Cuenta los ceros (más de 70 millones al año) y separa “¿dónde está ahora?” de “¿qué pasó el trimestre pasado?”. Vuelve a leer El tipo es solo la mitad de la pregunta.
5. Los equipos trabajan sus paradas en Salesforce, pero las rutas se arman en una herramienta de despacho heredada, y nada conecta las dos. ¿Cómo dibujas el día de hoy?
Tal como es, marcado como un estado actual: las rutas que se vuelven a teclear en Salesforce y las paradas completadas que se vuelven a teclear de vuelta, en discontinuo porque lo hacen personas y en rojo porque está mal. No dibujes la integración que te gustaría que existiera; cada línea roja se convierte en un requisito para el diseño. Vuelve a leer Marca lo que está mal y RouteDesk sigue ahí.
6. Alguien dice que la ley de privacidad europea exige una organización separada. ¿Cómo respondes?
Ni lo aceptes a ciegas ni lo descartes. El RGPD no exige por sí solo una organización separada; fija reglas para los datos personales, incluidas las transferencias fuera de la UE. Pregunta qué requisito concreto cumple (almacenamiento, procesamiento, transferencia, acceso de soporte, un contrato, una política), y luego trabaja con privacidad, el área legal y seguridad para convertirlo en arquitectura. Vuelve a leer No hagas de abogado y Cuando Europa tiene su propia organización.
7. Salesforce envía pedidos a la API del ERP. ¿Qué lado se encarga de los reintentos, y dónde guarda Salesforce el secreto?
Salesforce es el cliente: abre la conexión, ve el viaje completo de ida y vuelta y es el único lado que puede reintentar. Una Named Credential guarda el endpoint, y su External Credential, la autenticación. El ERP, el servidor, define el contrato y valida lo que entra. Vuelve a leer Cada flecha necesita un mecanismo.
8. Una integración envía hoy un par de registros por minuto, y el negocio espera decenas de miles por hora el año que viene. ¿Cambia la flecha?
Posiblemente su mecanismo, y hasta su dirección. Unos pocos registros por minuto pueden ser un callout desde Salesforce; muchos más pueden significar publicar eventos a los que se suscribe el otro sistema, así que la flecha empieza en el otro extremo; millones durante la noche son un lote. Conoce los recuentos antes de elegir. Vuelve a leer Pon los ceros en el inventario.
Explora
Sección titulada «Explora »- Guía del examen Salesforce Certified Platform Data Architect (opens in a new tab), Ayuda de Salesforce (en inglés, consultado el 2026-09-25): la lista oficial de objetivos y sus pesos. Revisa siempre la versión actual antes de reservar el examen.
