La arquitectura es el arte de las compensaciones

🌐 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 4 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: La Prueba de Reversibilidad · Siguiente: Construye para hoy. Planifica para mañana. Planifica para el fallo.

La pregunta que responde este módulo: Cuando varias soluciones podrían funcionar, ¿cómo elige un arquitecto y cómo explica la elección?

Si la arquitectura consistiera simplemente en identificar la respuesta correcta, sería mucho más fácil. Aprendes la plataforma, aprendes los patrones, aprendes los límites, eliges el correcto y listo.

Así no funciona la arquitectura real. Las decisiones difíciles no suelen ser entre una solución claramente buena y una claramente mala. Son entre varias soluciones que podrían funcionar, cada una con ventajas y desventajas, cada una llevando la arquitectura en una dirección ligeramente distinta. Ahí es donde el arquitecto se gana su lugar en la mesa.

Muchas formas de resolver el problema

He usado una versión de este ejemplo muchas veces al enseñar a arquitectos.

En Salesforce puede haber muchas formas de resolver un problema. A veces le pongo un número, digamos diez, pero es una analogía, no una cuenta. Muchas de las opciones tienen problemas desde el principio: chocan con una restricción de la plataforma, no cumplen un requisito crítico o crean un problema de seguridad o de rendimiento que no podemos aceptar. Esas las descartamos rápido. Otras funcionan hoy pero tendrán problemas cuando los datos crezcan. Técnicamente funcionan, pero no resistirán el crecimiento que ya sabemos que viene.

Lo que queda es un pequeño número de opciones que pueden sostener tus necesidades hacia adelante, y ahí se pone interesante. Cada una podría funcionar, escalar y cumplir los requisitos. Entonces, ¿cuál es la correcta? Quizá todas. El trabajo del arquitecto es entender las diferencias.

Incluso algo tan simple como una lista de selección funciona hoy y puede tener problemas a medida que crecen los datos. Una lista de selección es fácil para los usuarios. Pero pregunta de dónde vienen los valores y cuántos puede haber. Las listas de selección funcionan mejor con menos de unos 20 valores. A veces llegamos a 50, como los estados de EE. UU., y rara vez pasamos de 100, como los países, y esas se vuelven difíciles de manejar. Así que, para cada lista de selección, conoce el límite superior. Y cambiar los valores de una lista de selección es un cambio de metadatos, no un cambio de datos.

Si usas una búsqueda en su lugar, la interfaz de usuario se vuelve un poco más compleja. Pero la lista puede seguir creciendo sin límite superior, y los valores nuevos pueden llegar desde una integración. Es una compensación frente a la facilidad de uso. Ese es el equilibrio.

Click to enlarge

Óptimo no significa perfecto

Uso la palabra óptimo con cuidado. Una arquitectura óptima no es una en la que cada decisión individual es perfecta; esa arquitectura probablemente no existe. Es una en la que la solución en conjunto está equilibrada.

Supón que la solución A da el mejor rendimiento pero es cara y difícil de mantener. La solución B cuesta menos y es más fácil de operar, pero renuncia a algo de rendimiento. La solución C es más flexible para el futuro pero agrega complejidad hoy. ¿Cuál es la óptima? No puedo responder solo con esos datos. Necesito conocer el negocio, los requisitos y las prioridades, y qué restricciones son reales y cuáles son preferencias. La arquitectura depende del contexto. Por eso el patrón que fue correcto para un cliente puede ser completamente equivocado para el siguiente.

Y tu trabajo como arquitecto de datos es equilibrar estas decisiones. Tomarás decenas tú mismo o con tu equipo. Sabe cuáles son, y sabe cuándo una decisión tiene un impacto mayor, en costo, tiempo o funcionalidad, y tiene que subir a quienes toman las decisiones clave.

Una decisión subóptima puede ser parte de una arquitectura óptima

Esta es una de las ideas más importantes de este capítulo. A veces tomo a sabiendas una decisión subóptima en una parte de la arquitectura porque mejora la solución completa.

Quizá duplico una pequeña cantidad de datos, porque eliminar la duplicación crearía una complejidad de integración innecesaria. Quizá elijo un modelo de datos más simple, porque el teóricamente más limpio haría mucho más difíciles los informes y el uso diario. Quizá acepto un pequeño costo de rendimiento, porque la alternativa agrega infraestructura que la organización no está lista para operar.

