This is the user sandbox of Eltjopoort. A user sandbox is a subpage of the user's user page. It serves as a testing spot and page development space for the user and is not an encyclopedia article. For a sandbox of your own, create it here.
If you are writing an article, and are ready to request its creation:
Content below is being prepared for the Software Architecture page.
Applying the term “architecture” to software systems was originally a metaphor referring to the classical field of the architecture of buildings. The term “software architecture” is used to denote three concepts:
- the high level structure of a software system
- the discipline of creating such a high level structure
- the documentation of this high level structure
To date there is still no agreement on the precise definition of the term “software architecture”. The word “software” does not cover the full scope of what software architecture is about, and the word “architecture” begs the question when something is considered “architectural” in the software world.
Software: In IEEE_1471 the 2000 edition of the ISO/IEC/IEEE 42010:2011 standard, 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 include not only hardware and software, but also “humans, processes, procedures, facilities, materials and naturally occurring entities”. This reflects the current state of affairs where software architecture is strongly related to Enterprise Architecture and Solution Architecture.
Architecture: There are various opinions as to what is considered architectural in the software world:
- Overall, macroscopic system structure ; this refers to architecture as a higher level abstraction of a software system, consisting of high-level components and connectors, as opposed to implementation details.
- 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 -- which may include apparently low-level details.
- That which is fundamental to understanding a system in its environment"
- Things that people perceive as hard to change ; since architecting 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, since reversing such decisions may be impossible or prohibitively expensive.
- A set of architectural design decisions ; software architecture should not be considered to be merely a set of models or structures, but also the decisions that have led to these particular structures and the rationale behind them. This insight has led to substantial research into software architecture knowledge management.
There is no sharp division between software architecture, design and requirements engineering (see “Related fields” below). They are all part of a “chain of intentionality” from high-level intentions to low-level details.
The topics below are generally associated with software architecture and help clarify its scope.
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 how they are addressed is part of architecting the system. . 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 by separating 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. These separate descriptions are called architectural views (see e.g. 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 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. Stakeholder concerns often translate into requirements on these quality attributes, which are variously called non-functional requirements, extra-functional requirements, system quality requirements or constraints.
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 on various levels of abstraction. Common terms for recurring solutions are architectural style, strategy or tactic, reference architecture and architectural pattern.
Conceptual integrity: a term introduced by Fred Brooks in 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 conceptual integrity.
Software architecture is an “intellectually graspable” abstraction of a complex system. This abstraction provides a number of benefits:
- It gives a basis for analysis of software systems' behavior before the system has been built. The ability to verify that a future software system fulfills it stakeholders' needs without actually having to build it represents substantial cost-saving and risk-mitigation. A number of techniques has been developed to perform such analyses, like ATAM.
- It provides a basis for re-use of elements and decisions. 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 provides support for early design decisions which have high impact on a system's development, deployment and maintenance life. Getting the early, high-impact decisions right is important to prevent schedule and budget overruns.
- It facilitates communication with stakeholders, contributing to a system that better fulfills their needs. 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.
Through these mechanisms, software architecture helps to manage risks and reduce costs in complex IT projects.
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.  IEEE Software devoted a special issue to the interaction between agility and architecture.
- Perry, D. E.; Wolf, A. L. (1992). "Foundations for the study of software architecture". ACM SIGSOFT Software Engineering Notes 17 (4): 40. doi:10.1145/141874.141884.
- SEI (2006). "How do you define Software Architecture?". Retrieved 2012-09-12.
- ISO/IEC/IEEE (2011). "ISO/IEC/IEEE 42010:2011 Systems and software engineering -- Architecture description". Retrieved 2012-09-12.
- Garlan & Shaw (1994). "An Introduction to Software Architecture". Retrieved 2012-09-13.
- Fowler, M. (2003). "Design - Who needs an architect?". IEEE Software 20 (5): 11–44. doi:10.1109/MS.2003.1231144.
- Jansen, A.; Bosch, J. (2005). "Software Architecture as a Set of Architectural Design Decisions". 5th Working IEEE/IFIP Conference on Software Architecture (WICSA'05). p. 109. doi:10.1109/WICSA.2005.61. ISBN 0-7695-2548-2.
- Ali Babar, Muhammad; Dingsoyr, Torgeir; Lago, Patricia; van Vliet, Hans (2009). Software Architecture Knowledge Management. Dordrecht Heidelberg London New York: Springer. ISBN 978-3-642-02373-6.
- George Fairbanks (2010). Just Enough Software Architecture. Marshall & Brainerd.
- Bass, Len; Paul Clements, Rick Kazman (2003). Software Architecture in Practice, Second Edition. Boston: Addison-Wesley. ISBN 0-321-15495-9.
- SARA Work Group (2002). "SARA Report". Retrieved 14 September 2012.
- Boehm, Barry; Turner, Richard (2994). Balancing Agility and Discipline. Addison-Wesley. ISBN 0321186125.
- "IEEE Software Special Issue on Agility and Architecture". April 2010. Retrieved 14 September 2012.