Software architecture: Difference between revisions

Revision as of 20:33, 15 March 2020

Latest revision as of 10:49, 27 August 2025

(127 intermediate revisions by 76 users not shown)

Line 1:

{{short description|High level structures of a software system}}

{{Software development process}}

'''Software architecture''' refers tois the fundamentalset of structures ofneeded to reason about 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.<ref name="DSA2">{{cite book |last=Clements |first=Paul |title=Documenting Software Architectures: Views and Beyond, Second Edition |author2=Felix Bachmann |author3-link=Len Bass|author3=Len Bass |author4=David Garlan |author5=James Ivers |author6=Reed Little |author7=Paulo Merson |author8=Robert Nord |author9=Judith Stafford |title=Documenting Software Architectures: Views and Beyond, Second Edition|publisher = Addison-Wesley |year=2010|___location=Boston |isbn=978-0-321-55268-6}}</ref> The ''architecture'' of a software system is a metaphor, analogous to the [[architecture]] of a building.<ref name="PERRY1992">{{Cite journal | last1 ___location= PerryBoston | first1 language= D. E. | last2 = Wolf | first2 = A. L. | authorlink2 = Alexander L. Wolf| doi = 10.1145/141874.141884 | title = Foundations for the study of software architecture | journal = [[ACM SIGSOFT Software Engineering Notes]]| volume = 17 | issue = 4 | pages = 40 | year = 1992 | url = http://users.ece.utexas.edu/~perry/work/papers/swaen-sen.pdf| citeseerx = 10.1.1.40.5174 }}</ref> It functions as a blueprint for the system and the developing project, laying out the tasks necessary to be executed by the design teams.<ref>{{CiteUS web|url=https://www.sei.cmu.edu/researchauthor3-capabilities/all-work/display.cfm?customel_datapageid_4050link=21328|title=SoftwareLen Architecture|website=www.sei.cmu.edu|language=en|access-date=2018-07-23Bass}}</ref>

The ''architecture'' of a software system is a [[metaphor]], analogous to the [[architecture]] of a building.<ref name="PERRY1992">{{Cite journal | last1 = Perry | first1 = D. E. | last2 = Wolf | first2 = A. L. | author-link2 = Alexander L. Wolf| doi = 10.1145/141874.141884 | title = Foundations for the study of software architecture | journal = [[ACM SIGSOFT Software Engineering Notes]]| volume = 17 | issue = 4 | pages = 40 | year = 1992 | url = http://users.ece.utexas.edu/~perry/work/papers/swa-sen.pdf| citeseerx = 10.1.1.40.5174 | s2cid = 628695 }}</ref> It functions as the blueprints for the system and the development project, which [[project management]] can later use to extrapolate the tasks necessary to be executed by the teams and people involved.

Software architecture is about making fundamental structural choices that are costly to change once implemented. Software architecture choices include specific structural options from possibilities in the design of the software. For example, the systems that controlled the [[Space Shuttle]] launch vehicle had the requirement of being very fast and very reliable. Therefore, an appropriate [[real-time computing]] language would need to be chosen. Additionally, to satisfy the need for reliability the choice could be made to have multiple redundant and independently produced copies of the program, and to run these copies on independent hardware while cross-checking results.

Software architecture is about making fundamental structural choices that are costly to change once implemented. Software architecture choices include specific structural options from possibilities in [[Software design|the design of the software]]. There are two fundamental laws in software architecture:<ref>{{Cite book |title=Head First Software Architecture |publisher=O'Reilly Media |year=2024 |isbn=978-1098134358}}</ref><ref name="O'Reilly Media">{{Cite book |title=Fundamentals of Software Architecture: An Engineering Approach |publisher=O'Reilly Media |year=2020 |isbn=978-1492043454}}</ref>

Documenting software architecture facilitates communication between [[Stakeholder (corporate)#In management|stakeholders]], captures early decisions about the high-level design, and allows reuse of design components between projects.<ref name="SAP2">{{cite book|last=Bass|first=Len|author2=Paul Clements |author3=Rick Kazman |title=Software Architecture in Practice, Third Edition|publisher = Addison-Wesley|year=2012|___location=Boston|isbn=978-0-321-81573-6}}</ref>{{rp|29–35}}

# Everything is a trade-off

# "Why is more important than how"

"Architectural Kata" is a teamwork which can be used to produce an architectural solution that fits the needs. Each team extracts and prioritizes architectural characteristics (aka [[Non-functional requirement|non functional requirements]]) then models the components accordingly. The team can use [[C4 model|C4 Model]] which is a flexible method to model the architecture just enough. Note that synchronous communication between architectural components, entangles them and they must share the same architectural characteristics. <ref name="O'Reilly Media" />

[[Software documentation|Documenting software]] architecture facilitates communication between [[Stakeholder (corporate)#In management|stakeholders]], captures early decisions about the high-level design, and allows the reuse of design components between projects.<ref name="SAP2">{{cite book|last=Bass|first=Len|author2=Paul Clements |author3=Rick Kazman |title=Software Architecture in Practice, Third Edition|publisher = Addison-Wesley|year=2012|___location=Boston|isbn=978-0-321-81573-6}}</ref>{{rp|29–35}}

Software architecture design is commonly juxtaposed with [[software application design]]. Whilst application design focuses on the design of the processes and data supporting the required functionality (the services offered by the system), software architecture design focuses on designing the infrastructure within which application functionality can be realized and executed such that the functionality is provided in a way which meets the system's [[non-functional requirement]]s.

Software architectures can be categorized into two main types: [[Monolithic application|monolith]] and [[Distributed computing|distributed architecture]], each having its own subcategories.<ref name="O'Reilly Media"/>

Software architecture tends to become more complex over time. [[Software architect]]s should use "[[fitness function]]s" to [[Continuous design|continuously]] keep the architecture in check.<ref name="O'Reilly Media"/>

[[File:Software Architecture Activities.jpg|thumb|Software architecture activities]]

==Scope==

Opinions vary as to the scope of software architectures:<ref>{{cite web|author=SEI|title= How do you define Software Architecture?|url= http://www.sei.cmu.edu/architecture/start/glossary/definition-form.cfm |year=2006|accessdateaccess-date=2012-09-12}}</ref>

* '''Macroscopic system structure''': this refers to architecture as a higher-level [[Abstraction (computer science)|abstraction]] of a software system that consists of a collection of computational ''components'' together with ''connectors'' that describe the interaction between these components.<ref>{{cite web|author=Garlan & Shaw |title= An Introduction to Software Architecture |url= https://www.cs.cmu.edu/afs/cs/project/able/ftp/intro_softarch/intro_softarch.pdf |year=1994|accessdateaccess-date=2012-09-13}}</ref>

* '''The important stuff—whatever that is''': this refers to the fact that software architects should concern themselves with those decisions that have high impact on the system and its stakeholders.<ref name="FOWL2003">{{Cite journal | last1 = Fowler | first1 = Martin | title = Design – Who needs an architect? | doi = 10.1109/MS.2003.1231144 | journal = IEEE Software | volume = 20 | issue = 5 | pages = 11–44 | year = 2003 | s2cid = 356506 }}</ref>

* '''That which is fundamental to understanding a system in its environment'''<ref>[http://www.iso-architecture.org/42010/defining-architecture.html ISO/IEC/IEEE 42010: Defining "architecture"]. Iso-architecture.org. Retrieved on 2013-07-21.</ref>

* '''Things that people perceive as hard to change''': since designing the architecture takes place at the beginning of a software system's lifecycle, the architect should focus on decisions that "have to" be right the first time. Following this line of thought, architectural design issues may become non-architectural once their irreversibility can be overcome.<ref name="FOWL2003"/>

* '''A set of [[Architectural decision|architectural design decisions]]''': software architecture should not be considered merely a set of models or structures, but should include the decisions that lead to these particular structures, and the rationale behind them.<ref name="jansen05" /> This insight has led to substantial research into software architecture [[knowledge management]].<ref name="AKM">{{cite book |title=Software Architecture Knowledge Management |last1=Ali Babar |first1=Muhammad|last2=Dingsoyr|first2=Torgeir|last3=Lago|first3=Patricia|last4=van Vliet|first4=Hans|year=2009 |publisher=Springer|___location=Dordrecht Heidelberg London New York |isbn=978-3-642-02373-6}}</ref>

There is no sharp distinction between software architecture versus design and requirements engineering (see [[#Related fields|Related fields]] below). They are all part of a "chain of intentionality" from high-level intentions to low-level details.<ref name="FAIRBANKS2010">{{cite book|author=George Fairbanks|title=Just Enough Software Architecture|year=2010|publisher=Marshall & Brainerd}}</ref>{{rp|18}}

== Software architecture style vs. software architecture pattern ==

==Characteristics==

{{Main article|List of software architecture styles and patterns}}'''Software Architecture Pattern''' refers to a reusable, proven solution to a recurring problem at the system level, addressing concerns related to the overall structure, component interactions, and quality attributes of the system. Software architecture patterns operate at a higher level of abstraction than software [[Software design pattern|design patterns]], solving broader system-level challenges. While these patterns typically affect system-level concerns, the distinction between architectural patterns and architectural styles can sometimes be blurry. Examples include [[Circuit breaker design pattern|Circuit Breaker]]. <ref name="O'Reilly Media2">{{Cite book |title=Fundamentals of Software Architecture: An Engineering Approach |publisher=O'Reilly Media |year=2020 |isbn=978-1492043454}}</ref><ref name=":0">{{Cite book |title=Design Patterns: Elements of Reusable Object-Oriented Software |isbn=978-0201633610 |last1=Larman |first1=Craig |date=2005 |publisher=Pearson Deutschland GmbH }}</ref><ref name=":1">{{Cite book |title=Patterns of Enterprise Application Architecture |isbn=978-0321127426}}</ref>

'''Software Architecture Style''' refers to a high-level structural organization that defines the overall system organization, specifying how components are organized, how they interact, and the constraints on those interactions. Architecture styles typically include a vocabulary of component and connector types, as well as semantic models for interpreting the system's properties. These styles represent the most coarse-grained level of system organization. Examples include [[Multitier architecture|Layered Architecture]], [[Microservices]], and [[Event-driven architecture|Event-Driven Architecture]]. <ref name="O'Reilly Media2" /><ref name=":0" /><ref name=":1" />

== Anti-patterns ==

The following architectural [[Anti-pattern|anti-patterns]] can arise when [[Software architect|architects]] make decisions. These anti-patterns often follow a progressive sequence, where resolving one may lead to the emergence of another. <ref name="O'Reilly Media" />

* An architect may delay or avoid making architectural decisions due to the fear of choosing incorrectly. To address this, ongoing and close collaboration with the development team is often necessary, with architectural choices being adjusted based on their feedback. Additionally, decisions are typically made at the "last responsible moment," ensuring there is enough information to justify and validate the decision, while avoiding unnecessary delays that could lead to [[analysis paralysis]] and hinder the team's progress. <ref name="O'Reilly Media" />

* Another anti-pattern can arise when architectural decisions are forgotten, not documented, or not understood, leading to repeated discussions without resolution. This often occurs when email is used to communicate architectural decisions. To address these challenges, [[Software architect|architects]] typically provide both technical and business justifications (often related to cost, user satisfaction, and time to market) in a single record of the architectural decision (usually an Architecture Decision Record). This record can be maintained in an accessible repository, such as a wiki. Communication via email focuses on the nature and context of the change and is directed only to relevant stakeholders, with a link to the centralized record. This ensures there is always a single updated source of truth. Additionally, if an architectural decision does not offer tangible business value, or if the business value is misaligned with business stakeholders, it may need to be reconsidered. <ref name="O'Reilly Media" />

== Characteristics ==

Software architecture exhibits the following:

Line 25 ⟶ 52:

'''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 journalbook |lastlast1=Angelov |firstfirst1=SamuilS. |last2=Grefen |first2=PaulP. |last3=Greefhorst |first3=DannyD. |title=A2009 ClassificationJoint ofWorking IEEE/IFIP Conference on Software ReferenceArchitecture Architectures:& AnalyzingEuropean TheirConference Successon andSoftware EffectivenessArchitecture |journalchapter=Proc.A Ofclassification WICSA/ECSAof 2009software reference architectures: Analyzing their success and effectiveness | publisher=IEEE| pages=141–150 |year=2009| doi=10.1109/WICSA.2009.5290800 |year=2009 |isbn=978-1-4244-4984-2 |citeseerx=10.1.1.525.7208 }}</ref> and [[architectural pattern]].<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, Jr.| 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:''' [[Conway's law|anAn 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 Asweb|url=http://www.melconway.com/Home/Conways_Law.html|title=Conway's withLaw|last=Conway|first=Melvin|website=Mel conceptualConway's integrity,Home it wasPage|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 who introduced it to a wider audience when he cited the paper and the idea in his elegant classic ''The Mythical Man-Month'', calling it "[[Conway's law|Conway's Law]]."

== Motivation ==

Software architecture is an "intellectually graspable" abstraction of a complex system.<ref name="SAP2"/>{{rp|5–6}} This abstraction provides a number of benefits:

* ''It gives a basis for analysis of software systems' behavior before the system has been built.''<ref name="PERRY1992"/> The ability to verify that a future software system fulfills its stakeholders' needs without actually having to build it represents substantial cost-saving and risk-mitigation.<ref name="SARA">{{cite web| firstfirst1 = H. | lastlast1 = Obbink

| last2 = Kruchten| first2 = P.

| last3 = Kozaczynski| first3 = W.

Line 46 ⟶ 73:

| date = Feb 6, 2002

| url = https://pkruchten.files.wordpress.com/2011/09/sarav1.pdf

| accessdateaccess-date = November 1, 2015}}</ref> A number of techniques have been developed to perform such analyses, such as [[ATAM]] or by creating a visual representation of the software system.

* ''It provides a basis for re-use of elements and decisions.''<ref name="PERRY1992"/><ref name="SAP2"/>{{rp|35}} A complete software architecture or parts of it, like individual architectural strategies and decisions, can be re-used across multiple systems whose stakeholders require similar quality attributes or functionality, saving design costs and mitigating the risk of design mistakes.

* ''It supports early design decisions that impact a system's development, deployment, and maintenance life.''<ref name="SAP2"/>{{rp|31}} Getting the early, high-impact decisions right is important to prevent schedule and [[cost overrun|budget overruns]].

* ''It facilitates communication with stakeholders, contributing to a system that better fulfills their needs.''<ref name="SAP2"/>{{rp|29–31}} Communicating about complex systems from the point of view of stakeholders helps them understand the consequences of their stated requirements and the design decisions based on them. Architecture gives the ability to communicate about design decisions before the system is implemented, when they are still relatively easy to adapt.

* ''It helps in risk management.'' Software architecture helps to reduce risks and chance of failure.<ref name="FAIRBANKS2010"/>{{rp|18}}

* ''It enables [[cost reduction]].'' Software architecture is a means to manage risk and costs in complex IT projects.<ref name="RCDA">{{cite journal |lastlast1=Poort |firstfirst1=Eltjo |last2=van Vliet |first2=Hans |date=September 2012 |title=RCDA: Architecting as a risk- and cost management discipline |journal=Journal of Systems and Software |volume=85 |issue=9 |pages=1995–2013 |doi=10.1016/j.jss.2012.03.071 |url=https://zenodo.org/record/896159 }}</ref>

==History==

The comparison between software design and (civil) architecture was first drawn in the late 1960s,<ref>{{cite web |editor1=P. Naur |editor2=B. Randell |title=Software Engineering: Report of a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7–11 Oct. 1968 |publisher=NATO, Scientific Affairs Division |___location=Brussels |year=1969 |url=http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF |accessdatearchive-url=https://web.archive.org/web/20030607182458/http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF |archive-date=2003-06-07 |url-status=live |access-date=2012-11-16}}</ref> but the term "software architecture" did not see widespread usage until the 1990s.<ref>{{Cite journal|author1=P. Kruchten |author2=H. Obbink |author3=J. Stafford |title=The past, present and future of software architecture|journal=IEEE Software |volume=23 |issue=2 |pages=22 |year=2006|doi=10.1109/MS.2006.59 |bibcode=2006ISoft..23b..22K |s2cid=2082927 }}</ref> The field of [[computer science]] had encountered problems associated with complexity since its formation.<ref>{{cite web|author=University of Waterloo|title= A Very Brief History of Computer Science |url=http://www.cs.uwaterloo.ca/~shallit/Courses/134/history.html |year=2006|accessdateaccess-date=2006-09-23}}</ref> Earlier problems of complexity were solved by developers by choosing the right [[data structure]]s, developing [[algorithm]]s, and by applying the concept of [[separation of concerns]]. Although the term "software architecture" is relatively new to the industry, the fundamental principles of the field have been applied sporadically by [[software engineering]] pioneers since the mid-1980s. Early attempts to capture and explain software architecture of a system were imprecise and disorganized, often characterized by a set of box-and-line [[diagram]]s.<ref>{{Cite journal|authorwebsite=IEEE Transactions on Software Engineering.org|title= Introduction to the Special Issue on Software Architecture |year=2006|doi= 10.1109/TSE.1995.10003 }}</ref>

Software architecture as a concept has its origins in the research of [[Edsger Dijkstra]] in 1968 and [[David Parnas]] in the early 1970s. These scientists emphasized that the structure of a software system matters and getting the structure right is critical. During the 1990s there was a concerted effort to define and codify fundamental aspects of the discipline, with research work concentrating on architectural styles ([[patterns]]), [[architecture description language]]s, [[Software documentation#Architecture/Design design documentation|architecture documentation]], and [[formal method]]s.<ref>{{cite web|author=Garlan & Shaw |title= An Introduction to Software Architecture |url= https://www.cs.cmu.edu/afs/cs/project/able/ftp/intro_softarch/intro_softarch.pdf |year=1994|accessdateaccess-date=2006-09-25}}</ref>

Research institutions have played a prominent role in furthering software architecture as a discipline. [[Mary Shaw (computer scientist)|Mary Shaw]] and [[David Garlan]] of [[Carnegie Mellon]] wrote a book titled ''Software Architecture: Perspectives on an Emerging Discipline'' in 1996, which promoted software architecture concepts such as [[software component|components]], connectors, and styles. The [[University of California, Irvine]]'s Institute for Software Research's efforts in software architecture research is directed primarily in architectural styles, architecture description languages, and dynamic architectures.

[[IEEE 1471]]-2000, "Recommended Practice for Architecture Description of Software-Intensive Systems", was the first formal standard in the area of software architecture. It was adopted in 2007 by ISO as [[IEEE 1471|ISO/IEC 42010:2007]]. In November 2011, IEEE 1471–2000 was superseded by [[ISO/IEC 42010|ISO/IEC/IEEE 42010:2011]], "Systems and software engineering – Architecture description" (jointly published by IEEE and ISO).<ref name="ISO42010">{{cite web|author=ISO/IEC/IEEE|title=ISO/IEC/IEEE 42010:2011 Systems and software engineering – Architecture description|url=http://www.iso.org/iso/catalogue_detail.htm?csnumber=50508|year=2011|accessdateaccess-date=2012-09-12}}</ref>

While in [[IEEE 1471]], software architecture was about the architecture of "software-intensive systems", defined as "any system where software contributes essential influences to the design, construction, deployment, and evolution of the system as a whole", the 2011 edition goes a step further by including the [[ISO/IEC 15288]] and [[ISO/IEC 12207]] definitions of a system, which embrace not only hardware and software, but also "humans, processes, procedures, facilities, materials and naturally occurring entities". This reflects the relationship between software architecture, [[enterprise architecture]] and [[solution architecture]].

Line 66 ⟶ 93:

==Architecture activities==

Making architectural decisions involves collecting sufficient relevant information, providing justification for the decision, documenting the decision and its rationale, and communicating it effectively to the appropriate stakeholders. <ref name="O'Reilly Media" />

There are many activities that a software architect performs. A software architect typically works with project managers, discusses [[architecturally significant requirements]] with stakeholders, designs a software architecture, evaluates a design, communicates with designers and stakeholders, documents the architectural design and more.<ref name="Kruchten 2008">{{Cite journal | last1 = Kruchten | first1 = P. | title = What do software architects really do? | doi = 10.1016/j.jss.2008.08.025 | journal = Journal of Systems and Software | volume = 81 | issue = 12 | pages = 2413–2416 | year = 2008 }}</ref> There are four core activities in software architecture design.<ref name="hofmeister07"/> These core architecture activities are performed iteratively and at different stages of the initial software development life-cycle, as well as over the evolution of a system.

It's software architect's responsibility to match [[List of system quality attributes|architectural characteristics]] (aka [[Non-functional requirement|non-functional requirements]]) with business requirements. For example: <ref name="O'Reilly Media" />

* Having a high [[Customer satisfaction|customer satisfactions]] requires availability, fault tolerance, security, testability, recoverability, agility and performance in the system.

* Doing [[mergers and acquisitions]] (M&A) requires extensibility, scalability, adaptability, and interoperability

* Constrained budget and time requires feasibility and simplicity

* Faster [[Time to market|time-to-market]] requires maintainability, testability and deployability.

There are four core activities in software architecture design.<ref name="hofmeister07" /> These core architecture activities are performed iteratively and at different stages of the initial software development life-cycle, as well as over the evolution of a system.

'''Architectural analysis''' is the process of understanding the environment in which a proposed system will operate and determining the requirements for the system. The input or requirements to the analysis activity can come from any number of stakeholders and include items such as:

* what the system will do when operational (the functional requirements)

* how well the system will perform runtime non-functional requirements such as reliability, operability, performance efficiency, security, compatibility defined in [[ISO/IEC 25010]]:2011 standard<ref name="ISO25010">{{cite web|author=ISO/IEC|title=ISO/IEC 25010:2011 Systems and software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – System and software quality models|url=http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=35733|year=2011|accessdateaccess-date=2012-10-08}}</ref>

* development-time of non-functional requirements such as maintainability and transferability defined in ISO 25010:2011 standard<ref name="ISO25010"/>

* business requirements and environmental contexts of a system that may change over time, such as legal, social, financial, competitive, and technology concerns<ref>{{cite journalbook|author=Osterwalder and Pigneur| title = Value Creation from E-Business Models| chapter = An Ontology for e-Business Models|pages=65–97|year=2004| doi = 10.1016/B978-075066140-9/50006-0| isbn = 9780750661409|chapter-url=https://pdfs.semanticscholar.org/8513/9070e23b0b3278d73ea51b873acd99352e9c.pdf|citeseerx=10.1.1.9.6922| s2cid = 14177438| archive-url = https://web.archive.org/web/20181117063152/https://pdfs.semanticscholar.org/8513/9070e23b0b3278d73ea51b873acd99352e9c.pdf| archive-date = 2018-11-17}}</ref>

The outputs of the analysis activity are those requirements that have a measurable impact on a software system's architecture, called architecturally significant requirements.<ref name="ASR_Chen">{{Cite journal |doi = 10.1109/MS.2012.174|title = Characterizing Architecturally Significant Requirements|journal = IEEE Software|volume = 30|issue = 2|pages = 38–45|year = 2013|last1 = Chen|first1 = Lianping|last2 = Ali Babar|first2 = Muhammad|last3 = Nuseibeh|first3 = Bashar| bibcode=2013ISoft..30b..38C |hdl = 10344/3061|s2cid = 17399565|hdl-access = free}}</ref>

'''Architectural synthesis''' or design is the process of creating an architecture. Given the architecturally significant requirements determined by the analysis, the current state of the design and the results of any evaluation activities, the design is created and improved.<ref name="hofmeister07"/><ref name="SAP2"/>{{rp|311–326}}

'''Architecture evaluation''' is the process of determining how well the current design or a portion of it satisfies the requirements derived during analysis. An evaluation can occur whenever an architect is considering a design decision, it can occur after some portion of the design has been completed, it can occur after the final design has been completed or it can occur after the system has been constructed. Some of the available software architecture evaluation techniques include [[Architecture tradeoff analysis method|Architecture Tradeoff Analysis Method (ATAM)]] and TARA.<ref name="woods2012" >{{Cite journal | last1 = Woods | first1 = E. | title = Industrial architectural assessment using TARA | doi = 10.1016/j.jss.2012.04.055 | journal = Journal of Systems and Software | volume = 85 | issue = 9 | pages = 2034–2047 | year = 2012 | pmids2cid = | pmc =179244 }}</ref> Frameworks for comparing the techniques are discussed in frameworks such as ''SARA Report''<ref name="SARA" /> and ''Architecture Reviews: Practice and Experience''.<ref>{{Cite journal | last1 = Maranzano | first1 = J. F. | last2 = Rozsypal | first2 = S. A. | last3 = Zimmerman | first3 = G. H. | last4 = Warnken | first4 = G. W. | last5 = Wirth | first5 = P. E. | last6 = Weiss | first6 = D. M. | doi = 10.1109/MS.2005.28 | title = Architecture Reviews: Practice and Experience | journal = IEEE Software | volume = 22 | issue = 2 | pages = 34 | year = 2005 | pmidbibcode = 2005ISoft..22b..34M | pmcs2cid = 11697335 }}</ref>

'''Architecture evolution''' is the process of maintaining and adapting an existing software architecture to meet changes in requirements and environment. As software architecture provides a fundamental structure of a software system, its evolution and maintenance would necessarily impact its fundamental structure. As such, architecture evolution is concerned with adding new functionality as well as maintaining existing functionality and system behavior.

Architecture requires critical supporting activities. These supporting activities take place throughout the core software architecture process. They include knowledge management and communication, design reasoning and decision -making, and documentation.

=== Architecture supporting activities ===

Software architecture supporting activities are carried out during core software architecture activities. These supporting activities assist a software architect to carry out analysis, synthesis, evaluation, and evolution. For instance, an architect has to gather knowledge, make decisions, and document during the analysis phase.

* '''Knowledge management and communication''' is the act of exploring and managing knowledge that is essential to designing a software architecture. A software architect does not work in isolation. They get inputs, functional and non-functional requirements, and design contexts, from various stakeholders; and providesprovide outputs to stakeholders. Software architecture knowledge is often tacit and is retained in the heads of stakeholders. Software architecture knowledge management activity is about finding, communicating, and retaining knowledge. As software architecture design issues are intricate and interdependent, a knowledge gap in design reasoning can lead to incorrect software architecture design.<ref name="Kruchten 2008">{{Cite journal |last1=Kruchten |first1=P. |year=2008 |title=What do software architects really do? |journal=Journal of Systems and Software |volume=81 |issue=12 |pages=2413–2416 |doi=10.1016/j.jss.2008.08.025}}</ref><ref name="SAKM">{{cite book|last1=Babar|first1=M.A.|last2=Dingsøyr|first2=T.|last3=Lago|first3=P.|last4=Vliet|first4=H. van|title=Software Architecture Knowledge Management:Theory and Practice (eds.), First Edition|publisher = Springer|year=2009|isbn=978-3-642-02373-6}}</ref> Examples of knowledge management and communication activities include searching for design patterns, prototyping, asking experienced developers and architects, evaluating the designs of similar systems, sharing knowledge with other designers and stakeholders, and documenting experience inon a wiki page.

* '''Design reasoning and decision making''' is the activity of evaluating design decisions. This activity is fundamental to all three core software architecture activities.<ref name="jansen05">{{Cite book | last1 = Jansen | first1 = A. | last2 = Bosch | first2 = J. | doi = 10.1109/WICSA.2005.61 | chapter = Software Architecture as a Set of Architectural Design Decisions | title = 5th Working IEEE/IFIP Conference on Software Architecture (WICSA'05) | pages = 109 | year = 2005 | isbn = 978-0-7695-2548-8 | pmid = | pmc = | citeseerx = 10.1.1.60.8680 | s2cid = 13492610 }}</ref><ref name="tang09">{{Cite journal | last1 = Tang | first1 = A. | last2 = Han | first2 = J. | last3 = Vasa | first3 = R. | doi = 10.1109/MS.2009.46 | title = Software Architecture Design Reasoning: A Case for Improved Methodology Support | journal = IEEE Software | volume = 26 | issue = 2 | pages = 43 | year = 2009 | pmidbibcode = | pmc =2009ISoft..26b..43T | hdl = 1959.3/51601 | s2cid = 12230032 | hdl-access = free }}</ref> It entails gathering and associating decision contexts, formulating design decision problems, finding solution options and evaluating tradeoffs before making decisions. This process occurs at different levels of decision [[granularity]] while evaluating significant architectural requirements and software architecture decisions, and software architecture analysis, synthesis, and evaluation. Examples of reasoning activities include understanding the impacts of a requirement or a design on quality attributes, questioning the issues that a design might cause, assessing possible solution options, and evaluating the [[Trade-off|tradeoffs]] between solutions.

* '''Documentation''' is the act of recording the design generated during the software architecture process. [[Software design|System design]] is described using several views that frequently include a static view showing the code structure of the system, a dynamic view showing the actions of the system during execution, and a deployment view showing how a system is placed on hardware for execution. Kruchten's 4+1 view suggests a description of commonly used views for documenting software architecture;<ref name="Kru95">{{cite journal |last=Kruchten |first=Philippe |year=1995 |url=http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf |title=Architectural Blueprints – The '4+1' View Model of Software Architecture |journal=IEEE Software |volume=12 |issue=6 |pages=42–50 |doi=10.1109/52.469759|arxiv=2006.04975 |s2cid=219558624 }}</ref> ''Documenting Software Architectures: Views and Beyond'' has descriptions of the kinds of notations that could be used within the view description.<ref name="DSA2" /> Examples of documentation activities are writing a specification, recording a system design model, documenting a design rationale, developing a viewpoint, documenting views.

== Software architectureArchitecture topicsDesign Strategies ==

Software architecture inherently deals with uncertainties, and the size of architectural components can significantly influence a system's outcomes, both positively and negatively. Neal Ford and Mark Richards propose an iterative approach to address the challenge of identifying and right-sizing components. This method emphasizes continuous refinement as teams develop a more nuanced understanding of system behavior and requirements. <ref name="O'Reilly Media" />

The approach typically involves a cycle with several stages: <ref name="O'Reilly Media" />

=== Software architecture description ===

{{main|Software architecture description}}

Software architecture description involves the principles and practices of modeling and representing architectures, using mechanisms such as architecture description languages, architecture viewpoints, and architecture frameworks.

* A high-level partitioning strategy is established, often categorized as technical or ___domain-based. Guidelines for the smallest meaningful deployable unit, referred to as "quanta," are defined. While these foundational decisions are made early, they may be revisited later in the cycle if necessary.

=== Architecture description languages ===

* Initial components are identified based on the established strategy.

{{main|Architecture description language}}

* Requirements are assigned to the identified components.

An architecture description language (ADL) is any means of expression used to describe a software architecture ([[ISO/IEC 42010|ISO/IEC/IEEE 42010]]).

* The roles and responsibilities of each component are analyzed to ensure clarity and minimize overlap.

Many special-purpose ADLs have been developed since the 1990s, including [[Architecture analysis and design language|AADL]] (SAE standard), [[Wright (ADL)|Wright]] (developed by Carnegie Mellon), [[Acme (ADL)|Acme]] (developed by Carnegie Mellon), xADL (developed by UCI), [[Darwin (ADL)|Darwin]] (developed by [[Imperial College London]]), DAOP-ADL (developed by University of Málaga), SBC-ADL (developed by [[National Sun Yat-Sen University]]), and [[ByADL (ADL)|ByADL]] (University of L'Aquila, Italy).

* Architectural characteristics, such as scalability, fault tolerance, and maintainability, are evaluated.

* Components may be restructured based on feedback from development teams.

This cycle serves as a general framework and can be adapted to different domains.

=== Architecture viewpoints ===

{{main|View model}}

[[File:4+1 Architectural View Model.svg|thumb|264px|[[4+1 architectural view model]].]]

Software architecture descriptions are commonly organized into [[view model|views]], which are analogous to the different types of [[blueprint]]s made in building [[architecture]]. Each view addresses a set of system concerns, following the conventions of its ''viewpoint'', where a viewpoint is a specification that describes the notations, modeling, and analysis techniques to use in a view that expresses the architecture in question from the perspective of a given set of stakeholders and their concerns ([[ISO/IEC 42010|ISO/IEC/IEEE 42010]]). The viewpoint specifies not only the concerns framed (i.e., to be addressed) but the presentation, model kinds used, conventions used and any consistency (correspondence) rules to keep a view consistent with other views.

== Software architecture topics ==

=== Architecture frameworks ===

{{main|Architecture framework}}

An architecture framework captures the "conventions, principles and practices for the description of architectures established within a specific ___domain of application and/or community of stakeholders" ([[ISO/IEC 42010|ISO/IEC/IEEE 42010]]). A framework is usually implemented in terms of one or more viewpoints or ADLs.

=== Architectural styles and patterns ===

{{main|Architectural pattern}}

<!-- This section is linked from [[Abstraction (computer science)]] -->

An [[architectural pattern]] is a general, reusable solution to a commonly occurring problem in software architecture within a given context.

Architectural patterns are often documented as software [[Design pattern (computer science)|design patterns]].

Following traditional building architecture, a 'software architectural style' is a specific method of construction, characterized by the features that make it notable" ([[architectural style]]).

{{cquote|''An architectural style defines: a family of systems in terms of a pattern of structural organization; a vocabulary of components and connectors, with constraints on how they can be combined.''<ref name=SG>{{cite book |last=Shaw |first=Mary |last2=Garlan |first2=David |date=1996 |title=Software architecture: perspectives on an emerging discipline |publisher=Prentice Hall |isbn=978-0-13-182957-2}}</ref>}}

{{cquote|''Architectural styles are reusable 'packages' of design decisions and constraints that are applied to an architecture to induce chosen desirable qualities.''<ref>[http://www.isr.uci.edu/architecture/styles.html UCI Software Architecture Research – UCI Software Architecture Research: Architectural Styles]. Isr.uci.edu. Retrieved on 2013-07-21.</ref>}}

There are many recognized architectural patterns and styles, among them:

* [[Blackboard (computing)|Blackboard]]

* [[Client–server model|Client-server]] (2-tier, [[Three-tier (computing)|3-tier]], [[n-tier|''n''-tier]], [[cloud computing]] exhibit this style)

* [[Software componentry|Component-based]]

* [[Database-centric architecture|Data-centric]]

* [[Event-driven architecture|Event-driven]] (or [[implicit invocation]])

* [[Abstraction (computer science)#Layered architecture|Layered]] (or [[multilayered architecture]])

* [[Microservices|Microservices architecture]]

* [[Monolithic application]]

* [[Peer-to-peer]] (P2P)

* [[Pipes and filters]]

* [[Plug-in (computing)|Plug-ins]]

* [[Reactive architecture]]

* [[Representational state transfer]] (REST)

* [[Rule-based system|Rule-based]]

* [[Service-oriented architecture|Service-oriented]]

* [[Shared nothing architecture]]

* [[Space-based architecture]]

Some treat architectural patterns and architectural styles as the same,<ref name=MSDN>[http://msdn.microsoft.com/en-us/library/ee658117.aspx Chapter 3: Architectural Patterns and Styles]. Msdn.microsoft.com. Retrieved on 2013-07-21.</ref> some treat styles as specializations of patterns. What they have in common is both patterns and styles are idioms for architects to use, they "provide a common language"<ref name=MSDN/> or "vocabulary"<ref name=SG/> with which to describe classes of systems.

=== Software architecture and agile development ===

{{main|Agile development}}

There are also concerns that software architecture leads to too much [[Big Design Up Front]], especially among proponents of [[agile software development]]. A number of methods have been developed to balance the trade-offs of up-front design and agility,<ref name="Boehm2004">{{cite book |title=Balancing Agility and Discipline |last1=Boehm|first1=Barry|last2=Turner|first2=Richard|year=2004|publisher=Addison-Wesley|isbn=978-0-321-18612-6}}</ref> including the agile method [[dynamic systems development method|DSDM]] which mandates a "Foundations" phase during which "just enough" architectural foundations are laid. ''[[IEEE Software]]'' devoted a special issue<ref>{{cite web|url=http://www.computer.org/portal/web/computingnow/archive/april2010|title=IEEE Software Special Issue on Agility and Architecture|date=April 2010|accessdate=14 September 2012}}</ref> to the interaction between agility and architecture.

There are also concerns that software architecture leads to too much [[big design up front]], especially among proponents of [[agile software development]]. A number of methods have been developed to balance the trade-offs of up-front design and agility,<ref name="Boehm2004">{{cite book |title=Balancing Agility and Discipline |last1=Boehm|first1=Barry|last2=Turner|first2=Richard|year=2004|publisher=Addison-Wesley|isbn=978-0-321-18612-6}}</ref> including the agile method [[dynamic systems development method|DSDM]] which mandates a "Foundations" phase during which "just enough" architectural foundations are laid. ''[[IEEE Software]]'' devoted a special issue to the interaction between agility and architecture.

=== Software architecture erosion ===

Software architecture erosion refers to a gradual gap between the intended and implemented architecture of a software system over time.<ref name="Ruiyin2022">{{Cite journal | last1 = Li | first1 = Ruiyin | last2 = Liang | first2 = Peng | last3 = Soliman | first3 = Mohamed | last4 = Avgeriou | first4 = Paris | doi = 10.1002/smr.2423 | title = Understanding software architecture erosion: A systematic mapping study | journal = [[Journal of Software: Evolution and Process]]| volume = 34 | issue = 3 | pages = e2423 | year = 2022 | url = https://onlinelibrary.wiley.com/doi/abs/10.1002/smr.2423| arxiv = 2112.10934 }}</ref> The phenomenon of software architecture erosion was initially brought to light in 1992 by Perry and Wolf alongside their definition of software architecture.<ref name="PERRY1992"/>

Software architecture erosion (or "decay") refers to the gap observed between the planned and actual architecture of a software system as realized in its implementation.<ref>Terra, R., M.T. Valente, K. Czarnecki, and R.S. Bigonha, "Recommending Refactorings to Reverse Software Architecture Erosion",

16th European Conference on Software Maintenance and Reengineering, 2012.

http://gsd.uwaterloo.ca/sites/default/files/Full%20Text.pdf</ref> Software architecture erosion occurs when implementation decisions either do not fully achieve the architecture-as-planned or otherwise violate constraints or principles of that architecture.<ref name="PERRY1992"/> The gap between planned and actual architectures is sometimes understood in terms of the notion of [[technical debt]].

Software architecture erosion may occur in each stage of the software development life cycle and has varying impacts on the development speed and the cost of maintenance. Software architecture erosion occurs due to various reasons, such as ''architectural violations'', ''the accumulation of technical debt'', and ''knowledge vaporization''.<ref name="Ruiyin2021">{{Cite book | last1 = Li | first1 = Ruiyin | last2 = Liang | first2 = Peng | last3 = Soliman | first3 = Mohamed | last4 = Avgeriou | first4 = Paris | doi = 10.1109/icpc52881.2021.00037 | title = The 29th IEEE/ACM International Conference on Program Comprehension (ICPC) | chapter = Understanding architecture erosion: The practitioners' perceptive | pages = 311–322 | year = 2021 | isbn = 978-1-6654-1403-6 }}</ref> A famous case of architecture erosion is the failure of Mozilla Web browser.<ref>van Gurp, J. and Bosch, J.: 2002, Design erosion: Problems and causes, Journal of Systems and Software 61(2), 105–119.</ref> Mozilla is an application created by Netscape with a complex codebase that became harder to maintain due to continuous changes. Due to initial poor design and growing architecture erosion, Netscape spent two years redeveloping the Mozilla Web browser, demonstrating the importance of proactive architecture management to prevent costly repairs and project delays.

As an example, consider a strictly [[Abstraction (computer science)#Layered architecture|layered]] system, where each layer can only use services provided by the layer immediately below it. Any source code component that does not observe this constraint represents an architecture violation. If not corrected, such violations can transform the architecture into a monolithic block, with adverse effects on understandability, maintainability, and evolvability.

Architecture erosion can decrease software performance, substantially increase evolutionary costs, and degrade software quality. Various approaches and tools have been proposed to detect architecture erosion. These approaches are primarily classified into four categories: consistency-based, evolution-based, defect-based, and decision-based approaches.<ref name=" Ruiyin2022"/> For instance, automated architecture conformance checks, static code analysis tools, and refactoring techniques help identify and mitigate erosion early.

Various approaches have been proposed to address erosion.

"These approaches, which include tools, techniques, and processes, are primarily classified into three general categories that attempt to minimize, prevent and repair architecture erosion. Within these broad categories, each approach is further broken down reflecting the high-level strategies adopted to tackle erosion. These are process-oriented architecture conformance, architecture evolution management, architecture design enforcement, architecture to implementation linkage, self-adaptation and architecture restoration techniques consisting of recovery, discovery, and reconciliation."<ref>{{cite journal |last1=de Silva |first1=L. |first2=D. |last2=Balasubramaniam |title=Controlling software architecture erosion: A survey |journal=Journal of Systems and Software |year=2012 |volume=85 |issue=1 |pages=132–151 |doi=10.1016/j.jss.2011.07.036}}</ref>

Besides, the measures used to address architecture erosion contain two main types: preventative and remedial measures.<ref name=" Ruiyin2022"/> Preventative measures include enforcing architectural rules, regular code reviews, and automated testing, while remedial measures involve refactoring, redesign, and documentation updates.

There are two major techniques to detect architectural violations: reflexion models and ___domain-specific languages. Reflexion model (RM) techniques compare a high-level model provided by the system's architects with the source code implementation. There are also [[___domain-specific language]]s with a focus on specifying and checking architectural constraints.

=== Software architecture recovery ===

Line 166 ⟶ 162:

Software architecture recovery (or reconstruction, or [[reverse engineering]]) includes the methods, techniques, and processes to uncover a software system's architecture from available information, including its implementation and documentation. Architecture recovery is often necessary to make informed decisions in the face of obsolete or out-of-date documentation and

[[Software architecture#Software architecture erosion|architecture erosion]]: implementation and maintenance decisions diverging from the envisioned architecture.<ref>

Lungu, M. "Software architecture recovery", University of Lugano, 2008.

http://www.slideshare.net/mircea.lungu/software-architecture-recovery-in-five-questions-presentation

</ref> Practices exist to recover software architecture as [[Code analysis|static program analysis]]. This is a part of the subjects covered by the [[software intelligence]] practice.

==Related fields==

Line 176 ⟶ 172:

{{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 |archiveurlarchive-url=https://web.archive.org/web/20070928035606/http://eden-study.org/articles/2003/icse03.pdf |archivedatearchive-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 '[[ProblemComputational problem|problem space]]' or the 'what'.<ref name="shekaran94">{{Cite journalbook|author1=C. Shekaran |journal=Proceedings of IEEE International Conference on Requirements Engineering |pages=239–245 |author2=D. Garlan |author3=M. Jackson |author4=N.R. Mead |author5=C. Potts |author6=H.B. Reubenstein |yeartitle=1994|doi=10.1109/ICRE.1994.292379Proceedings of IEEE International Conference on Requirements Engineering |titlechapter=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' ===

Line 189 ⟶ 185:

;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 consistsconsist 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".<ref>[http://www.gartner.com/technology/it-glossary/enterprise-architecture.jsp Definition of Enterprise Architecture, Gartner]</ref> 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.

==See also==

{{cmn|colwidth=30em|

*[[ArchiMate]]

*[[Architecture description language]]

*[[Architecture framework]]

*[[Architectural pattern (computer science)]]

*[[Architectural style]]

*[[Anti-pattern]]

*[[Attribute-driven design]]

*[[C4 model (software)|C4 model]]

*[[Computer architecture]]

*[[Distributed Data Management Architecture]]

Line 206 ⟶ 211:

*[[Systems design]]

*[[Software Architecture Analysis Method]]

*[[List of software architecture styles and patterns]]

*[[Software architecture description]]

*[[Time-triggered system]]

*[[View model]]

}}

==References==

Line 212 ⟶ 221:

== Further reading ==

*{{Cite book|last=Richards|first=Mark|title=Fundamentals of Software Architecture: An Engineering Approach|publisher=[[O'Reilly Media]]|year=2020|isbn=9781492043454|___location=|pages=}}

*{{Cite book|last=Len|first=Bass|title=Software Architecture in Practice (3rd Edition)|publisher=[[Addison-Wesley Professional]]|year=2012|isbn=9780321815736|___location=|pagesedition=3rd}} - This book covers the fundamental concepts of the discipline. The theme is centered on achieving quality attributes of a system.

*{{Cite book|last=Clements|first=Paul|title=Documenting Software Architectures: Views and Beyond (2nd Edition)|publisher=[[Addison-Wesley Professional]]|year=2010|isbn=9780321552686|___location=|pagesedition=2nd}} - This book describes what software architecture is and shows how to document it in multiple views, using UML and other notations. It also explains how to complement the architecture views with behavior, software interface, and rationale documentation. Accompanying the book is a [https://wiki.sei.cmu.edu/sad/index.php/The_Adventure_Builder_SAD wiki that contains an example of software architecture documentation].

*{{Cite book| last = Bell | first = Michael | editor1-first = Michael | editor1-last = Bell | year = 2008 | title = Service-Oriented Modeling: Service Analysis, Design, and Architecture | publisher = Wiley|isbn=9780470255704|___location=|pages=|doi=10.1002/9781119198864}}

*{{Cite journalbook |first1=Tony |last1=Shan |first2=Winnie |last2=Hua |title=Solution2006 Architecting10th MechanismIEEE |journal=ProceedingsInternational ofEnterprise theDistributed 10thObject IEEEComputing InternationalConference (EDOC'06) Enterprise|chapter=Solution ComputingArchitecting ConferenceMechanism |date=October 2006 |pages=23–32|doi=10.1109/EDOC.2006.54 |isbn=978-0-7695-2558-7 |s2cid=8361936 }}

*{{cite journal |first1=Javier |last1=Garzás |first2=Mario |last2=Piattini |title=An ontology for micro-architectural design knowledge |journal=[[IEEE Software]] |volume=22 |issue=2 |year=2005 |pages=28–33 |doi=10.1109/MS.2005.26|bibcode=2005ISoft..22b..28G |s2cid=17639072 }}

*{{Cite journal|last=Fowler|first=Martin|date=September 2003|title=Who Needs an Architect?|url=http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf|journal=[[IEEE Software]]|volume=20|issue=5|pagespage=11 |doi=10.1109/MS.2003.1231144|viabibcode=2003ISoft..20e..11F |s2cid=356506}}

*{{Cite journal|last=Kazman|first=Rick|date=May 2003|title=Architecture, Design, Implementation|url=https://resources.sei.cmu.edu/asset_files/WhitePaper/2003_019_001_29559.pdf |journalarchive-url=Softwarehttps://web.archive.org/web/20150921170650/http://resources.sei.cmu.edu/asset_files/WhitePaper/2003_019_001_29559.pdf Engineering Institute|volumearchive-date=2015-09-21 |pagesurl-status=live|viajournal=Software Engineering Institute}} - On the distinction between architectural design and detailed design.

*{{cite journal |last=Kruchten |first=Philippe |year=1995 |url=http://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2003/Pbk4p1.pdf |archive-url=https://web.archive.org/web/20060613222204/http://www.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2003/Pbk4p1.pdf |archive-date=2006-06-13 |url-status=live |title=Architectural Blueprints – The '4+1' View Model of Software Architecture |journal=IEEE Software |volume=12 |issue=6 |pages=42–50 |doi=10.1109/52.469759|arxiv=2006.04975 |s2cid=219558624 }}

*{{Cite book|last=Pautasso|first=Cesare|title=Software Architecture: visual lecture notes|publisher=LeanPub|year=2020|url=https://leanpub.com/software-architecture/|pages=689}}

==External links==

Line 228 ⟶ 238:

* Collection of [http://www.sei.cmu.edu/architecture/start/definitions.cfm software architecture definitions] at [[Software Engineering Institute]] (SEI), [[Carnegie Mellon University]] (CMU)

* [http://www.iasaglobal.org/ International Association of IT Architects (IASA Global)], formerly known as the International Association for Software Architects (IASA)

* [http://www.softwarearchitectureportal.org/ SoftwareArchitecturePortal.org] – website of [[IFIP Working Group 2.10]] on Software Architecture

* [http://www.softwarearchitectures.com/ SoftwareArchitectures.com] – an independent resource of information on the discipline

* [http://www.ics.uci.edu/~fielding/pubs/dissertation/software_arch.htm Software Architecture], chapter 1 of [[Roy Fielding]]'s REST dissertation

Line 234 ⟶ 244:

* [https://github.com/bp4you/sadd The Spiral Architecture Driven Development] – the [[Systems Development Life Cycle|SDLC]] based on the [[Spiral model]] aims to reduce the risks of ineffective architecture

* [https://www.infoq.com/architecture Software Architecture Real Life Case Studies]

* [https://apiumhub.com/tech-blog-barcelona/importance-good-software-architecture/ The importance of a good Software Architecture]

{{Software engineering}}

{{Edsger Dijkstra}}

{{Authority control}}

Line 243 ⟶ 251:

{{DEFAULTSORT:Software Architecture}}

[[Category:Software architecture| ]]

[[Category:Edsger W. Dijkstra]]