Mira cualquiera de ellas por separado y dirías que no es óptima. Correcto. Pero la arquitectura no trata de optimizar cada componente por sí solo; trata de optimizar el sistema. Una decisión localmente subóptima puede ser parte de una arquitectura globalmente óptima, siempre que entendamos la compensación que estamos haciendo. Lo peligroso es hacer la compensación sin saber que la estás haciendo.

Sabe a qué estás renunciando

Cada vez que alguien me dice “esta es la mejor solución”, mi siguiente pregunta es “¿la mejor en qué?”. ¿La más rápida? ¿La más barata? ¿La más simple? ¿La más escalable, la más segura, la más flexible? ¿La más fácil de operar, la más rápida de entregar, la que menos depende de habilidades especializadas? Casi siempre hay otra dimensión en la que la respuesta no es “la mejor”. Esa es la compensación. Quiero saber qué obtenemos, y también quiero saber a qué renunciamos.

Toma dos opciones para un gran conjunto de datos de la empresa. Una copia los datos a Salesforce, lo que hace más fácil usar las capacidades nativas de Salesforce, pero ahora somos responsables de moverlos, guardarlos, sincronizarlos, proteger otra copia y lidiar con la latencia. La otra deja los datos donde están y accede a ellos cuando hace falta. Eliminamos algo de duplicación, pero ahora importan más la disponibilidad, el rendimiento de las consultas, las dependencias de red y las capacidades del sistema remoto. Ninguna de las dos descripciones nos dice cuál elegir. Nos dice qué preguntas hacer.

No todos los requisitos son iguales

Las compensaciones también nos obligan a ver que no todos los requisitos pesan lo mismo.

Alguien dice: “Los datos tienen que estar disponibles al instante”. Bien, ¿qué significa al instante? ¿Un segundo, diez segundos, un minuto? ¿Y por qué? Quizá sea detección de fraude, donde los segundos importan. Quizá alguien simplemente no quiere esperar a la carga nocturna. Son requisitos muy distintos, y el arquitecto sigue preguntando hasta saber cuál tenemos.

Me gustan los requisitos que resisten las preguntas: cuánto, cuántos, qué tan rápido, con qué frecuencia, para quién y qué pasa si no lo hacemos. “Rápido” no es un requisito de arquitectura. “El 95 % de las actualizaciones de clientes debe estar disponible para el agente de servicio en 30 segundos” se acerca mucho más a uno. Ahora sí podemos evaluar compensaciones.

Las restricciones cambian la respuesta

A veces la arquitectura no está restringida por la tecnología en absoluto. Está restringida por el dinero, las personas, el tiempo, las licencias o la madurez de la organización.

Una arquitectura técnicamente excelente que necesita un equipo de operaciones que la empresa no tiene no es una buena arquitectura. Una capacidad que resuelve el problema con elegancia pero necesita licencias que el cliente no va a comprar tampoco es la solución. Y la transformación perfecta a tres años no ayuda a una empresa que tiene que lanzar en ocho semanas.

Nada de eso significa abandonar la buena arquitectura por una fecha límite. Significa entender qué estamos comprometiendo, por qué y qué consecuencias aceptamos, e idealmente cómo pasaremos del compromiso de hoy a la arquitectura de mañana.

El arquitecto necesita una imagen de lo “óptimo”

Aquí hay una tensión interesante. Te digo que a menudo no hay una única respuesta perfecta, y también quiero que lleves en la cabeza una imagen de cómo es una solución óptima. No son contradictorias. Necesitas un punto de referencia.

Cuando miro un modelo de datos, quiero saber qué construiría si pudiera optimizar para los requisitos sin restricciones innecesarias. Luego, a medida que las restricciones reales nos alejan de ese diseño (aplanamos parte del modelo, duplicamos algunos datos, posponemos una integración, aceptamos un proceso manual temporal), no hago concesiones al azar. Sé en qué dirección me estoy alejando de lo óptimo, y por qué. Ese es el arte de la arquitectura, y el instinto requiere práctica.

Dibújalo

Una de las mejores formas de entender una compensación es dibujarla. Los diagramas de arquitectura no son adornos para una presentación; son herramientas para pensar. Si elegimos entre dos enfoques, dibuja los dos. ¿Dónde viven los datos y por dónde se mueven? ¿Quién es su dueño? ¿Dónde están los límites y dónde se aplica la seguridad? ¿Qué pasa cuando algo falla y qué cambia cuando crece el volumen?

