Software architecture
Software architecture is about making fundamental structural choices that are costly to change once implemented.
Each team extracts and prioritizes architectural characteristics (aka non functional requirements) then models the components accordingly.
Architecture styles typically include a vocabulary of component and connector types, as well as semantic models for interpreting the system's properties.
[5]: 29–31 This implies that architecture involves dealing with a broad variety of concerns and stakeholders, and has a multidisciplinary nature.
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[5]: 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, maintainability, availability, security, usability, and other such –ilities.
[17][18][5]: 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.
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 conceptual integrity.
[20] 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.
Early attempts to capture and explain software architecture of a system were imprecise and disorganized, often characterized by a set of box-and-line diagrams.
[26] Software architecture as a concept has its origins in the research of Edsger Dijkstra in 1968 and David Parnas in the early 1970s.
[27] Research institutions have played a prominent role in furthering software architecture as a discipline.
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 components, connectors, and styles.
[28] 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.
[28][5]: 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.
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.
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.
[41] 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.
[39] For instance, automated architecture conformance checks, static code analysis tools, and refactoring techniques help identify and mitigate erosion early.
Both requirements engineering and software architecture revolve around stakeholder concerns, needs, and wishes.
[45] Approaches such as the Twin Peaks model[46] aim to exploit the synergistic relation between requirements and architecture.
