Conoce tus herramientas: las nueve preguntas

🌐 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)

Imagen generada con IA

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

Módulo 6 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: Construye para hoy. Planifica para mañana. Planifica para el fallo. · Siguiente: El arquitecto de datos en la era de la IA

La pregunta que responde este módulo: ¿Cómo evalúas cualquier herramienta, incluida una que nunca has visto?

Los arquitectos necesitan criterio. Pero el criterio sin conocimiento no sirve de mucho. Igual tienes que conocer tus herramientas.

Llevo años enseñando a arquitectos, y un marco que uso es un conjunto de preguntas que deberías poder responder sobre cada herramienta o capacidad importante de tu arquitectura. Originalmente enseñaba ocho preguntas. He agregado una novena. Las tecnologías cambian, Salesforce cambia, aparecen productos nuevos y evolucionan las capacidades antiguas, y la IA lo está acelerando todo. Estas preguntas siguen funcionando.

Las nueve preguntas

Cada vez que aprendas o evalúes una tecnología, pregunta:

1. ¿Qué es?
2. ¿Dónde se usa?
3. ¿Cómo la uso?
4. ¿Cuáles son mis alternativas?
5. ¿Cuáles son sus fortalezas?
6. ¿Cuáles son sus debilidades?
7. ¿Cómo se la explico a los desarrolladores, al negocio y a los ejecutivos?
8. ¿Cómo se mantiene a largo plazo?
9. ¿Cuánto cuesta, qué licencias requiere y cuáles son sus límites?

Si puedes responder las nueve, empiezas a entender la herramienta como un arquitecto. Fíjate en lo que no está en la lista: “¿Puedo configurarla?”. Eso importa, pero es solo una parte de conocer la herramienta.

Click to enlarge

1. ¿Qué es?

Empieza por la pregunta obvia, porque la gente se la salta con una frecuencia sorprendente. Oímos el nombre de un producto o una función e inmediatamente empezamos a discutir si usarla. Frena. ¿Qué hace realmente? ¿Qué problema se diseñó para resolver? ¿Dónde se ubica en la arquitectura y qué no es? Un arquitecto debería poder describir una tecnología sin repetir la descripción de marketing. Si no puedo explicar algo en unas pocas frases, probablemente todavía no lo entiendo lo suficiente.

2. ¿Dónde se usa?

Saber lo que hace algo no es lo mismo que saber cuándo pertenece a una arquitectura. ¿En qué tipo de problemas es buena? ¿Qué condiciones la hacen adecuada y qué condiciones deberían hacerme desconfiar? Es el paso de “conozco esta función” a “reconozco el problema que resuelve esta función”, y es un paso importante. No quieres ir por ahí buscando dónde usar tu tecnología favorita. Quieres reconocer problemas y saber qué herramientas encajan con ellos.

3. ¿Cómo la uso?

Sí, los arquitectos deberían entender la implementación. No tienes que construir cada componente, pero deberías entender lo suficiente para saber qué les estás pidiendo construir a otros. Sabe cómo se configura, cómo trabaja un desarrollador con ella, cómo entran y salen los datos, cómo se despliega y se protege, y cómo se ve en operación. No quiero un arquitecto diseñando alrededor de una tecnología que solo ha visto en una diapositiva de producto. Ensúciate las manos: construye algo, rompe algo, mira cómo se comporta en realidad. La arquitectura mejora cuando está anclada en la realidad.

4. ¿Cuáles son mis alternativas?

Quizá sea la pregunta más importante de la lista. Si conoces una sola forma de resolver un problema, no tienes una decisión de arquitectura; tienes una opción por defecto. Cada vez que alguien propone una tecnología, quiero saber qué más podríamos hacer. ¿Otra capacidad de Salesforce? ¿Algo declarativo, o código? ¿Podría vivir la capacidad fuera de Salesforce? ¿Podríamos dejar los datos donde están en lugar de copiarlos, usar un evento en lugar de una llamada a la API o evitar construir nada en absoluto? Las alternativas crean compensaciones, y las compensaciones son el corazón de la arquitectura.

5. ¿Cuáles son sus fortalezas?

Cada herramienta existe por una razón. Entiende en qué es realmente buena: qué hace fácil, dónde escala bien, qué complejidad elimina, qué problemas resuelve con elegancia. Usa las tecnologías donde sus fortalezas coinciden con el problema. Suena obvio, pero es muy fácil elegir una herramienta porque ya la tenemos, el equipo la conoce, es nueva o alguien vio una demostración. Pueden ser factores. No son lo mismo que el encaje con la arquitectura.

6. ¿Cuáles son sus debilidades?

