La arquitectura siempre está. En los mejores casos, es consciente. En los que no, es casual. En los peores, se la ignora. Antes de adentrarnos en el tema de competencia, la Arquitectura de Software, hagamos un breve repaso, con una visión holística, de la más amplia aceptación, de la Arquitectura en el contexto de la TI.

Esta es la Arquitectura de la Empresa, o Arquitectura Empresarial. Marcos de referencia reconocidos mundialmente incluyen en esta desde los aspectos organizacionales, capacidades de la organización, aspectos estratégicos, metas, fortalezas y debilidades, etc. hasta la evolución planeada en el tiempo de los cambios esenciales en infraestructura con el propósito de prever cambios tecnológicos, evolutivos o disruptivos, y evitar riesgos por obsolescencia. Y, desde luego, pasando también por la visión arquitectónica de procesos de negocio, aplicaciones e información, y el soporte de infraestructura tecnológica (HW, SW de base, redes), alineados con las necesidades de negocio (no necesariamente económicas o financieras) de la Empresa.


Foto de Fotis Fotopoulos en Unsplash

El “tándem” Procesos-Aplicaciones+Información-Infraestructura es lo que también se conoce como “Arquitectura de Solución”. Dentro de ella, es que podemos identificar a la Arquitectura de Software: la arquitectura de las aplicaciones y la información que procesan y transforman, expresada por sus componentes y elementos de datos esenciales que se interrelacionan, trabajan colaborativamente para propender a alcanzar los objetivos de negocio, así como las guías para su diseño, realización y evolución en tiempo. Esta descripción no es caprichosa, y se alinea perfectamente con las definiciones conocidas de Arquitectura (ISO/IEC/IEEE 42010:2011, OG).

Por otra parte, la Arquitectura de Software está subsumida dentro de la Ingeniería de Software, siendo el Software Engineering Institute (SEI) el principal referente de este campo. La Ingeniería de Software implica la aplicación sistemática de los principios utilizados en el campo de la ingeniería, que generalmente se ocupa de los sistemas físicos, al diseño, desarrollo, prueba, implementación y gestión de sistemas de software, con el grado de calidad, eficiencia en tiempos y presupuestos requeridos.

Queda claro entonces, cuán importante es asegurar una buena Arquitectura de Software cuando se debe abordar un nuevo proyecto. En primer lugar, la brújula son las necesidades del negocio, manifestadas a través de los procesos. Luego, el aseguramiento de la calidad del diseño del software, a partir del reconocimiento de los atributos de calidad y el planteo estratégico necesario para dar satisfacción a estos. Ejemplos de atributos de calidad son la facilidad de mantenimiento, la extensibilidad, el desempeño, la simplicidad, facilidad para que el SW pueda escalar, interoperabilidad, fiabilidad, facilidad para su evolución (flexibilidad ante los cambios), seguridad, facilidad para realizar pruebas, alta tasa de nuevas entregas.
El dar respuesta a estos atributos de calidad, además los requerimientos funcionales propios de la solución, permiten pensar en soluciones de software con claros beneficios a largo plazo: previsibilidad de la evolución, adecuada gestión de cambios, definición clara de “mesetas” de arquitecturas estables y confiables, gobernanza de las arquitecturas.

¿Cómo lograrlo? Se tiene un gran número de marcos de referencia de arquitectura fácilmente identificables y hallables en la web es uno de los más populares (The TOGAF® Standard). Sin embargo, no existe una “bala de plata” ni recetas que garanticen, mucho menos que aseguren, mediante su aplicación rigurosa, el éxito que representa una arquitectura adecuada y correcta para un conjunto dado de requerimientos. A pesar de esto, siempre es posible encontrar, tomando lo que mejor se adapte a la organización de nuestra incumbencia, el marco metodológico, las herramientas y el soporte que faciliten la tarea, y vale la pena el esfuerzo de definirlos e identificarlos. Particularmente, contar con un repositorio gobernado de Arquitectura es un facilitador de los beneficios a largo plazo mencionados previamente.

