Software architecture is a concept that is easy to understand, and that most engineers intuitively feel, especially
with a little experience, but it is hard to define precisely. In particular, it is difficult to draw a sharp line
between design and architecture-architecture is one aspect of design that concentrates on some specific features.
In An Introduction to Software Architecture, David Garlan and Mary Shaw 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." [GAR93]
But there is more to architecture than just structure; the IEEE Working Group on Architecture defines it as "the
highest-level concept of a system in its environment" [IEP1471]. It also encompasses the "fit" with system integrity, with economical
constraints, with aesthetic concerns, and with style. It is not limited to an inward focus, but takes into
consideration the system as a whole in its user environment and its development environment - an outward focus.
The architecture focuses on specific aspects of the overall system design, concentrating on structure, essential
elements, key scenarios and those aspects that have a lasting impact on system qualities such as performance,
reliability, adaptability and cost. It also defines the set of Architectural Mechanisms, Patterns and styles that will guide the rest of the design, assuring its integrity.
Purpose of Architecture
The architecture can be used for many things:
To describe the essential structure of the system and the decisions guiding the structure of the
system so the integrity and understandability of the system is assured.
To provide context and guidance for developers to construct the system by describing the
motivations behind the architectural decisions so those decisions can be robustly implemented. The architecture
services as the blueprint for development. For example, the architect may place constraints on how data is
packaged and communicated between different parts of the system. This may appear to be a burden, but the
justification in the Architecture Notebook can explain that there is a significant performance bottleneck when
communicating with a legacy system. The rest of the system must adapt to this bottleneck by following a specific
data packaging scheme.
To provide an overview of the system to whoever must maintain the architecture, as well as an
understanding of the motivation behind the important technical decisions. Team members who were not involved
in those architectural decisions need to understand the reasoning behind the context of the architecture so
they can best address the needs of the system.
To define the project structure and team organization. Architectural elements make excellent units
of implementation, unit testing, integration, configuration management and documentation. They can
also be used to define so that managers can plan the project.
To speak and reason about software architecture, you must first define an architectural representation, a way of
describing important aspects of an architecture.
The following is some information that is worth capturing as part of the software architecture:
The architecture can contain any information and references that are appropriate in communicating how developers should
build the system.
The architecture can be represented in many forms and from many viewpoints, depending on the needs of the project and
the preferences of the project team. It need not be a formal document. The essence of the architecture can often be
communicated through a series of simple diagrams on a whiteboard; or as a list of decisions. The illustration just
needs to show the nature of the proposed solution, convey the governing ideas, and represent the major building blocks
to make it easier to communicate the architecture to the project team and stakeholders.
If a more complex system is required, then the architecture can be represented as a more comprehensive set
of views that describe the architecture from a number of viewpoints. For more information, see Concept: Architectural Views and Viewpoints.
The architecture can be expressed as a simple metaphor or as a comparison to a predefined architectural style or set of
styles. It may be a precise set of models or documents that describe the various aspects of the system's key elements.
Expressing it as skeletal implementation is another option - although this may need to be baselined and preserved to
ensure that the essence of the system can be understood as the system grows. Choose the medium that best meets the
needs of the project.
Architectural Patterns are ready-made forms that solve recurring architectural problems. An
architectural framework or an architectural infrastructure (middleware) is a set of components on which you can build a
certain kind of architecture. Many of the major architectural difficulties should be resolved in the framework or in
the infrastructure, usually targeted to a specific domain: command and control, MIS, control system, and so on.
[BUS96] groups architectural patterns according to the characteristics of the
systems in which they are most applicable, with one category dealing with more general structuring issues. The table
shows the categories presented in [BUS96] and the patterns they contain.
Pipes and Filters
Refer to [BUS96] for a complete description of these patterns.
A software architecture (or an architectural view) may have an attribute called architectural style, which
reduces the set of possible forms to choose from, and imposes a certain degree of uniformity to the architecture. The
style may be defined by a set of patterns, or by the choice of specific components or connectors as the basic building
Teams should expect to spend more time on architectural issues early in the project. This allows the team to
reduce risk associated to technology early in the project, hence allowing the team to more rapidly reduce the variance
in their estimate on what they can deliver at what time. Examples of architectural issues that needs to be resolved
early on include
Component and their major interfaces
Major technology choices (platform, languages, architecture frameworks / reference architectures, etc.)
Interfaces to external systems
Common services (persistence mechanisms, logging mechanisms, garbage collection, etc.)
Validating the Architecture
The best way to validate the architecture is to actually implement it. For more information, see Executable Architecture.