La arquitectura que nadie pidió
Introducción
¿De qué sirve construir una arquitectura técnicamente impecable si nunca fue necesaria para
resolver el problema? En el desarrollo de software, una decisión arquitectónica debe surgir
siempre de las necesidades y las restricciones que definen el sistema. Ignorar esto puede
convertir lo que era una solución sencilla en una compleja generando un aumento de costos y
esfuerzo.
Por ello, los requisitos funcionales y los atributos de calidad deben construir la base para
determinar qué arquitectura es adecuada para el sistema. El verdadero desafío al diseñar un
sistema no es generar la arquitectura más sofisticada sino lograr justificar aquella que responda
de manera efectiva al problema.
De la necesidad a la decisión arquitectónica
¿Qué pasaría si la arquitectura de un sistema fuera la respuesta a una pregunta que nunca se
hizo? En el desarrollo de software, el adoptar tecnologías antes de lograr comprender
correctamente el problema hace que una solución sencilla se vuelva una estructura
innecesariamente compleja. Por ello, las decisiones deben ser fundamentadas por los requisitos
del sistema y no por la popularidad de las tecnologías.
Tanto los requisitos funcionales como los atributos de calidad, rendimiento, seguridad,
disponibilidad y escalabilidad deben orientar las decisiones de arquitectura (Lago, Avgeriou, and
Hilliard 2010). Cada componente que se incorpora al sistema debe responder a una necesidad
concreta y debe aportar un beneficio que se pueda justificar.
Cuando la arquitectura supera al problema
La Sobre Ingeniería ocurre cuando la solución técnica que se plantea es mucho más compleja del
problema a resolver. Un ejemplo es adoptar una arquitectura distribuida para una aplicación
sencilla. Aunque estas decisiones pueden parecer preparación futura, genera una consecuencia
medible al chocar con los atributos de calidad, disparando costos de mantenimiento, pruebas y
dificultades que no existían sin un beneficio que lo justifique (Kazman, Klein, and Clements
2000).
Esto no significa que la complejidad sea negativa ya que hay sistemas que si lo necesitan como
los sistemas que procesan datos sensibles o las plataformas con miles de usuarios. En estos
casos, estas arquitecturas generan beneficios reales. El problema surge cuando una solución
compleja se adopta sin tener un requisito que la justifique. La complejidad deja de ser una
inversión cuando no se responde a las necesidades reales del sistema convirtiéndose en una
complejidad accidental, introducida por tendencias, imitaciones o expectativas poco realistas.
Un mismo problema, diferentes soluciones
Bien, para verlo de mejor manera se plantea el caso: “Desarrollo de sistema para la gestión de
citas de un veterinario particular”, contemplando registrar usuarios, agendar cita, consultar
disponibilidad, cancelar cita, entre otras. Para darle solución al problema veremos dos
posibilidades, una de ella utilizando un monolítico y una arquitectura basada en microservicios.
Figura 1. Comparación de una arquitectura monolítica y una arquitectura basada en microservicios para un mismo sistema de gestión. Fuente: elaboración propia.
Tal como lo presenta la Figura 1, una arquitectura basada en microservicios representaría
aproximadamente el triple de despliegues a mantener, pues se observan 3 servicios, que precisamente en el caso planteado, cuentan con un sistema de persistencia cada uno, frente a una
aplicación global y una base de datos que representaría un monolítico. Ojo, que no
automáticamente significa que está mal, pero estamos hablando de un “Sistema para la gestión
de citas de un veterinario particular”, no hay ningún driver, como alta disponibilidad o
escalamiento masivo que justifique la implementación de un proyecto de tal magnitud.
Conclusión
Para diseñar una arquitectura es importante tener en cuenta que no se construye un sistema para
relucir conocimientos técnicos, o para dar a conocer habilidades. Esos dos factores son
esenciales, pero no son la prioridad; la prioridad en todo momento es buscar la mejor solución al
problema inicial y satisfacer las necesidades del usuario. Por supuesto, la propuesta tiene que
tener fundamento técnico y tiene que ser hecha a la medida, y en esta parte es donde se tiene que
demostrar cuán capacitado está un arquitecto, porque esto no va de suponer que estilo
arquitectónico es mejor valorado, o más difícil de implementar, consiste en buscar una solución
apta. Basar la arquitectura en la definición de “architecture drivers” es una práctica
indispensable, pues estos ponen restricciones, límites, y alcances que condicionan la elaboración
y planificación de un proyecto, esta práctica ayuda a que el producto final sea una solución real.
https://pure.rug.nl/ws/files/2632678/2010IEEESoft wareLago.pdf.
2. Kazman, Rick, Mark Klein, and Paul Clements. 2000. ATAM: Method for Architecture
Evaluation, CMU/SEI-2000-TR-004. Pittsburgh, PA: Software Engineering Institute,
Carnegie Mellon University.
https://www.sei.cmu.edu/documents/629/2000_00 5_001_13706.pdf.
3. Gonzalez, Rodrigo Alejandro, Sergio Agustín Giménez, Numa Roy Molina Pualuk, and
Rodrigo Zalazar. 2024. “¿Son Los Microservicios La Mejor opción? Una evaluación De
Su Eficacia Y Eficiencia Frente a Los Monolitos”. JAIIO, Jornadas Argentinas De
Informática 10 (5). https://revistas.unlp.edu.ar/JAII O/article/view/17980.
Ver diseño original de las páginas
