Editing Software architecture (section)

== Characteristics ==
Software architecture exhibits the following:

'''Multitude of stakeholders:''' software systems have to cater to a variety of stakeholders such as business managers, owners, users, and operators. These stakeholders all have their own concerns with respect to the system. Balancing these concerns and demonstrating that they are addressed is part of designing the system.<ref name="SAP2" />{{rp|29–31}} This implies that architecture involves dealing with a broad variety of concerns and stakeholders, and has a multidisciplinary nature.

'''[[Separation of concerns]]:''' the established way for architects to reduce complexity is to separate the concerns that drive the design. Architecture documentation shows that all stakeholder concerns are addressed by modeling and describing the architecture from separate points of view associated with the various stakeholder concerns.<ref name="ISO42010"/> These separate descriptions are called architectural views (see for example the [[4+1 architectural view model]]).

'''Quality-driven:''' classic [[software design]] approaches (e.g. [[Jackson Structured Programming]]) were driven by required functionality and the flow of data through the system, but the current insight<ref name="SAP2"/>{{rp|26–28}} is that the architecture of a software system is more closely related to its [[quality attributes]] such as [[fault-tolerance]], [[backward compatibility]], [[extensibility]], [[reliability (engineering)|reliability]], [[maintainability]], [[availability]], security, usability, and other such –[[ilities]]. Stakeholder concerns often translate into [[requirements]] on these quality attributes, which are variously called [[non-functional requirements]], extra-functional requirements, behavioral requirements, or quality attribute requirements.

'''Recurring styles:''' like building architecture, the software architecture discipline has developed standard ways to address recurring concerns. These "standard ways" are called by various names at various levels of abstraction. Common terms for recurring solutions are architectural style,<ref name="FAIRBANKS2010"/>{{rp|273–277}} tactic,<ref name="SAP2"/>{{rp|70–72}} [[reference architecture]] and [[architectural pattern]].<ref name="REFARCHPRIMER">{{cite web |url=http://www.gaudisite.nl/ReferenceArchitecturePrimerPaper.pdf |archive-url=https://web.archive.org/web/20111219235909/http://www.gaudisite.nl/ReferenceArchitecturePrimerPaper.pdf |archive-date=2011-12-19 |url-status=live |title=A Reference Architecture Primer |last1=Muller |first1=Gerrit |date=August 20, 2007 |website=Gaudi site |access-date=November 13, 2015}}</ref><ref name="REFARCHCLASS">{{cite book |last1=Angelov |first1=S. |last2=Grefen |first2=P. |last3=Greefhorst |first3=D. |title=2009 Joint Working IEEE/IFIP Conference on Software Architecture & European Conference on Software Architecture |chapter=A classification of software reference architectures: Analyzing their success and effectiveness | url=https://ieeexplore.ieee.org/document/5290800| publisher=IEEE| pages=141–150 |year=2009| access-date=15 December 2023| doi=10.1109/WICSA.2009.5290800|isbn=978-1-4244-4984-2}}</ref><ref name="SAP2"/>{{rp|203–205}}

'''Conceptual integrity:''' a term introduced by [[Fred Brooks]] in his 1975 book ''[[The Mythical Man-Month]]'' to denote the idea that the architecture of a software system represents an overall vision of what it should do and how it should do it. This vision should be separated from its implementation. The architect assumes the role of "keeper of the vision", making sure that additions to the system are in line with the architecture, hence preserving [[The Mythical Man-Month#Conceptual integrity|conceptual integrity]].<ref name="BROOKS">{{cite book | last=Brooks | first=Frederick P. Jr. |date=1975|title=The Mythical Man-Month – Essays on Software Engineering |publisher=Addison-Wesley |isbn=978-0-201-00650-6|title-link=The Mythical Man-Month }}</ref>{{rp|41–50}}

'''Cognitive constraints:''' An observation first made in a 1967 paper by computer programmer [[Melvin Conway]] that organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.<ref>{{cite web|url=http://www.melconway.com/Home/Conways_Law.html|title=Conway's Law|last=Conway|first=Melvin|website=Mel Conway's Home Page|url-status=live|archive-url=https://web.archive.org/web/20190929004831/http://www.melconway.com/Home/Conways_Law.html|archive-date=2019-09-29|access-date=2019-09-29}}</ref> Fred Brooks introduced it to a wider audience when he cited the paper and the idea in ''The Mythical Man-Month'', calling it [[Conway's law|Conway's Law]].