Pensar como un arquitecto de datos
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 1 del curso Data Architect. Lee primero los siete 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.
Este capítulo trae menos datos de examen, y es a propósito. Trata de cómo piensa un arquitecto, y ningún objetivo del examen le pertenece solo a él. Pero el examen está hecho de escenarios: un negocio, algunos números, una restricción y varias respuestas que podrían funcionar. Los hábitos de este capítulo son la forma de leer esos escenarios. Por eso la lista de verificación de abajo indica qué objetivo apoya cada punto, en lugar de afirmar que se evalúa directamente.
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.
Leer un escenario como un arquitecto (apoya todos los objetivos)
- Separo el requisito real del diseño con el que llegó (“necesitamos campos Aprobador 2 y Aprobador 3” frente a “necesitamos llevar el seguimiento de cada aprobación”). (No te limites a aceptar el requisito)
- Busco los requisitos implícitos que nadie dijo: propiedad, actualidad, fallo, retención, acceso. (Busca los requisitos implícitos)
- Le pongo números: volumen por día, por año, con crecimiento, y me doy cuenta cuando un cero más cambia la respuesta. (Conoce tus números)
- Entre varias respuestas que funcionan, comparo qué gana y a qué renuncia cada una frente a los requisitos y las restricciones planteados. (Sabe a qué estás renunciando, Las restricciones cambian la respuesta)
- Trato el costo, las licencias y los límites como parte de si una herramienta encaja, no como algo de último momento. (Las nueve preguntas)
El modelo de datos (apoya DM-1)
- Puedo juzgar un modelo según si sostiene el negocio, puede crecer con él y rinde. (Sostener. Crecer. Rendir.)
- Puedo detectar un modelo demasiado plano (Campo 1, Campo 2, Campo 3), normalizado de más o construido sobre el objeto estándar equivocado. (Demasiado plano, demasiado complicado o simplemente equivocado)
- Sé por qué una lista de selección sirve para una lista corta y estable, y una búsqueda para una lista que no deja de crecer o que llega desde una integración. (Muchas formas de resolver el problema)
- Sé que una clave que tiene significado (parte de un nombre, por ejemplo) se rompe cuando ese significado cambia. (Algunas decisiones son baratas de cambiar)
Cambiar lo que ya existe (apoya DM-1 y SDM-2)
- Sé por qué cambiar el tipo de un campo, o hacer obligatorio un campo existente, puede romper cosas más adelante, y por qué la plataforma bloquea un cambio de tipo mientras el código o los flujos hacen referencia al campo. (Cuidado con cambiar el esqueleto)
- Conozco el patrón agrega en lugar de mutar, deja obsoleto en lugar de sorprender, y sé que Field Usage puede marcar un campo como candidato a quedar obsoleto. (Cuidado con cambiar el esqueleto)
- Conozco los datos de principal-detalle detrás de la Prueba de Reversibilidad: el acceso y la propiedad del detalle siguen al principal, eliminar un principal elimina sus detalles, los campos de resumen acumulativo necesitan principal-detalle y una búsqueda solo se convierte en principal-detalle cuando todos los registros tienen un valor. (La Prueba de Reversibilidad, Explora)
Licencias y uso compartido (apoya SDM-1)
- Sé que los usuarios de comunidad de gran volumen (Customer Community entre ellos) no tienen funciones y no usan el modelo de uso compartido, así que su acceso viene de los conjuntos de uso compartido y los grupos de uso compartido, y el uso compartido con Apex no puede llegar a ellos. (Un ejemplo resuelto: el uso compartido con Apex)
El fallo (apoya MIG-1 y los capítulos de integración)
- Sé que “trabajo completado” no es lo mismo que los datos son correctos, y cómo la conciliación encuentra los registros que no llegaron. (Un éxito parcial sigue siendo un fallo que tienes que entender)
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.
- Alguien tiene que sostener el plano. La arquitectura es tomar buenas decisiones con información incompleta y conocer sus consecuencias.
- El modelo de datos es el esqueleto. Todo lo demás se construye sobre él.
- La Prueba de Reversibilidad: ¿qué tan difícil es revertir esto y cuánto dependerá de ello?
- La arquitectura crea gravedad. Lo que encarece el cambio son las dependencias, no el cambio en sí.
- Piensa en el radio de impacto, dentro de Salesforce y en toda la empresa. La arquitectura es tráfico en dos sentidos.
- Escribe por qué: contexto, opciones, decisión, consecuencias, responsable, revisión. Sustituye; no borres.
- ¿La mejor en qué? Una decisión subóptima puede ser parte de una arquitectura óptima, si sabes que la estás tomando.
- Lleva contigo una imagen de lo óptimo, para saber en qué dirección te alejas de ello, y por qué.
- Piensa bien. Piensa rápido. La velocidad viene del pensamiento hecho antes del momento.
- Construye para hoy. Planifica para mañana. Planifica para el fallo. Y usa un 30 % de crecimiento cuando nadie te dé un número.
- Aprende las nueve preguntas, no solo las respuestas.
- La IA es un cohete propulsor. Generar no es juzgar, lo irreversible sigue siendo irreversible y la revisión humana no es una ceremonia. Confía, pero verifica.
Palabras que conviene conocer
Sección titulada «Palabras que conviene conocer »| Término | En una línea |
|---|---|
| Decisión de arquitectura | Una que es difícil de revertir, con mucho dependiendo de ella |
| Prueba de Reversibilidad | ¿Qué tan difícil es revertir esto y cuánto dependerá de ello? |
| Gravedad | Las dependencias que se acumulan alrededor de una decisión con el tiempo |
| Radio de impacto | Todo lo demás que se mueve cuando cambia una decisión |
| Registro de decisiones | Contexto, opciones, decisión, consecuencias, responsable y punto de revisión, en poco espacio |
| Compensación (trade-off) | Lo que gana una opción y a lo que renuncia para conseguirlo |
| Requisito implícito | Algo que el negocio espera sin pedirlo, como la recuperación cuando falla una carga |
| El Número de Ceros de Steve | Un cero más en el volumen puede cambiar toda la arquitectura |
| Conciliación | Comparar lo que debería haber pasado con lo que pasó, registro por registro |
| Dejar obsoleto | Marcar algo como de salida y luego retirarlo de forma deliberada, en lugar de cambiarlo en el mismo lugar |
| Usuario de gran volumen | Un usuario de comunidad (Customer Community entre las licencias) sin función, fuera del modelo de uso compartido |
| Expansión descontrolada del esquema | Objetos y campos que se acumulan porque eran baratos de crear, hasta que nadie diseñó el modelo |
Ponte a prueba
Sección titulada «Ponte a prueba »Escenarios cortos al estilo del curso. Decide tu respuesta antes de abrirla.
1. Un equipo de ventas pide campos Aprobador 2 y Aprobador 3, cada uno con una fecha, en la oportunidad. ¿Qué preguntas y qué podrías construir?
Pregunta por qué, y cuántas aprobaciones puede haber. Si puede haber más de dos o tres, el requisito es llevar el seguimiento de cada aprobación, no agregar campos: un objeto hijo, un registro por aprobación. Vuelve a leer No te limites a aceptar el requisito.
2. Alguien quiere renombrar la etiqueta de un campo, y otra persona quiere cambiar el formato del identificador de cliente que ya guardan cinco sistemas. ¿Cuál merece más tu atención, y por qué?
El identificador. La etiqueta es barata de cambiar. El identificador no pasa la Prueba de Reversibilidad: es difícil de revertir y ya depende mucho de él. Pon tu atención en proporción al costo de equivocarte. Vuelve a leer Algunas decisiones son baratas de cambiar.
3. Un campo de texto lleva años en uso. Ahora el negocio quiere que guarde un número. ¿Cómo lo abordas?
No lo mutes en el mismo lugar. Averigua qué depende de él (Flows, Apex, informes, integraciones, agentes) y qué pasa con los datos antiguos. Lo habitual: agrega un campo nuevo, migra de forma deliberada y deja obsoleto el antiguo. Vuelve a leer Cuidado con cambiar el esqueleto.
4. 1.200 locales, 100 citas por local al día, unos 305 días al año, dos registros por cita, cinco años conservados, 30 % de crecimiento. ¿Aproximadamente cuántos registros, y por qué importa?
Unos 73 millones de registros el primer año (36,6 millones de citas, dos registros cada una), y más de 650 millones en cinco años con el crecimiento. La misma funcionalidad, un par de ceros más, una arquitectura muy distinta. Vuelve a leer Conoce tus números.
5. Una carga nocturna informa "completada" con un millón de registros. ¿Cómo sabes que funcionó?
Concilias. El lado que recibe confirma cada registro que guardó; el que envía compara lo que mandó con lo que se confirmó. Si faltan confirmaciones, no funcionó, diga lo que diga el estado del trabajo, y sabes qué registros reintentar, enviar a una persona o convertir en alerta. Vuelve a leer Un éxito parcial sigue siendo un fallo que tienes que entender.
6. Una comunidad de 15 millones de usuarios de Customer Community necesita un acceso a registros complejo. Alguien propone el uso compartido con Apex. ¿Cuál es el problema?
Son usuarios de gran volumen: sin funciones y fuera del modelo de uso compartido, así que no hay ningún registro de uso compartido que Apex pueda escribir. Su acceso viene de los conjuntos y grupos de uso compartido. La licencia decidió qué herramientas de uso compartido existen. Vuelve a leer Un ejemplo resuelto: el uso compartido con Apex.
7. Una herramienta de IA genera veinte objetos para una aplicación nueva en minutos. ¿Cuál es ahora el trabajo del arquitecto?
Decidir si deberíamos tener cinco. Entender el modelo lo suficiente para defenderlo: por qué estos objetos y relaciones, dónde están las claves y los datos maestros, qué pasa a escala. Verificar los datos en los que se apoyó. Generar no es juzgar. Vuelve a leer La implementación barata desplaza el valor.
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.