Esto es igual de importante. Toda tecnología tiene debilidades, todas. Si alguien solo puede decirte las fortalezas de una tecnología, todavía no estás teniendo una discusión de arquitectura. ¿Qué no hace bien? ¿Dónde aparece la complejidad y qué pasa a escala? ¿Qué carga operativa y qué dependencias trae? ¿Qué requisitos la sacan de su punto fuerte? Una debilidad no siempre significa que no debamos usar la tecnología. Significa que necesitamos saber qué estamos aceptando. Una compensación que entiendes puede ser una decisión de arquitectura. Una compensación que no entiendes puede convertirse en una sorpresa.

7. ¿Cómo la explico a públicos distintos?

Esta es una de las preguntas que separan el conocimiento técnico de la habilidad de arquitectura. ¿Puedes explicar la misma tecnología a un desarrollador, al negocio y a un ejecutivo? No deberían ser la misma explicación. El desarrollador necesita las API, el comportamiento de las transacciones, la seguridad, el manejo de fallos y los patrones de implementación. Al negocio le importa lo que permite hacer y cómo cambia su proceso. Al ejecutivo le importan el costo, el riesgo, el tiempo, el impacto en la organización y qué opciones deja abiertas o cierra la decisión. No cambias la verdad; cambias el nivel de abstracción. Si la única forma en que puedes explicar una tecnología es con el vocabulario de su documentación, sigue trabajando en tu comprensión.

8. ¿Cómo se mantiene a largo plazo?

Los proyectos terminan. Los sistemas no, o al menos eso esperamos. Alguien tiene que hacerse cargo de lo que construimos cuando el equipo del proyecto se va. Eso significa saber cómo se monitorea, se actualiza y se diagnostica, quién necesita las habilidades para darle soporte, cómo se despliegan y se prueban los cambios, y qué pasa cuando la tecnología evoluciona o Salesforce cambia algo debajo de nosotros. Imagínalo dentro de tres años. He visto arquitecturas muy ingeniosas el día del lanzamiento y miserables de operar después. Eso no es un éxito. La facilidad de mantenimiento es parte de la arquitectura.

9. ¿Cuánto cuesta, qué licencias requiere y cuáles son sus límites?

Esta es la pregunta que agregué a las ocho originales, y hoy creo que es imposible dejarla fuera. Una tecnología puede ser la solución técnica perfecta y aun así la equivocada desde la arquitectura si la economía no cierra. ¿Está incluida en las licencias que tenemos o es un complemento? ¿Se licencia por usuario, por uso, por consumo, por almacenamiento o por transacciones? ¿Qué pasa con el costo a medida que escalamos?

Luego están los límites, y toda plataforma los tiene: de API, de almacenamiento, de consultas, de transacciones, de concurrencia, de rendimiento y de licencias. Algunos son estrictos y otros flexibles; algunos se pueden ampliar y otros no; algunos no importan a nuestra escala hasta que sumamos otro cero. No tienes que memorizar cada límite de Salesforce, y hacerlo sería un pésimo uso de tu tiempo. Necesitas saber que los límites existen, cuáles importan para tu arquitectura y cuándo ir a verificar el número actual. Los números cambiarán. La pregunta de arquitectura permanece.

Un ejemplo resuelto: el uso compartido con Apex

Este es uno de mis ejemplos más habituales de las preguntas en acción. Recibimos un requisito de uso compartido complicado, que no se puede cumplir con ninguna de las reglas de uso compartido basadas en el propietario o en criterios. Eso nos lleva al uso compartido con Apex: código que escribe él mismo los registros de uso compartido. Así que ahora necesitamos saber qué es el uso compartido con Apex, dónde se usa, cómo se usa y el resto. Es una escalada: el uso compartido con Apex es la alternativa (pregunta 4) para cuando las reglas que necesitamos van más allá de lo que pueden expresar el uso compartido basado en el propietario y el basado en criterios.

Ahora sus debilidades (pregunta 6). Digamos que tenemos una comunidad de clientes con 10 o 20 millones de miembros, y usamos la licencia Customer Community, no Customer Community Plus. Son usuarios de gran volumen. No tienen funciones y no usan el modelo de uso compartido en absoluto: su acceso viene de los conjuntos de uso compartido y los grupos de uso compartido, emparejados a través de su cuenta y su contacto. No hay ningún registro de uso compartido que Apex pueda escribir para ellos, así que el uso compartido con Apex no funciona para ellos. Y la pregunta de costo y licencias (pregunta 9) es la que nos llevó ahí: la elección de licencia decidió qué herramientas de uso compartido existen siquiera.

