Classic definitions appear in some of the more prominent or influential books and papers on architecture.
Contact us to submit your definition of software architecture.
An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization---these elements and their interfaces, their collaborations, and their composition (Kruchten: The Rational Unified Process. Also cited in Booch, Rumbaugh, and Jacobson: The Unified Modeling Language User Guide, Addison-Wesley, 1999).
An early one by Dewayne Perry and Alex Wolf is:
A set of architectural (or, if you will, design) elements that have a particular form. Perry and Wolf distinguish between processing elements, data elements, and connecting elements, and this taxonomy by and large persists through most other definitions and approaches.
In what has come to be regarded as a seminal paper on software architecture , Mary Shaw and David Garlan suggest that software architecture is a level of design concerned with issues
...beyond the algorithms and data structures of the computation; designing and specifying the overall system structure emerges as a new kind of problem. Structural issues include gross organization and global control structure; protocols for communication, synchronization, and data access; assignment of functionality to design elements; physical distribution; composition of design elements; scaling and performance; and selection among design alternatives."
Writing about a method to evaluate architectures with respect to the quality attributes they instill in a system , Bass and his colleagues write that
...the architectural design of a system can be described from (at least) three perspectives -- functional partitioning of its domain of interest, its structure, and the allocation of domain function to that structure.
Writing for the ARPA Domain-Specific Software Architecture (DSSA) program, Hayes-Roth says that software architecture is
...an abstract system specification consisting primarily of functional components described in terms of their behaviors and interfaces and component-component interconnections.
David Garlan and Dewayne Perry have adopted the following definition for their guest editorial to the April 1995 IEEE Transactions on Software Engineering devoted to software architecture:
The structure of the components of a program/system, their interrelationships, and principles and guidelines governing their design and evolution over time.
(The source of this definition was a weekly discussion group devoted to software architecture at the Software Engineering Institute.)
Barry Boehm and his students at the USC Center for Software Engineering write that:
A software system architecture comprises
Soni, Nord, and Hofmeister of Siemens Corporate Research write that, based on structures found to be prevalent and influential in the development environment of industrial projects they studied, software architecture has at least four distinct incarnations:
Within each category, the structures describe the system from a different perspective:
Shaw, 1995: At the First International Workshop on Architectures for Software Systems, Mary Shaw provided a much-needed clarification of the terminological chaos. Distilling the definitions and viewpoints (implicit or explicit) of the workshop's position papers, Shaw classifies the views of software architecture thus :
Work in this area is exemplified by the development of architectural description languages (ADLs), which are formal languages that facilitate the description of an architecture's components and connections. The languages are usually graphical, and provide some form of "box and line" syntax for specifying components and hooking them together.
These views do not preclude each other, nor do they really represent a fundamental conflict about what software architecture is. Instead, they represent a spectrum in the software architecture research community about the emphasis that should be placed on architecture -- its constituent parts, the whole entity, the way it behaves once built, or the building of it. Taken together, they form a consensus view of software architecture.