There is no shortage of definitions when it comes to "architecture." There are even Websites that maintain collections of definitions.1 The definition used in this article is that taken from IEEE Std 1472000, the IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, referred to as IEEE 1471.2 This definition follows, with key characteristics bolded.
Architecture is the fundamental organization of a system embodied in itscomponents, their relationships to each other, and to the environment, and the principles guiding its design and evolution. [IEEE 1471]
This standard also defines the following terms related to this definition:
A system is a collection of components organized to accomplish a specific function or set of functions. The term system encompasses individual applications, systems in the traditional sense, subsystems, systems of systems, product lines, product families, whole enterprises, and other aggregations of interest. A system exists to fulfill one or more missions in its environment. [IEEE 1471]
The environment, or context, determines the setting and circumstances of developmental, operational, political, and other influences upon that system. [IEEE 1471]
A mission is a use or operation for which a system is intended by one or morestakeholders to meet some set of objectives. [IEEE 1471]
A stakeholder is an individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system. [IEEE 1471]
As we can see, the term "component" is used throughout these definitions. However, most definitions of architecture do not define the term "component," and IEEE 1471 is no exception, as it leaves it deliberately vague to cover the many interpretations in the industry. A component may be logical or physical, technology-independent or technology-specific, large-grained or small-grained. For the purposes of this article, I use the definition of component from the UML 2.0 specification; and I use the term fairly loosely in order to encompass the variety of architectural elements that we may encounter, including objects, technology components (such as an Enterprise JavaBean), services, program modules, legacy systems, packaged applications, and so on. Here is the UML 2.0 definition for "component":
[A component is] a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment. A component defines its behavior in terms of provided and required interfaces. As such, a component serves as a type, whose conformance is defined by these provided and required interfaces (encompassing both their static as well as dynamic semantics).3
The definitions provided here cover a number of different concepts, which are discussed in more detail later in this article. Although there is no generally agreed definition of "architecture" in the industry, it is worth considering some other definitions so that similarities between them can be observed. Consider the following definitions where, again, I've bolded some of the key characteristics.
An architecture is the set of significant decisions about the organization of a software system, the selection of 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 elements into progressively larger subsystems, and the architectural style that guides this organization -- these elements and their interfaces, their collaborations, and their composition. [Kruchten]4
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. [Bass et al.]5
[Architecture is] the organizational structure and associated behavior of a system. An architecture can be recursively decomposed into parts that interact through interfaces, relationships that connect parts, and constraints for assembling parts. Parts that interact through interfaces include classes, components and subsystems. [UML 1.5]6
The software architecture of a system or a collection of systems consists of all the important design decisions about the software structures and the interactions between those structures that comprise the systems. The design decisions support a desired set of qualities that the system should support to be successful. The design decisions provide a conceptual basis for system development, support, and maintenance. [McGovern]7
Although the definitions are somewhat different, we can see a large degree of commonality. For example, most definitions indicate that an architecture is concerned with both structure and behavior, is concerned with significant decisions only, may conform to an architectural style, is influenced by its stakeholders and its environment, and embodies decisions based on rationale. All of these themes, and others, are discussed below.