Editing Software architecture (section)

==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" /> 

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|access-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 book|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|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 | s2cid = 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 | s2cid = 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 provide 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 on 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 | 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 | 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.