Modern definitions appear in Software Documenting Software Architectures: Views and Beyond (2nd Edition), Software Architecture in Practice (2nd Edition), and ANSI/IEEE Std 1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems.
Contact us to submit your definition of software architecture.
1. From the book Documenting Software Architectures: Views and Beyond (2nd Edition), Clements et al, Addison-Wesley, 2010:
The set of structures needed to reason about the system, which comprises software elements, relations among them, and properties of both.
In this book, we use a definition based on the one from Software Architecture in Practice (2nd Edition) (see below). We chose it because it helps us know what to document about an architecture. The definition emphasizes the plurality of structures present in every software system. These structures, carefully chosen and designed by the architect, are the key to achieving and reasoning about the system's design goals. And those structures are the key to understanding the architecture. Therefore, they are the focus of our approach to documenting a software architecture.
Structures consist of elements, relations among the elements, and the important properties of both. So documenting a structure entails documenting those things.
2. From the book Software Architecture in Practice (2nd edition), Bass, Clements, Kazman; Addison-Wesley 2003:
The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.
"Externally visible" properties refers to those assumptions other elements can make of an element, such as its provided services, performance characteristics, fault handling, shared resource usage, and so on. Let us look at some of the implications of this definition in more detail.
First, architecture defines elements. The architecture embodies information about how the elements relate to each other. This means that architecture specifically omits certain information about elements that does not pertain to their interaction. Thus, an architecture is foremost an abstraction of a system that suppresses details of elements that do not affect how they use, are used by, relate to, or interact with other elements. In nearly all modern systems, elements interact with each other by means of interfaces that partition details about an element into public and private parts. Architecture is concerned with the public side of this division; private details of elements—details having to do solely with internal implementation—are not architectural.
Second, the definition makes clear that systems can and do comprise more than one structure and that no one structure holds the irrefutable claim to being the architecture. For example, all non-trivial projects are partitioned into implementation units; these units are given specific responsibilities, and are the basis of work assignments for programming teams. This kind of element will comprise programs and data that software in other implementation units can call or access, and programs and data that are private. In large projects, the elements will almost certainly be subdivided for assignment to subteams. This is one kind of structure often used to describe a system. It is a very static structure, in that it focuses on the way the system's functionality is divided up and assigned to implementation teams.
Other structures are much more focused on the way the elements interact with each other at runtime to carry out the system's function. Suppose the system is to be built as a set of parallel processes. The set of processes that will exist at runtime, the programs in the various implementation units described previously that are strung together sequentially to form each process, and the synchronization relations among the processes form another kind of structure often used to describe a system.
Third, the definition implies that every software system has an architecture because every system can be shown to be composed of elements and relations among them. In the most trivial case, a system is itself a single element—an uninteresting and probably non-useful architecture, but an architecture nevertheless. Even though every system has an architecture, it does not necessarily follow that the architecture is known to anyone. Unfortunately, an architecture can exist independently of its description or specification, which raises the importance of architecture documentation and architecture reconstruction.
Fourth, the behavior of each element is part of the architecture insofar as that behavior can be observed or discerned from the point of view of another element. This behavior is what allows elements to interact with each other, which is clearly part of the architecture. This does not mean that the exact behavior and performance of every element must be documented in all circumstances; but to the extent that an element's behavior influences how another element must be written to interact with it or influences the acceptability of the system as a whole, this behavior is part of the software architecture.
Finally, the definition is indifferent as to whether the architecture for a system is a good one or a bad one, meaning that the architecture will allow or prevent the system from meeting its behavioral, performance, and life-cycle requirements. Assuming that we do not accept trial and error as the best way to choose an architecture for a system—that is, picking an architecture at random, building the system from it, and hoping for the best—this raises the importance of architecture evaluation.
3. ANSI/IEEE Std 1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems
Architecture is defined by the recommended practice as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution. This definition is intended to encompass a variety of uses of the term architecture by recognizing their underlying common elements. Principal among these is the need to understand and control those elements of system design that capture the system's utility, cost, and risk. In some cases, these elements are the physical components of the system and their relationships. In other cases, these elements are not physical, but instead, logical components. In still other cases, these elements are enduring principles or patterns that create enduring organizational structures. The definition is intended to encompass these distinct, but related uses, while encouraging more rigorous definition of what constitutes the fundamental organization of a system within particular domains.