Como arquitectos, debemos evitar caer en la tentación de la solución perfecta. Si leemos un artículo sobre microservicios o escalabilidad de gran escala, quisiéramos replicar ese esquema en nuestro proyecto actual. Pero la verdad que muchos olvidan es: una arquitectura excelente en el contexto equivocado es una mala arquitectura.
1. El mito de la “mejor práctica”
No existen las mejores prácticas universales, solo decisiones con base en compensaciones (trade-offs). El mayor error es elegir un patrón simplemente porque está de moda o porque “es lo que usan los grandes”.
Si el equipo es pequeño y el presupuesto es limitado, implementar una arquitectura compleja solo añadirá una carga operativa que podría hundir el proyecto rápidamente. La decisión de arquitectura superior es la que se adapte a las condiciones de negocio, de equipo de trabajo, de infraestructura y de presupuesto.
2. Las dimensiones del contexto
Elegir correctamente es ver más allá del código, lo que implica un análisis del contexto desde todas sus dimensiones:
– Contexto de negocio: ¿Cuál es el tiempo de salida al mercado? ¿Es un prototipo para validar una idea o un sistema que debe perdurar?
– Contexto de equipo: ¿Qué habilidades tienen los desarrolladores del equipo? No perder el tiempo proponiendo una arquitectura en Rust si el equipo domina Python, a menos que haya tiempo, presupuesto y razones de peso para la curva de aprendizaje.
– Contexto operativo: ¿Quién va a dar mantenimiento? La complejidad de la infraestructura debe ser proporcional a la capacidad de monitoreo y soporte de la empresa.
3. El peligro de la “arquitectura para el perfil profesional”
Hay que evitar soluciones diseñadas para lucir bien, pero que no resuelven el problema del cliente. Esto conlleva sobreingeniería, y por lo tanto costos innecesarios, lentitud en el desarrollo y una frustración en el equipo.
La arquitectura no debe diseñarse pensando en usar la tecnología más avanzada, sino encontrando la solución más simple que soporte los requerimientos actuales y permita el crecimiento futuro. Antes de dibujar el primer diagrama, hay que hacer preguntas: ¿Cuántos usuarios reales tendrá la aplicación? ¿Cuál es el presupuesto? ¿Qué tan rápido necesita cambiar de dirección el negocio? Las respuestas a esas preguntas dictarán la arquitectura.
Para recordar: el trabajo del arquitecto no es diseñar y construir el sistema más complejo del mundo, sino el sistema que el negocio necesita para prosperar.