La Prueba de Reversibilidad
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)
Módulo 3 de 7 del capítulo Pensar como un arquitecto de datos, el primer capítulo del curso Data Architect. Cada módulo se sostiene por sí solo. Anterior: El modelo de datos es el esqueleto · Siguiente: La arquitectura es el arte de las compensaciones
La pregunta que responde este módulo: ¿Cómo distingues una decisión de arquitectura de una ordinaria?
Los arquitectos toman muchas decisiones.
Pero no toda decisión es una decisión de arquitectura.
Es una distinción importante. Si tratamos cada decisión como arquitectura, pasaremos todo el tiempo debatiendo cosas relativamente fáciles de cambiar. Si no reconocemos las decisiones que de verdad son de arquitectura, podemos tomar hoy en cinco minutos una decisión que tarde cinco años en deshacerse.
Entonces, ¿cómo notamos la diferencia?
Me gusta hacer una pregunta sencilla:
¿Qué tan difícil será revertir esta decisión más adelante?
La llamo la Prueba de Reversibilidad.
Cuanto más difícil sea revertir algo, y cuantas más cosas dependan de ello, más atención de arquitectura merece.
Algunas decisiones son baratas de cambiar
Sección titulada «Algunas decisiones son baratas de cambiar »Empecemos por algo sencillo.
Llamamos a un campo Customer Category (categoría de cliente). Seis meses después, el negocio decide que en realidad todos lo llaman Customer Segment (segmento de cliente). Cambiamos la etiqueta. Puede que haya que actualizar algo de documentación y dar un poco de formación a los usuarios, pero no es un gran acontecimiento de arquitectura. Eso sí, tendremos que vivir con el nombre de API original, porque cambiarlo tiene consecuencias mucho mayores. Así que esto puede significar simplemente lidiar con un cambio de etiqueta y la confusión que puede traer.
Tomamos una decisión. Cambiamos de opinión. Seguimos adelante.
Ahora compáralo con otra decisión.
Estamos creando un identificador para los clientes. Decidimos qué significa, qué formato usa y qué sistema lo crea. Luego lo publicamos.
Salesforce lo usa. El almacén de datos lo usa. La plataforma de integración lo usa. El portal de clientes lo usa. Otras cinco aplicaciones empiezan a guardarlo. Los informes y las canalizaciones de datos lo usan. Quizá, con el tiempo, los clientes lo ven.
Tres años después, alguien dice:
Probablemente no deberíamos haber diseñado el identificador de esa manera.
Esa es una conversación muy distinta.
La diferencia no es que una decisión sea más técnica que la otra.
La diferencia es la reversibilidad.
Así es como puede pasar. Digamos que el negocio ha estado construyendo sus claves con parte del nombre del cliente más un número. Funciona durante años, porque nadie ha tenido que cambiar nunca un nombre. Luego, un año o más después, un nombre sí cambia y, de repente, las claves no coinciden con el patrón que espera el resto de los datos. Esta es una de las razones por las que las claves no deberían tener ningún significado intrínseco.
La arquitectura crea gravedad
Sección titulada «La arquitectura crea gravedad »Una decisión de arquitectura tiende a acumular cosas a su alrededor. Lo pienso como gravedad.
Elige un modelo de objetos, y se construye automatización a su alrededor.
Elige una clave, y otros sistemas empiezan a guardarla.
Elige dónde viven los datos maestros, y las integraciones empiezan a fluir hacia ellos y desde ellos.
Elige un modelo de uso compartido, y los procesos de negocio empiezan a depender de quién puede ver qué.
Elige un patrón de integración, y los sistemas empiezan a depender de sus tiempos y su comportamiento.
Cuanto más tiempo existen esas decisiones, más gravedad desarrollan. Al final, cambiar la decisión original significa cambiar todo lo que se ha acumulado a su alrededor.
La IA también siente esa gravedad. Una herramienta de IA trabaja a partir de lo que ya está en el sistema: una vez que un elemento clave del diseño está ahí, cada interacción con la IA que viene después lo trata como un hecho y sigue construyendo sobre él, y construyendo, y construyendo. La decisión resuena hacia adelante a través de muchas más decisiones, y ningún humano vuelve nunca a revisar la original. Cada generación suma a la gravedad.
Por eso importa que el modelo de datos sea “el esqueleto”. No tenemos cuidado porque el cambio sea malo. Tenemos cuidado porque las dependencias hacen que el cambio sea costoso.
Haz dos preguntas
Sección titulada «Haz dos preguntas »Cuando miro una decisión de diseño, hago dos preguntas:
¿Qué tan difícil es revertir esto?
¿Cuánto dependerá de ello?
Están relacionadas, pero no son idénticas. Algo puede ser técnicamente fácil de cambiar pero tener cientos de consumidores. Antes la gente reetiquetaba objetos estándar para dar claridad: la cuenta como “Cliente”, por ejemplo. Fácil de hacer. Luego otro sistema quiso usar las cuentas para los socios, y no pudo. Otra cosa puede tener solo unos pocos consumidores pero necesitar una migración enorme para cambiar, como el nombre de API de un objeto al que se hace referencia en muchos lugares internamente. Nadie de fuera lo ve, pero uno equivocado sigue confundiendo al equipo. Cualquiera de los dos merece atención.
Piensa en algunas decisiones de datos habituales:
- ¿Qué objeto de Salesforce representa este concepto de negocio?
- ¿Cuál es el identificador único?
- ¿Qué sistema es el sistema de registro?
- ¿Estos datos se copian a Salesforce o se accede a ellos en otro lugar?
- ¿Es un objeto o varios objetos relacionados?
- ¿Quién es dueño de los datos y cuánto tiempo los conservamos?
- ¿Cuáles son nuestros límites de acceso predeterminados?
- ¿Cómo se mueven estos datos entre sistemas?
Son muy distintas de decidir dónde aparece un campo en una página Lightning. El diseño de páginas también importa. Lo que cambia es el costo de equivocarse.
Piensa en el radio de impacto
Sección titulada «Piensa en el radio de impacto »Otra forma de pensar en la reversibilidad es el radio de impacto: si cambio esta decisión, ¿qué más se mueve?
Supón que algo que modelamos como un campo en realidad tiene que convertirse en un objeto hijo. Eso no es solo un cambio de esquema. ¿Qué pasa con los datos existentes? ¿Con los informes, las integraciones que esperan ese campo, el Apex y los Flows que hacen referencia a él, la seguridad, la analítica, un agente de IA cuyas acciones dependen de la estructura original?
Cuanto mayor sea el radio, con más cuidado deberíamos tomar la decisión original.
Por eso los arquitectos también tienen que mirar más allá de su propia parte del sistema. Desde dentro de Salesforce, un cambio puede parecer fácil. Desde la empresa, puede afectar a otros doce sistemas.
Decisiones de la empresa y decisiones de Salesforce
Sección titulada «Decisiones de la empresa y decisiones de Salesforce »Un arquitecto de datos piensa en dos niveles.
Dentro de Salesforce, decidimos objetos, relaciones, claves, volumen, acceso, automatización y cómo se comportan los datos en la plataforma.
En toda la empresa, hacemos preguntas más amplias. ¿Dónde vive realmente el cliente? ¿Quién es dueño del producto? ¿Qué sistema crea un pedido? ¿Cuál es nuestro identificador de referencia? ¿Qué información se copia entre sistemas y cuál se queda donde está?
Los dos niveles tienen que conectarse. He visto implementaciones de Salesforce en las que el modelo interno tenía todo el sentido por sí solo, pero no encajaba con la empresa que lo rodeaba. Eso no basta. Las estructuras de Salesforce tienen que estar representadas a nivel de empresa, y las decisiones de la empresa tienen que volver a Salesforce.
La arquitectura es tráfico en dos sentidos.
Frena ante las decisiones costosas
Sección titulada «Frena ante las decisiones costosas »Un peligro en tecnología es que las decisiones más fáciles de implementar pueden parecer las más fáciles de tomar. No son lo mismo.
Crear otro objeto personalizado es fácil. Crear otro campo es fácil. Conectar otra API es cada vez más fácil, y la IA lo hace todo aún más fácil.
Pero la facilidad de implementación no nos dice casi nada sobre el costo de la decisión de arquitectura.
Antes de una decisión difícil de revertir, frena el tiempo suficiente para preguntar: ¿Qué problema estamos resolviendo realmente? ¿Qué alternativas consideramos? ¿Qué estamos suponiendo? ¿Qué pasa cuando crece el volumen y cuando cambia el negocio? ¿Qué más dependerá de esto? ¿Qué pasa si nos equivocamos?
No necesitamos seis meses de revisión cada vez que creamos un objeto. Sí necesitamos una reflexión proporcional al costo de equivocarnos. Si es un objeto para un solo departamento o subsistema, puedes ir más rápido. Si son datos de referencia, un objeto de cliente clave o algo que se usa entre sistemas, tómate el tiempo de pensarlo bien.
Escribe por qué
Sección titulada «Escribe por qué »Hay otro problema con las decisiones importantes: la gente olvida por qué se tomaron.
Alguien mira una arquitectura tres años después y pregunta: “¿Por qué alguien la diseñaría así?”. A veces la respuesta es que fue un mal diseño. Pasa. Pero a veces había una razón muy buena: una limitación de la plataforma que ya no existe, un requisito normativo, otro sistema que no podía soportar el enfoque preferido, una compensación aceptada a sabiendas para cumplir una fecha.
Si solo registramos qué decidimos y no por qué, el siguiente arquitecto no tiene forma de saberlo.
Para las decisiones importantes, escríbelo. No hace falta un documento de 50 páginas. Un registro de decisiones útil puede ser muy pequeño:
Contexto: ¿Qué problema estamos resolviendo?
Opciones: ¿Qué alternativas realistas consideramos?
Decisión: ¿Qué elegimos?
Consecuencias: ¿Qué ganamos y a qué renunciamos?
Responsable: ¿Quién responde por esta decisión?
Revisión: ¿Qué motivo o qué fecha debería hacernos revisarla?
El valor no está en el documento. El valor está en conservar el razonamiento.
Y cuando una decisión cambia, no borres la original. Sustitúyela. La decisión que era correcta en 2027 puede no serlo en 2030, porque los volúmenes, el negocio, Salesforce y nuestra comprensión cambian. Lo que quiero conservar es la historia: este era el contexto, esta fue la decisión y por qué, esto es lo que cambió y esto es lo que decidimos ahora. Eso vale mucho más que fingir que siempre supimos la respuesta.
Más allá del examen: la IA acorta el tiempo entre la decisión y la dependencia. Una herramienta de IA puede proponer un modelo de datos en segundos y luego crear encima los objetos, la automatización, el código de integración y la interfaz de usuario. Antes, una decisión dudosa tardaba meses de desarrollo hasta que algo importante dependía de ella; ahora las dependencias llegan casi de inmediato. Así que revisa las decisiones que hay debajo del resultado, no solo el resultado. La IA puede ayudar: puede enumerar opciones, cuestionar supuestos y redactar el registro de decisiones. Pero el arquitecto sigue decidiendo, y cuanto más difícil de revertir es la decisión, más importa ese criterio humano.
Sabe qué decisiones importan
Sección titulada «Sabe qué decisiones importan »Una de las habilidades que quiero que desarrolles es saber dónde poner tu atención.
No conviertas cada elección de configuración en una cumbre de arquitectura.
Pero no tomes a la ligera una decisión con la que la organización vivirá durante la próxima década.
Pregunta:
¿Qué tan difícil será revertir esto?
¿Cuánto dependerá de ello?
Si las respuestas son muy difícil y mucho, probablemente encontraste una decisión de arquitectura.
Frena. Entiende el requisito. Explora las alternativas. Haz visibles las compensaciones. Toma la decisión. Y escribe por qué.
El objetivo de la arquitectura no es tomar decisiones que nunca puedan cambiar.
El objetivo es reconocer las decisiones en las que cambiar de opinión va a salir caro.
Lo que decide aquí un arquitecto
Sección titulada «Lo que decide aquí un arquitecto »- Qué decisiones son de arquitectura: difíciles de revertir, con mucho dependiendo de ellas.
- Cuánta atención recibe cada decisión, en proporción al costo de equivocarse.
- Qué decisiones se escriben, con su contexto, opciones, consecuencias, responsable y punto de revisión.
- Cómo se alinean las decisiones de Salesforce con las de la empresa.
Explora
Sección titulada «Explora »- Object Relationships Overview (opens in a new tab), Ayuda de Salesforce (en inglés, consultado el 2026-10-09; verificado de nuevo el 2026-10-12): en una relación principal-detalle, el acceso y la propiedad del detalle siguen al principal, y eliminar un principal elimina sus detalles.
- Considerations for Object Relationships (opens in a new tab), Ayuda de Salesforce (en inglés, consultado el 2026-10-09; verificado de nuevo el 2026-10-12): una búsqueda solo se convierte en principal-detalle cuando todos los registros tienen un valor en ella; la conversión cambia el modelo de uso compartido (a Controlled by Parent), y el tipo de relación decide qué tipos de informe estándar están disponibles.
- Roll-Up Summary Field (opens in a new tab), Ayuda de Salesforce (en inglés, consultado el 2026-10-09; verificado de nuevo el 2026-10-12): los campos de resumen acumulativo solo existen en relaciones principal-detalle, y hay que eliminarlos antes de que una principal-detalle pueda convertirse en búsqueda.