Community hub
Recent from talks
Contribute something to knowledge base
Content stats: 0 posts, 0 articles, 0 media, 0 notes
Members stats: 0 subscribers, 0 contributors, 0 moderators, 0 supporters
Subscribers
Supporters
Contributors
Moderators
Architectural decision
In software engineering and software architecture design, architectural decisions are design decisions that address architecturally significant requirements; they are perceived as hard to make and/or costly to change.
Architectural decisions influence and impact the non-functional characteristics of a system. Each architectural decision describes a concrete, architecturally significant design issue (a.k.a. design problem, decision required) for which several potential solutions (a.k.a. options, alternatives) exist. An architectural decision captures the result of a conscious, often collaborative option selection process and provides design rationale for the decision making outcome, e.g., by referencing one or more of the quality attributes addressed by the architectural decision and answering "why" questions about the design and option selection. Architectural decisions concern a software system as a whole, or one or more of the core components of such a system. Types of architectural decisions are the selection of architectural tactics and patterns, of integration technologies, and of middleware, as well as related implementation strategies and assets (both commercial products and open source projects).
Software architecture design is a wicked problem, therefore architectural decisions are difficult to get right. Often, no single optimal solution for any given set of architecture design problems exists. Architectural decision making is a core responsibility of software architects; additional motivation for/of the importance of architectural decisions as a first-class concept in software architecture can be found online.
Rationale was mentioned in an early definition of software architecture by Perry/Woolf, but not researched much until 2004, when a workshop on architectural decisions and Architectural Knowledge Management was held in Groningen, NL. Early publications can be traced back to this workshop,. From 2006 on, the architectural knowledge management and architectural decision research communities gained momentum and a number of papers was published at major software architecture conferences such as European Conference on Software Architecture (ECSA), Quality of Software Architecture (QoSA) and (Working) International Conference on Software Architecture (ICSA). A Springer book summarized the state of the art as of 2009, and a systematic mapping study from 2013 compiles and analyzes more and more recent research results.
In practice, the importance of making the correct decisions has always been recognized, for instance in software development processes such as OpenUP; many templates and practices for decision documentation exist. Seven of these templates are compared in. The most recent standard for architecture descriptions, ISO/IEC/IEEE 42010:2011 has a dedicated rationale entity, and gives detailed recommendations which architectural decisions to capture and which properties of an architectural decision to record in the decision log.
Before a decision can be made, the need for a decision must be articulated: how urgent and how important is the AD? Does it have to be made now or can it wait until more is known about requirements and system under construction? Both personal and collective experience, as well as recognized design methods and practices, can assist with decision identification; it has been proposed that Agile software development team should maintain a decision backlog complementing the product backlog of the project.
Identified decisions can only be made if certain criteria are met, which form a definition of ready for AD making: (1) Stakeholders have been identified, (2) Time is right, (3) Alternatives (aka options) listed, (4) Requirements and other criteria defined, (5) ADR Template chosen.
A number of decision making techniques exists, both general ones and software and software architecture specific ones, for instance, dialogue mapping. Group decision making is an active research topic.
Architectural decision
In software engineering and software architecture design, architectural decisions are design decisions that address architecturally significant requirements; they are perceived as hard to make and/or costly to change.
Architectural decisions influence and impact the non-functional characteristics of a system. Each architectural decision describes a concrete, architecturally significant design issue (a.k.a. design problem, decision required) for which several potential solutions (a.k.a. options, alternatives) exist. An architectural decision captures the result of a conscious, often collaborative option selection process and provides design rationale for the decision making outcome, e.g., by referencing one or more of the quality attributes addressed by the architectural decision and answering "why" questions about the design and option selection. Architectural decisions concern a software system as a whole, or one or more of the core components of such a system. Types of architectural decisions are the selection of architectural tactics and patterns, of integration technologies, and of middleware, as well as related implementation strategies and assets (both commercial products and open source projects).
Software architecture design is a wicked problem, therefore architectural decisions are difficult to get right. Often, no single optimal solution for any given set of architecture design problems exists. Architectural decision making is a core responsibility of software architects; additional motivation for/of the importance of architectural decisions as a first-class concept in software architecture can be found online.
Rationale was mentioned in an early definition of software architecture by Perry/Woolf, but not researched much until 2004, when a workshop on architectural decisions and Architectural Knowledge Management was held in Groningen, NL. Early publications can be traced back to this workshop,. From 2006 on, the architectural knowledge management and architectural decision research communities gained momentum and a number of papers was published at major software architecture conferences such as European Conference on Software Architecture (ECSA), Quality of Software Architecture (QoSA) and (Working) International Conference on Software Architecture (ICSA). A Springer book summarized the state of the art as of 2009, and a systematic mapping study from 2013 compiles and analyzes more and more recent research results.
In practice, the importance of making the correct decisions has always been recognized, for instance in software development processes such as OpenUP; many templates and practices for decision documentation exist. Seven of these templates are compared in. The most recent standard for architecture descriptions, ISO/IEC/IEEE 42010:2011 has a dedicated rationale entity, and gives detailed recommendations which architectural decisions to capture and which properties of an architectural decision to record in the decision log.
Before a decision can be made, the need for a decision must be articulated: how urgent and how important is the AD? Does it have to be made now or can it wait until more is known about requirements and system under construction? Both personal and collective experience, as well as recognized design methods and practices, can assist with decision identification; it has been proposed that Agile software development team should maintain a decision backlog complementing the product backlog of the project.
Identified decisions can only be made if certain criteria are met, which form a definition of ready for AD making: (1) Stakeholders have been identified, (2) Time is right, (3) Alternatives (aka options) listed, (4) Requirements and other criteria defined, (5) ADR Template chosen.
A number of decision making techniques exists, both general ones and software and software architecture specific ones, for instance, dialogue mapping. Group decision making is an active research topic.