Architectural decision

A Springer book summarized the state of the art as of 2009,[10] and a systematic mapping study from 2013 [11] compiles and analyzes more and more recent research results.

[14] 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.

Many templates and tools for decision capturing exist, both in agile communities (e.g., M. Nygard's architecture decision records[17]) and in software engineering and architecture design methods (e.g., see table layouts suggested by IBM UMF [18] and by Tyree and Akerman from CapitalOne[19]).

G. Fairbanks included decision rationale in his one-page Architecture Haikus;[20] his notation was later evolved into Y-statements.

Architectural decisions are used in software design; hence they have to be communicated to, and accepted by, the stakeholders of the system that fund, develop, and operate it.

Studies [32][33] of practitioners found that though groups are ideally sized, a structured approach to decision-making is largely lacking.

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