En ingeniería de software y diseño de arquitectura de software , las decisiones arquitectónicas son decisiones de diseño que abordan requisitos arquitectónicamente significativos ; se perciben como difíciles de tomar [1] y/o costosas de cambiar. [2]
Las decisiones arquitectónicas influyen e impactan las características no funcionales de un sistema. Cada decisión arquitectónica describe un problema de diseño concreto y arquitectónicamente significativo (también conocido como problema de diseño, decisión requerida) para el cual existen varias soluciones potenciales (también conocidas como opciones, alternativas). Una decisión arquitectónica captura el resultado de un proceso de selección de opciones consciente, a menudo colaborativo, y proporciona una justificación de diseño para el resultado de la toma de decisiones, por ejemplo, haciendo referencia a uno o más de los atributos de calidad abordados por la decisión arquitectónica y respondiendo preguntas de "por qué" sobre el diseño y la selección de opciones. Las decisiones arquitectónicas se refieren a un sistema de software en su totalidad, o a uno o más de los componentes centrales de dicho sistema. Los tipos de decisiones arquitectónicas son la selección de tácticas y patrones arquitectónicos, de tecnologías de integración y de middleware, así como de estrategias y activos de implementación relacionados (tanto productos comerciales como proyectos de código abierto). [3]
El diseño de la arquitectura de software es un problema complejo [4] , por lo que es difícil tomar decisiones arquitectónicas correctas. A menudo, no existe una única solución óptima para un conjunto determinado de problemas de diseño arquitectónico. La toma de decisiones arquitectónicas es una responsabilidad fundamental de los arquitectos de software; [5] En Internet se pueden encontrar motivaciones adicionales a favor o en contra de la importancia de las decisiones arquitectónicas como un concepto de primera clase en la arquitectura de software. [6]
La justificación se mencionó en una definición temprana de arquitectura de software por Perry/Woolf, [7] pero no se investigó mucho hasta 2004, cuando se celebró un taller sobre decisiones arquitectónicas y gestión del conocimiento arquitectónico en Groningen, Holanda. Las primeras publicaciones se remontan a este taller. [8] [9] A partir de 2006, las comunidades de investigación de gestión del conocimiento arquitectónico y decisiones arquitectónicas ganaron impulso y se publicaron varios artículos en las principales conferencias de arquitectura de software, como la Conferencia Europea sobre Arquitectura de Software (ECSA), la Calidad de la Arquitectura de Software (QoSA) y la Conferencia Internacional (de Trabajo) sobre Arquitectura de Software (ICSA). Un libro de Springer resumió el estado del arte a partir de 2009, [10] y un estudio de mapeo sistemático de 2013 [11] recopila y analiza cada vez más resultados de investigación recientes.
En la práctica, siempre se ha reconocido la importancia de tomar las decisiones correctas, por ejemplo, en los procesos de desarrollo de software como OpenUP; existen muchas plantillas y prácticas para la documentación de decisiones. En [12] se comparan siete de estas plantillas. La norma más reciente para descripciones de arquitectura, ISO/IEC/IEEE 42010:2011, tiene una entidad de fundamentos dedicada y ofrece recomendaciones detalladas sobre qué decisiones arquitectónicas capturar y qué propiedades de una decisión arquitectónica registrar en el registro de decisiones. [13]
Antes de tomar una decisión, se debe articular la necesidad de tomarla: ¿qué tan urgente e importante es el AD? ¿Se debe tomar ahora o se puede esperar hasta que se conozca más sobre los requisitos y el sistema en construcción? Tanto la experiencia personal como la colectiva, así como los métodos y prácticas de diseño reconocidos, pueden ayudar a la identificación de decisiones; se ha propuesto que el equipo de desarrollo de software ágil mantenga una lista de decisiones pendientes que complemente la lista de productos pendientes del proyecto. [14]
Las decisiones identificadas solo se pueden tomar si se cumplen ciertos criterios, que forman una definición de preparación para la toma de decisiones: (1) Se han identificado las partes interesadas, (2) Es el momento adecuado, (3) Se enumeran las alternativas (también conocidas como opciones), (4) Se definen los requisitos y otros criterios, (5) Se elige la plantilla de ADR. [15]
Existe una serie de técnicas de toma de decisiones, tanto generales como específicas del software y de la arquitectura del software, por ejemplo, el mapeo de diálogo . [16] La toma de decisiones en grupo es un tema de investigación activo.
Existen muchas plantillas y herramientas para la captura de decisiones, tanto en comunidades ágiles (por ejemplo, los registros de decisiones de arquitectura de M. Nygard [17] ) como en métodos de diseño de arquitectura e ingeniería de software (por ejemplo, consulte los diseños de tabla sugeridos por IBM UMF [18] y por Tyree y Akerman de CapitalOne. [19] G. Fairbanks incluyó la justificación de las decisiones en sus Haikus de arquitectura de una página; [20] su notación luego evolucionó a declaraciones Y. Consulte [21] para obtener motivación, ejemplos y comparaciones.
Las decisiones arquitectónicas se utilizan en el diseño de software , por lo que deben ser comunicadas a las partes interesadas del sistema que lo financian, desarrollan y operan, y aceptadas por ellas. Los estilos de codificación arquitectónicamente evidentes [22] y las revisiones de código que se centran en las preocupaciones y decisiones arquitectónicas son dos prácticas relacionadas.
Las decisiones arquitectónicas también deben considerarse al modernizar un sistema de software en la evolución del software .
Muchas decisiones arquitectónicas se repiten en distintos proyectos; por lo tanto, las experiencias con decisiones pasadas, tanto buenas como malas, pueden ser activos reutilizables valiosos cuando se emplea una estrategia explícita de gestión del conocimiento. [23]
Es importante saber cuándo se puede considerar que una decisión arquitectónica está hecha. Se han propuesto cinco elementos para definir lo que está hecho: evidencia, criterios, acuerdo, documentación y realización/revisión. [24]
En proyectos de gran escala, el número de decisiones arquitectónicas a tomar puede superar las 100, entre ellas:
Consulte los catálogos de conceptos de diseño en Attribute-Driven Design 3.0 [26] y los modelos de orientación de decisiones específicos del dominio [27] para obtener más ejemplos.
Este es un ejemplo de una decisión tomada, que está formateada de acuerdo con la plantilla de declaración Y propuesta en: [28]
“En el contexto del servicio de tienda web, frente a la necesidad de mantener los datos de las sesiones de los usuarios consistentes y actualizados en todas las instancias de la tienda, decidimos utilizar el Patrón de estado de sesión de base de datos (y contra el Patrón de estado de sesión del cliente o el Patrón de estado de sesión del servidor) [29] para lograr elasticidad en la nube, aceptando que es necesario diseñar, implementar y replicar una base de datos de sesiones”.
Los arquitectos en ejercicio y los investigadores de la arquitectura de software han sugerido muchas plantillas. Los repositorios de GitHub como "Architecture decision record (ADR)" [30] y "Markdown Architectural Decision Records" [31] recopilan muchas de ellas, así como enlaces a herramientas y sugerencias de escritura.
Tanto los profesionales como los investigadores reconocen que la toma de decisiones sobre la arquitectura de software es un proceso grupal que involucra a varias partes interesadas que discuten, evalúan y seleccionan las decisiones arquitectónicas. Los estudios [32] [33] de profesionales encontraron que, si bien los grupos tienen el tamaño ideal, falta en gran medida un enfoque estructurado para la toma de decisiones. En concreto:
Estos desafíos brindan un buen margen para la experimentación y la investigación para la comunidad de arquitectura de software.