In software engineering and

software architecture Software architecture is the fundamental structure of a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations. ...

design, architectural decisions are design decisions that address architecturally significant requirements; they are perceived as hard to make and/or costly to change.

Characteristics

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 A design rationale is an explicit documentation of the reasons behind decisions made when designing a system or artifact. As initially developed by W.R. Kunz and Horst Rittel, design rationale seeks to provide argumentation-based structure to ...

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 In planning and policy, a wicked problem is a problem that is difficult or impossible to solve because of incomplete, contradictory, and changing requirements that are often difficult to recognize. It refers to an idea or problem that cannot be fi ...

, 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.

History

Rationale was mentioned in an early definition of

by Perry/Woolf, but not researched much until 2004, when a workshop on architectural decisions and Architectural

Knowledge Management Knowledge management (KM) is the collection of methods relating to creating, sharing, using and managing the knowledge and information of an organization. It refers to a multidisciplinary approach to achieve organisational objectives by making ...

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.

Decision management steps

Decision identification

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 In software development, agile (sometimes written Agile) practices include requirements discovery and solutions improvement through the collaborative effort of self-organizing and cross-functional teams with their customer(s)/ end user(s), ...

team should maintain a ''decision backlog'' complementing the product backlog of the project.

Decision making

A number of decision making techniques exists, both general ones and software and software architecture specific ones, for instance,

dialogue mapping The issue-based information system (IBIS) is an argumentation-based approach to clarifying wicked problems—complex, ill-defined problems that involve multiple stakeholders. Diagrammatic visualization using IBIS notation is often called issue ...

. ''Group decision making'' is an active research topic.

Decision documentation

Many templates and tools for decision capturing exist, both in agile communities (e.g., M. Nygard's architecture decision records) and in software engineering and architecture design methods (e.g., see table layouts suggested by IBM UMF and by Tyree and Akerman from CapitalOne. G. Fairbanks included decision rationale in his one-page Architecture Haikus; his notation was later evolved into Y-statements. See for motivation, examples, comparisons.

Decision enactment (enforcement)

Architectural decisions are used in

software design Software design is the process by which an agent creates a specification of a software artifact intended to accomplish goals, using a set of primitive components and subject to constraints. Software design may refer to either "all the activi ...

; hence they have to be communicated to, and accepted by, the stakeholders of the system that fund, develop, and operate it. ''Architecturally evident coding styles'' and code reviews that focus on architectural concerns and decisions are two related practices. Architectural decisions also have to be considered when modernizing a software system in

software evolution Software evolution is the continual development of a piece of software after its initial release to address changing stakeholder and/or market requirements. Software evolution is important because organizations invest large amounts of money in the ...

Decision sharing (optional step)

Many architectural decisions recur across projects; hence, experiences with past decisions, both good and bad, can be valuable reusable assets when employing an explicit knowledge management strategy.

Examples

On large scale projects, the number of architectural decisions to be made can exceed 100, including: * Selection of architectural layering scheme and individual layer responsibilities (when adopting the Layers pattern from ) * Choice of implementation technology per layer, component, and connector (e.g., programming language, interface contract format, XML vs. JSON when designing integration interfaces and message exchanges) * Choice of presentation layer frameworks on client side (e.g., JavaScript frameworks) and on the server side (e.g., Java and PHP frameworks) Refer to the design concept catalogs in Attribute-Driven Design 3.0 and domain-specific decision guidance models for more examples. This is an example of a decision made, which is formatted according to the Y-statement template proposed in: ''“In the context of the Web shop service, facing the need to keep user session data consistent and current across shop instances, we decided for the Database Session State Pattern (and against Client Session State or Server Session State) to achieve cloud elasticity, accepting that a session database needs to be designed, implemented, and replicated.”''

Templates

Many templates have been suggested by practicing architects and by software architecture researchers. GitHub repositories such as "Architecture decision record (ADR)" and "Markdown Architectural Decision Records" collect many of them, as well as links to tools and writing hints.

Software Architecture Group Decision Making

Both practitioners and researchers recognize that software architecture decision-making is a group process that involves several stakeholders discussing, evaluating and shortlisting architectural decisions. Studies of practitioners found that though groups are ideally sized, a structured approach to decision-making is largely lacking. Specifically: * There is a predominance of unstructured approach to decision-making. This limits the participation of group members. * There is a lack of collaborative tool support to assist architects in the decision-making process. * Architects often experience delays and omissions in the decision-making process due to lack a of a structured approach * Architecting teams experience challenges including

Groupthink Groupthink is a psychological phenomenon that occurs within a group of people in which the desire for harmony or conformity in the group results in an irrational or dysfunctional decision-making outcome. Cohesiveness, or the desire for cohesiveness ...

and

Group polarization In social psychology, group polarization refers to the tendency for a group to make decisions that are more extreme than the initial inclination of its members. These more extreme decisions are towards greater risk if individuals' initial tendenci ...

These challenges provide good scope for experimentation and research for the software architecture community.

References

{{Reflist Software architecture