Otro aspecto a considerar es la metodología de desarrollo. O mejor aún, de qué manera se ajusta la práctica de Arquitectura a una metodología ágil, dada la importancia de éstas en el estado actual. Claramente, las Metodologías Ágiles, hace tiempo ya que han marcado una tendencia innegable en su adopción para desarrollo de proyectos de software, dado las necesidades cambiantes que naturalmente se dan en estos proyectos y la necesidad de obtener beneficios en el menor tiempo posible. Por otro lado, la Arquitectura de Software se ha mostrado históricamente como una actividad necesaria para dar como resultado decisiones de diseño tempranas. Sin embargo, esto no debiera ser así; la Arquitectura no debe pensarse como una actividad “one shot”, sino que debe evolucionar y adecuarse al carácter cambiante de los proyectos de SW. En tal sentido, cabe destacar el concepto de “Arquitectura Ágil”. Como ejemplo, caben destacarse las iniciativas del Open Group para el (“Open Agile Architecture™”) y del SEI del Carnegie Mellon University, desde hace ya un tiempo considerable, abordando la integración de la práctica de la Arquitectura de Software en metodologías tales como Scrum, XP y DevOps (Carnegie Mellon University – Software Engineering Institute).

Simplificando el tema, puede decirse que se propone extender el alcance de la elaboración de historias de usuario, HU. Generalmente, las HU recopiladas se priorizan según las necesidades del usuario final, con un enfoque altamente funcional. Pero casi todas las historias tienen dependencias con otras historias, y aunque tal vez menos evidente, también tienen dependencias sobre los elementos arquitectónicos del sistema.

Una buena definición de Agilidad Arquitectónica es tener la capacidad de identificar y analizar estas dependencias e incorporar la conciencia de dependencia en un modelo de desarrollo sensible y receptivo a los cambios. Se agregan, entrelazadas con las actividades típicas de las metodologías ágiles, actividades de arquitectura que abordan estas consideraciones adicionales, dando una nueva dimensión a la típica planificación de versiones ágiles. Las HU se enriquecen con un análisis de abordaje más amplio de las capacidades, reemplazándolas, incluyendo los requisitos de atributos de calidad, que fueran mencionados previamente. Además, se facilita un enfoque "justo a tiempo" (es decir, sólo con la anticipación suficiente) para construir la infraestructura arquitectónica y optimizar las decisiones de inversión en arquitectura mediante el análisis de la incertidumbre y las compensaciones entre el costo incurrido y el valor anticipado (Carnegie Mellon University – Software Engineering Institute –Agile Architecting).

Este enfoque permite incorporar una gestión e implementación de versiones efectivas, incluyendo la gestión de deudas técnicas. Esto requiere técnicas y herramientas de diseño y análisis para respaldar no solo las prácticas de desarrollo, sino también una implementación confiable, sólida y segura. Por ejemplo, un subconjunto de patrones y tácticas de diseño mejora la eficacia de las prácticas relacionadas con la implementación, como la integración continua, las pruebas automatizadas y la entrega continua.

Finalmente, cabe mencionar, dentro de los intereses naturales de la Arquitectura de Software, la necesidad siempre presente de prestar atención a la evolución continua de la tecnología, que da lugar a nuevos patrones arquitectónicos y de diseño (y también, a la necesidad de detectar también nuevos anti patrones). Particularmente destaco que se avecina un fuerte establecimiento de modelos responsivos orientados a eventos y arquitecturas de streaming en (casi) tiempo real, procesamiento y disponibilidad de información al vuelo, alimentando fuentes de datos de las más diversas naturalezas (documentales, No SQL, relacionales clásicas), combustible de modelos de IA (Apache Kakfa).

(*) Gustavo Antonelli: Arquitecto de Software Sr. de Liveware I.S.