Así que, igual que el uso compartido con Apex era la alternativa a las reglas basadas en el propietario y en criterios, puedes toparte con un caso en el que necesites una alternativa al uso compartido con Apex. Y en ese punto realmente no hay opciones basadas en configuración para reglas de uso compartido complejas. Terminas haciendo el objeto de solo lectura y controlando el acceso a través de Apex. Por eso haces las nueve preguntas antes de elegir, no después.

No memorices la plataforma

Esto importa sobre todo cuando estás aprendiendo arquitectura de Salesforce. No intentes memorizar Salesforce. No puedes: la plataforma es demasiado grande y cambia demasiado rápido. Llevo mucho tiempo trabajando con Salesforce y sigo aprendiendo. Es normal.

Lo que quiero que desarrolles es un marco para aprender. Cuando Salesforce lance mañana una capacidad nueva, no necesito haberla visto antes. Sé qué preguntar: qué es, dónde encaja, cómo la uso, qué otra cosa podría usar, en qué es buena, dónde le cuesta, cómo la explico, cómo la opero y cuánto cuesta y dónde están los límites. Ahora puedo empezar a evaluarla. Eso vale mucho más que memorizar otra matriz de funcionalidades.

Más allá del examen: la IA hace que las nueve preguntas se respondan más rápido, y que sea más fácil equivocarse. Si te encuentras con una tecnología que no conoces, puedes pedirle a la IA que la explique, que compare tres enfoques, que enumere sus límites y sus fallos comunes, o que argumente en contra de usarla. Es un asistente de investigación extraordinario. Pero puede equivocarse, estar desactualizado o confundir con total seguridad dos productos o ediciones con nombres parecidos. Para cualquier cosa que afecte una decisión, verifícalo: sigue la fuente y revisa la documentación, los límites y las licencias actuales. Confía, pero verifica (módulo 7).

Aprende las preguntas, no solo las respuestas

En este curso nos encontraremos con muchas tecnologías. No quiero que coleccionen respuestas; quiero que practiquen las preguntas. Cuando hablemos de objetos grandes, datos externos, Data 360, patrones de integración o una capacidad de IA que Salesforce lance seis meses después de escribir este capítulo, haz las mismas nueve preguntas.

Las respuestas cambiarán. Las preguntas perduran. Eso es lo que hace de esto un marco de arquitectura y no una guía de estudio.

Conoce tus herramientas: en qué son buenas, en qué son malas, qué otra cosa podrías usar, cuánto cuestan y dónde se rompen. Y sabe lo suficiente para explicar la decisión a las personas que tienen que vivir con ella. Así aprende tecnología un arquitecto.

Lo que decide aquí un arquitecto

• Si una herramienta encaja con el problema, juzgada con las nueve preguntas y no solo por si se puede configurar.
• Cuáles son las alternativas, y qué significan el costo, las licencias y los límites de la herramienta a tu escala.
• Quién la mantendrá, y cómo, dentro de tres años.
• Qué datos sobre la herramienta verificar antes de confiar en ellos.

Explora

• About High-Volume Community or Site Users (opens in a new tab), Ayuda de Salesforce (en inglés, consultado el 2026-10-09; verificado de nuevo el 2026-10-12): los usuarios de gran volumen (las licencias External Apps, Customer Community, High Volume Customer Portal y Authenticated Website) no tienen funciones; su acceso viene de los conjuntos de uso compartido y los grupos de uso compartido; no se pueden incluir en reglas de uso compartido basadas en el propietario, y los registros que poseen no se pueden compartir manualmente.
• Platform Sharing Architecture (opens in a new tab), Salesforce Architects (en inglés, consultado el 2026-10-09; verificado de nuevo el 2026-10-12): los usuarios de gran volumen (Customer Community, High Volume Customer Portal, Authenticated Website) no usan el modelo de uso compartido, porque sus licencias no admiten funciones; el acceso funciona emparejando al usuario con las búsquedas de cuenta y contacto, mediante conjuntos o grupos de uso compartido. La misma página explica cuándo el uso compartido gestionado por Apex es la herramienta adecuada.
• Account Sharing Sets for High Volume Customer Portal Users (opens in a new tab), pregunta en la Trailblazer Community, noviembre de 2024 (en inglés, consultado el 2026-10-09; verificado de nuevo el 2026-10-12): un profesional informa que insertar registros de uso compartido para usuarios de gran volumen falló con un error. Es un informe de campo, no documentación oficial. (La Trailblazer Community en línea pasa a ser de solo lectura el 30 de octubre de 2026; el enlace puede cambiar.)
• Create a Sharing Set for Experience Cloud Site Users (opens in a new tab), Ayuda de Salesforce (en inglés, consultado el 2026-10-09): un conjunto de uso compartido da acceso a los registros relacionados con la cuenta o el contacto del usuario.