Editing Software architecture (section)

==Related fields==

=== Design ===
{{main|Software design}}
Architecture is [[Software design|design]] but not all design is architectural.<ref name="DSA2"/> In practice, the architect is the one who draws the line between software architecture (architectural design) and detailed design (non-architectural design). There are no rules or guidelines that fit all cases, although there have been attempts to formalize the distinction. 
According to the ''Intension/Locality Hypothesis'',<ref name="edenkazman">{{cite web |author1=Amnon H. Eden |author2=Rick Kazman |title=Architecture Design Implementation |url=http://www.eden-study.org/articles/2003/icse03.pdf |year=2003 |url-status=dead |archive-url=https://web.archive.org/web/20070928035606/http://eden-study.org/articles/2003/icse03.pdf |archive-date=2007-09-28 }}</ref> the distinction between architectural and detailed design is defined by the ''Locality Criterion'',<ref name="edenkazman"/> according to which a statement about software design is non-local (architectural) if and only if a program that satisfies it can be expanded into a program that does not. For example, the [[client–server]] style is architectural (strategic) because a program that is built on this principle can be expanded into a program that is not client–server—for example, by adding [[peer-to-peer]] nodes.

=== Requirements engineering ===
{{main|Requirements engineering}}
[[Requirements engineering]] and software architecture can be seen as complementary approaches: while software architecture targets the '[[solution space]]' or the 'how', requirements engineering addresses the '[[Computational problem|problem space]]' or the 'what'.<ref name="shekaran94">{{Cite book|author1=C. Shekaran |pages=239–245 |author2=D. Garlan |author3=M. Jackson |author4=N.R. Mead |author5=C. Potts |author6=H.B. Reubenstein |title=Proceedings of IEEE International Conference on Requirements Engineering |chapter=The role of software architecture in requirements engineering |year=1994|doi=10.1109/ICRE.1994.292379 |isbn=978-0-8186-5480-0 |s2cid=3129363 }}</ref> Requirements engineering entails the [[Requirements elicitation|elicitation]], [[Requirements analysis|negotiation]], [[Software Requirements Specification|specification]], [[Data validation|validation]], [[Requirements traceability|documentation]], and [[Requirements management|management]] of [[requirement]]s. Both requirements engineering and software architecture revolve around [[Stakeholder (corporate)|stakeholder]] concerns, needs, and wishes.

There is considerable overlap between requirements engineering and software architecture, as evidenced for example by a study into five industrial software architecture methods that concludes that ''"the inputs (goals, constraints, etc.) are usually ill-defined, and only get discovered or better understood as the architecture starts to emerge"'' and that while ''"most architectural concerns are expressed as requirements on the system, they can also include mandated design decisions"''.<ref name="hofmeister07">{{cite journal|author1=Christine Hofmeister |author2=Philippe Kruchten |author3=Robert L. Nord |author4=Henk Obbink |author5=Alexander Ran |author6=Pierre America |title=A general model of software architecture design derived from five industrial approaches|year=2007|doi=10.1016/j.jss.2006.05.024|journal=Journal of Systems and Software |volume=80 |issue=1  |pages=106–126}}</ref> In short, required behavior impacts solution architecture, which in turn may introduce new requirements.<ref name="boer09">{{Cite journal|author=Remco C. de Boer, [[Hans van Vliet]]|title=On the similarity between requirements and architecture|journal=Journal of Systems and Software|volume=82|issue=3|pages=544–550|year=2009|doi=10.1016/j.jss.2008.11.185|citeseerx=10.1.1.415.6023}}</ref> Approaches such as the Twin Peaks model<ref name="twinpeaks">{{Cite journal|author=Bashar Nuseibeh|title=Weaving together requirements and architectures|journal=Computer|volume=34|issue=3|pages=115–119|year=2001|doi=10.1109/2.910904|url=http://oro.open.ac.uk/2213/1/00910904.pdf |archive-url=https://web.archive.org/web/20120907054241/http://oro.open.ac.uk/2213/1/00910904.pdf |archive-date=2012-09-07 |url-status=live}}</ref> aim to exploit the [[Synergy|synergistic]] relation between requirements and architecture.

=== Other types of 'architecture' ===
{{main|Computer architecture|Systems architecture|Enterprise architecture}}

;Computer architecture 
:[[Computer architecture]] targets the internal structure of a computer system, in terms of collaborating hardware components such as the [[Central processing unit|CPU]] – or processor – the [[Bus (computing)|bus]] and the [[Computer memory|memory]].

;Serverless architecture
:Serverless architecture is a cloud computing paradigm that is often misunderstood as being server-free. It essentially shifts server management responsibilities from developers to cloud service providers. This allows businesses to run their backend code on cloud infrastructure, eliminating the need for physical server management. The event-driven approach of serverless architecture relies on small, task-specific functions that are executed on-demand. These functions are known as Function as a Service (FaaS), and they offer cost-efficiency through a pay-as-you-go billing model and dynamic resource scaling based on application demand.<ref>{{Cite web |last=Company |first=DashDevs {{!}} FinTech Software Development |title=How to Use Serverless Architecture {{!}} DashDevs |url=https://dashdevs.com/blog/how-to-use-serverless-architecture/ |access-date=2023-08-28 |website=How to Use Serverless Architecture {{!}} DashDevs |language=en}}</ref>{{Better source needed|date=November 2023}}

;Systems architecture
:The term [[systems architecture]] has originally been applied to the architecture of [[system]]s that consist of both hardware and [[software]]. The main concern addressed by the systems architecture is then the integration of software and hardware in a complete, correctly working device. In another common – much broader – meaning, the term applies to the architecture of any complex system which may be of a technical, [[Sociotechnical system|sociotechnical]] or social nature.

;Enterprise architecture
:The goal of [[enterprise architecture]] is to "translate business vision and strategy into effective enterprise". Enterprise architecture [[Architecture framework|frameworks]], such as [[TOGAF]] and the [[Zachman Framework]], usually distinguish between different enterprise architecture layers. Although terminology differs from framework to framework, many include at least a distinction between a ''[[business]] layer'', an ''[[Application software|application]]'' (or ''[[information]]'') ''layer'', and a ''[[technology]] layer''. Enterprise architecture addresses among others the alignment between these layers, usually in a top-down approach.