Arquitecto de la torre de marfil
Introducción:
La arquitectura de software permite definir la estructura de un sistema y orientar las
decisiones necesarias para su desarrollo. Sin embargo, cuando estas se toman ignorando la
realidad del proyecto y con poca comunicación con el equipo encargado de implementarlas,
puede surgir una brecha entre el diseño y la construcción. Esta situación se puede relacionar
con la problemática del arquitecto de la torre de marfil.
El presente artículo explora las dificultades que surgen cuando las decisiones arquitectónicas
se alejan de las condiciones reales del desarrollo. También busca destacar la importancia de la
comunicación y colaboración entre arquitectos y desarrolladores de software, para favorecer
la retroalimentación y considerar las diferentes perspectivas sobre el proyecto.
Desarrollo:
La arquitectura de software cumple una función importante en el desarrollo de software,
debido a que establece la estructura y la comunicación entre los distintos componentes que
conforman un sistema. Sin embargo, surge la siguiente interrogante: ¿Qué pasaría si el
arquitecto encargado se apega a reglas y estándares «irreales» para establecer el modelo de
desarrollo que se utilizará en la construcción del software?
La problemática de la torre de marfil es una metáfora utilizada para hacer referencia a una
posición de aislamiento, asociada con figuras que desempeñan un rol de liderazgo. Como se
ilustra en la Figura 1, este aislamiento puede favorecer una cadena de desconexiones que
culmina en la erosión arquitectónica del sistema. En contraste, la comunicación constante y la
colaboración entre arquitectos y desarrolladores pueden favorecer una arquitectura más
adaptable y alineada con las necesidades reales del proyecto.
Figura 1. Comparación de los efectos de la toma de decisiones aislada y colaborativa en la arquitectura de software. Fuente: elaboración propia.
arquitectura de software. Fuente: Elaboración propia.
Debido al rol de liderazgo del arquitecto de software, puede presentarse la problemática de la
torre de marfil cuando sus decisiones se alejan de las herramientas, los procesos y las
necesidades reales del equipo. Esta desconexión puede dificultar la implementación de la
arquitectura propuesta y favorecer diferencias entre el diseño y el sistema construido.
Un ejemplo puede presentarse cuando un arquitecto decide implementar una solución cloud
ready basada en microservicios, Redis y Kubernetes en un sistema on-premise altamente
restrictivo. Desde el punto de vista administrativo, el diagrama de arquitectura puede parecer
lógico e impecable. Sin embargo, para el equipo de desarrollo la problemática no se resuelve,
sino que se agrava, debido a que el diseño asume conectividad permanente y alta
disponibilidad en la nube, ignorando las restricciones del negocio y la naturaleza offline de
los sistemas de facturación.
En este caso, la disponibilidad y la escalabilidad constituyen atributos de calidad que orientan
la decisión arquitectónica, pero implican un trade-off frente a las restricciones de
conectividad y las necesidades operativas del sistema. Entonces, ¿cómo pueden atenuarse los
efectos negativos asociados con la problemática de la torre de marfil en la arquitectura de software? Según Emmanuel Valverde Ramos, desde una perspectiva de equipo, es posible
● Reuniones casuales: realizar reuniones en un contexto de intercambio de ideas.
● Registrar tiempos entre ciclos: obtener datos relevantes sobre deficiencias.
Conclusiones:
La problemática del arquitecto de torre de marfil demuestra que una arquitectura no debe
evaluarse únicamente por su calidad en el diseño, sino también por su capacidad para
adaptarse a las condiciones reales de su implementación. Cuando no existe una alineación
entre los objetivos de ambas perspectivas se pueden generar diferencias entre la estructura
planeada y el producto final, dando como resultado problemas como la erosión
arquitectónica. Como recomendación, debe existir una revisión y comunicación frecuente
entre el arquitecto y los desarrolladores de software, de manera que la toma de decisiones se
pueda contrastar con la realidad del proyecto. Es importante encontrar un equilibrio entre
ambas perspectivas, de modo que la visión del arquitecto tampoco se vea limitada, para que
se puedan incorporar soluciones con capacidad de evolución, pero sin agregar complejidad
innecesaria.
Referencias bibliográficas:
Baabad, A., Zulzalil, H., Hassan, S., & Baharom, S. Characterizing the Architectural Erosion
Metrics: A Systematic Mapping Study. IEEE Access, 10 (2022): 22915–22940.
https://doi.org/10.1109/ACCESS.2022.3150847
Uzun, B., & Tekinerdogan, B. Detecting deviations in the code using architecture view-based
drift analysis. Computer Standards & Interfaces, 87 (2024): 103774.
https://doi.org/10.1016/j.csi.2023.103774.
Alami, A., Krancher, O., & Paasivaara, M. The journey to technical excellence in agile
software development. Information and Software Technology, 150 (2022): 106959.
https://doi.org/10.1016/j.infsof.2022.106959
Valverde Ramos, E. The Ivory Tower Architect. The Tech Lead Journal, Substack (2024).
https://emmanuelvalverderamos.substack.com/p/th e-ivory-tower-architect
Ver diseño original de las páginas
