Parte II – Arquitectura
Las diversas definiciones de arquitectura de software recopiladas por el Instituto de Ingeniería de Software de la Universidad Carnegie Mellon [1] sugieren que esta expresión no tiene un significado obvio cuando se examina de forma aislada. Aunque los términos "arquitectura" y "software" tienen significados delineados con precisión, su combinación intrínseca depende del contexto específico en el que se aplican.
Gregor Hohpe postula que todo software tiene una arquitectura, aunque no sea intencional. Esa arquitectura debería impulsar la eficiencia de los equipos de ingeniería al permitir el desarrollo en paralelo y la evaluación de los componentes creados. Además, sostiene que ninguna arquitectura es perfecta y que siempre existe una combinación de decisiones a considerar, siendo el contexto el principio organizador de todas ellas.
La documentación de arquitectura de software debe contener las decisiones no triviales y siempre ofrecer al lector el razonamiento detrás de cada elección realizada, observando el contexto que sirvió como catalizador. Además, la documentación debe enfatizar lo esencial, restar énfasis a lo innecesario y describir las limitaciones de una decisión arquitectónica. Es fundamental reconocer que toda decisión importante tiene sus desventajas.
El autor advierte que las decisiones demasiado costosas de revertir más adelante deben tomarse desde el inicio del proyecto, para evitar que el progreso se paralice debido al análisis de cada nuevo elemento introducido. Citando a Martin Fowler, Hohpe aclara que una de las tareas cruciales de los arquitectos de software es eliminar la irreversibilidad del diseño de software mediante abstracciones [2], patrones y paradigmas de desarrollo, con el fin de minimizar las decisiones irreversibles al principio del proceso. Si el nivel de conocimiento de las tecnologías por parte del equipo de ingenieros es insuficiente, es posible adoptar una arquitectura evolutiva, que se desarrolla a medida que crece la comprensión sobre esas herramientas.
La arquitectura de software abarca más que componentes y sus interrelaciones. Es necesario adoptar un enfoque sistémico, enfatizando las relaciones y cómo cada estructura actúa como medio para alcanzar un comportamiento deseado. En este sentido, técnicas como los ciclos de retroalimentación negativa pueden aplicarse actuando como una autorregulación de los sistemas mediante las relaciones entre los componentes diseñados. El foco en el comportamiento también debe reflejarse en la documentación producida, donde debe ser el aspecto más relevante, en lugar de las estructuras estáticas.
Controlar el software heredado también es un desafío en la arquitectura de software, y la clave para evitar la obsolescencia de estos sistemas es mantener su agilidad. Un sistema no es ágil si nadie puede modificarlo. Este temor a los cambios está justificado cuando no existen prácticas y técnicas de operación adecuadas, faltan métricas productivas y las implementaciones son esporádicas. Fowler afirma: "si algo duele, hazlo más seguido" [3]. En este contexto, las tareas problemáticas deben realizarse con frecuencia, de modo que se imponga la automatización.
Para una arquitectura de software en operaciones a gran escala, el autor enfatiza la necesidad de una amplia automatización, desde procesos burocráticos como aprobaciones de solicitudes de infraestructura, hasta pipelines para el despliegue de aplicaciones. Lo que no pueda automatizarse debe convertirse en sistemas de autoservicio, simplificando actividades rutinarias y predecibles. Una estrategia posible para la automatización de este tipo de sistema es la construcción de interfaces con validaciones integradas al ciclo de desarrollo de software, incluyendo el uso de código boilerplate para nuevas aplicaciones y la configuración de servicios de infraestructura. También debe codificarse el conocimiento tácito en scripts y herramientas, evidenciando estos procesos y facilitando la transferencia de conocimiento. Por último, los sistemas automatizados para procesos ampliamente estandarizados y explícitos facilitan la auditoría de cumplimiento.
La arquitectura de software implica tomar decisiones de diseño para evitar que los desarrolladores ejerzan una creatividad innecesaria. Esto significa que ciertos procesos deben establecerse previamente y mantenerse como estándares, con el fin de simplificar la operación del software y liberar a los equipos de ingeniería para aquello que aporta diferenciación de negocio a la empresa. La estandarización de componentes en TI simplifica las operaciones, permite economías de escala y ahorra recursos financieros gracias al aumento del poder de negociación con los proveedores.
Esta estandarización debe considerarse en dos niveles: el nivel inferior, donde debe buscarse el máximo reaprovechamiento, ya que no siempre es el diferencial de la empresa, y el nivel superior, con software desarrollado internamente, que aporta el verdadero valor y la diferenciación competitiva en el mercado. Existe un elemento de conformidad en el que ocurren pocos cambios en los niveles más bajos, lo que facilita la estandarización con un conjunto común de herramientas.
Al elaborar diagramas de arquitectura de software, ya sea utilizando modelos C4 [4] u otras notaciones gráficas, comúnmente se destacan los bloques que representan los componentes. Sin embargo, desde la perspectiva de Hohpe, estos diagramas deben diseñarse enfocándose en las funcionalidades y en las relaciones entre esos componentes, mediante líneas y flechas, para resaltar la comunicación entre los elementos que componen el sistema en diferentes niveles. Este enfoque contribuye a una comprensión más clara y eficiente de la arquitectura del software y de su dinámica.
Finalmente, al adoptar un conjunto de tecnologías de un proveedor, es crucial cuestionar los límites de cada herramienta y cómo se relacionan con el sistema en su conjunto. De esta forma, es posible establecer las fronteras de la solución propuesta y garantizar un enfoque más eficiente para la arquitectura de software.
Consideraciones
La dificultad para definir con precisión la arquitectura de software surge del intento de asociarla directamente con los componentes más fundamentales del software, como los datos y el código. Aunque temas como la arquitectura en capas, los patrones de diseño y el diseño del código fuente están relacionados con la arquitectura de software, esa asociación es solo parcialmente cierta. Como se observó, las estrategias formadas por el contexto en el que está inserto el arquitecto de software son indisociables de los principios que guían el diseño, la implementación y la evolución de esos sistemas.
Es fundamental establecer límites, responsabilidades y relaciones de cada componente seleccionado para conformar el mapa de la arquitectura, teniendo en cuenta todas las restricciones impuestas por el entorno y por el objeto observado, cuya representación sistémica se construirá. De esta forma, la arquitectura de software va más allá de los componentes básicos y abarca aspectos más amplios y complejos, que involucran las decisiones y estrategias específicas para cada contexto y proyecto.
Lista de referencias
- What is your definition of software architecture? – Carnegie Mellon University
- Who Needs an Architect? – Martin Fowler
- Frequency Reduces Difficulty – Martin Fowler
- C4 Model – Simon Brown