Las evaluaciones de arquitectura de software son instancias formales en las que, haciendo uso de algún método, se analiza si la arquitectura es adecuada para el propósito por el cual se concibe un sistema de software. No corresponde aquí discutir acerca de lo que es concretamente el propósito de un sistema de software, pero sepa el lector que este puede ser eventualmente caracterizado a nivel de escenarios o requisitos de atributos de calidad. Que las evaluaciones sean instancias formales no quiere decir que las arquitectura de software se pueden evaluar solo en iniciativas, sino más bien que al reconocer la instancia como tal dentro de un proceso y hacer uso de un método específico estamos apuntando a la sistematización de las evaluaciones.

Una pregunta que me han hecho en reiteradas ocasiones es: cuándo ejecutar una evaluación de arquitectura. La respuesta no es fácil y si agregamos el hecho de que algunos métodos como ATAM [1] presuponen contar con al menos una idea concreta de arquitectura y otros como ARID [2] se enorgullecen al decir que no requieren de una arquitectura completa, la discusión se torna un tanto más nebulosa.

Evaluar una arquitectura de software requiere reconocer todo el ciclo de diseño de estas. Analizar, por ejemplo, la decisión de tercerizar el sistema de pago en un producto requiere de caracterizar, y muchas veces levantar, los escenarios o requisitos, especialmente aquellos relacionados con atributos de calidad para determinar si las decisiones tomadas son adecuadas o no. Algunos métodos como ATAM [1] ponen énfasis en determinar también cómo estas decisiones se deben balancear con otras decisiones (tradeoffs o compromisos). Podemos decir que cada método hará énfasis en lo que promete atender con prioridad, como es el caso de DCAR [3] que se enfocará en decisiones concretas que deben ser desafiadas en el análisis.

Lo anterior pone de manifiesto que una evaluación de arquitectura puede comenzar tan tempranamente como el visionado mismo del producto de software en cuestión. El modelado de contexto que normalmente se realiza en etapas muy tempranas del desarrollo es una entrada importante para el diseño de una arquitectura de software. Los escenarios, especialmente aquellos que se levantan para propiedades cualitativas del sistema, son muy importantes a la hora de ejecutar una evaluación de arquitectura. Con mayor razón se justifica la inclusión de evaluaciones de arquitectura en etapas tempranas en el contexto del desarrollo ágil: no es de extrañar que ya en el primer Sprint Planning del primer Sprint en Scrum los ingenieros y desarrolladores comiencen a visualizar y diagramar una arquitectura de software (las evaluaciones normalmente se extienden por varios días por lo que es de esperar que en un primer Sprint la evaluación esté presente en una parte considerable de la extensión de este). Las evaluaciones también se pueden ejecutar en forma continua, es decir, a lo largo del desarrollo de un producto de software.

No solo desde un punto de vista temporal es posible discutir la inclusión de evaluaciones de arquitectura. También se puede discutir en términos del tipo de proyecto o iniciativa de desarrollo. Evaluaciones de arquitectura son bienvenidas en el desarrollo de productos [2], migraciones [4], adquisiciones [5] y mantenciones de software [2]. En el caso de las adquisiciones, las evaluaciones de arquitectura pueden incluso comenzar antes de la licitación, donde los resultados de la evaluación serán esenciales para explicitar concretamente los aspectos esperados de la propuesta de software que hagan los oferentes interesados en la licitación.

Finalmente, los resultados de las evaluaciones de arquitecturas de software no terminan en «sí» o «no». Por lo mismo, no corresponde asignar la responsabilidad de tomar decisiones a nivel de proyecto a las evaluaciones. Las evaluaciones terminarán con resultados que serán un input valiosísimo para la toma de decisiones a nivel de proyecto (por ejemplo, ¿continuamos con la migración?) y a nivel estratégico (por ejemplo, ¿estamos en condiciones de ofrecer un software mejor que la competencia?), pero la responsabilidad de tomar esas decisiones será siempre de los las personas que estén asumiendo esos roles.

[1] «ATAM: Method for Architecture Evaluation», Kazman et al. SEI, 2000.

[2] «Evaluating Software Architectures: Methods and Case Studies», Clements et al. Addison-Wesley, 2002.

[3] «Decision-Centric Architecture Reviews», van Heesch et al. IEEE Software, 2013.

[4] «Assessing Migration of a 20-Year-Old System to a Micro-Service Platform Using ATAM», Cruz et al. ICSA-C, 2019.

[5] «The Need for Software Architecture Evaluation in the Acquisition of Software-Intensive Systems», Zhu et al. Australian Government – Department of Decence, 2014.