Why is it so hard to define software architecture?

In recent gears, software engineering researchers have elevated the study of software architecture to the level of a major area of study. A review of the published literature however, shows quite clearly that a unified view of software architecture has not been forth-coming. This paper contends that the existence of a "software architecture level of design" is based on the implicit assumption that the software development process is analogous to those "construction" disciplines in which the completed artefacts or systems exhibit a unique representational abstraction, fired during the early stages of design, which we describe as "the architecture". We argue that our problems in obtaining an acceptable definition of software architecture are due to the assumption that software systems have an analogous, unique design abstraction, determinable at the early stages of the design. To determine the validity of this analogy, we contrast the nature and use of architecture in the traditional building process with software development to identify the differences, rather than the similarities that exist. These differences are explained using a theory of the software development process which highlights why these differences arise and, subsequently, why there has been trouble in developing a community-wide understanding of software architecture. Our conclusion is that due to the fundamental nature of the systems we construct, attempts to depict the large-scale structure of the system, in an analogous manner traditional building disciplines, results in many different architectures. These are fundamentally different representations and not merely different views of a single whole. Moreover, each of these is equally qualified to be labelled as the system architecture with respect to the general notion of what architecture is.