Un diagrama saca la ambigüedad a la luz y le da a todos la misma imagen a la que señalar.

Aprendí cuánto importa eso en un proyecto con una empresa de servicios públicos. Revisión tras revisión, me encontraba explicando otra vez los mismos conceptos y devolviendo la conversación al diseño original. Así que cambié la forma de llevar esas reuniones: cada revisión empezaba con el modelo de datos en la pantalla. No el detallado con todos los campos. Un modelo resumido: una cuenta tiene contactos, este registro tiene hijos, aquí es donde cuelga el trabajo. La sala estaba llena sobre todo de ejecutivos, y tomaba un par de minutos.

Como eran las mismas personas reunión tras reunión, el diagrama se convirtió en nuestro lenguaje común. La gente empezó a usar sus nombres. Las preguntas repetidas fueron desapareciendo y las reuniones se volvieron mucho más fáciles. Lo llamo anclar la reunión: un diagrama simple, mostrado cada vez, valía mucho más de lo que costaba hacerlo.

El objetivo no es la perfección artística. A veces es un diagrama detallado para ingenieros, a veces cinco cajas y seis flechas para un ejecutivo. El objetivo es la claridad.

Explica la compensación

Un buen arquitecto lo presenta en orden: estas son las opciones que consideramos, esto es lo que nos da cada una, esto es lo que nos cuesta cada una, esta es la opción que recomiendo y este es el porqué.

Fíjate en que la recomendación viene después de las compensaciones. No quiero que la arquitectura se convierta en “ya lo he hecho antes, confía en mí”. La experiencia importa muchísimo; te ayuda a reconocer patrones más rápido y a ver los problemas antes. Pero tu experiencia debería mejorar tu razonamiento, no reemplazarlo. Nuestro trabajo no es solo entender la arquitectura. Es ayudar a la organización a entender la decisión, sobre todo cuando quienes tienen la última palabra no son arquitectos.

Piensa bien. Piensa rápido.

No siempre tendrás tres semanas para analizar cada opción. A veces tendrás tres minutos. Un requisito cambia en una reunión, alguien menciona una restricción que no conocías o un ejecutivo pregunta: “¿Y si necesitamos esto en Europa el año que viene?”.

He usado la frase Piensa bien. Piensa rápido. La velocidad no viene de saltarse el pensamiento. Viene de haber pensado lo suficiente antes de que llegue el momento: has aprendido los patrones, conoces la plataforma, has visto fallos, sabes qué preguntas hacer y qué decisiones son difíciles de revertir. Por eso trabajamos con escenarios a lo largo de todo el curso. Cuantas más decisiones analizas, más rápido reconoces la forma de la siguiente.

Tuve un cliente que necesitaba captura de formularios. Pero había muchos formularios y las preguntas podían cambiar con el tiempo. Enseguida reconocí la necesidad de un modelo de datos de encuestas, un patrón al que volveremos más adelante en el curso. Como reconocí el patrón y la solución, pude proponer un modelo de datos más completo, uno que atendía los requisitos que aún estaban por llegar, no solo los que teníamos delante.

La arquitectura trata del equilibrio

A medida que profundicemos en la arquitectura de datos, encontrarás elecciones en las que me resisto a darte una regla simple. ¿Normalizar o aplanar? ¿Copiar los datos o federarlos? ¿Síncrono o asíncrono? ¿Objeto estándar o personalizado? ¿Archivarlo o mantenerlo en línea?

Hay principios, patrones y límites, y a veces respuestas claramente equivocadas. Pero a menudo el trabajo del arquitecto es encontrar el equilibrio correcto para este sistema, este negocio y este momento.

Sabe cómo es lo óptimo. Entiende las restricciones. Identifica las opciones viables. Haz visibles las compensaciones. Luego toma la decisión.

Eso no es indecisión. Eso es arquitectura.

Lo que decide aquí un arquitecto

• Qué opciones son viables y cuáles están mal ahora o se estropearán en un año.
• Qué gana y a qué renuncia cada opción viable, medido contra requisitos que resisten las preguntas.
• Qué restricciones son reales y cuáles son solo preferencias.
• Qué opción recomendar, después de presentar las compensaciones, y cómo explicarla.