architecture is a set of components and connections among them and it should
satisfy following requirements like:
· What is the nature of the
· What are the responsibilities of
· What is the significance of the
· What is the significance of the
Why Is Software Architecture
There are fundamentally three reasons for software
1. Communication among stakeholders. Software architecture represents a common abstraction of a system that most if not all of the
system's stakeholders can use as a basis for mutual understanding, negotiation,
consensus, and communication.
2. Early design decisions. Software architecture manifests the earliest design decisions about a system, and these
early bindings carry weight far out of proportion to their individual gravity
with respect to the system's remaining development, its deployment, and its
maintenance life. It is also the earliest point at which design decisions
governing the system to be built can be analyzed.
3. Transferable abstraction of a system. Software architecture constitutes a relatively small, intellectually graspable model for how a system
is structured and how its elements work together, and this model is
transferable across systems. In particular, it can be applied to other systems
exhibiting similar quality attribute and functional requirements and can
promote large-scale re-use.
We will address each of these points in turn.
1. Communication among Stakeholders:
1. Each stakeholder of a software system—customer, user, project
manager, coder, tester, and so on—is concerned with different system
characteristics that are affected by the architecture.
2. For example, the user is concerned that the system is reliable
and available when needed; the customer is concerned that the architecture can
be implemented on schedule and to budget; the manager is worried (as well as
about cost and schedule) that the architecture will allow teams to work largely
independently, interacting in disciplined and controlled ways. The architect is
worried about strategies to achieve all of those goals.
Architecture provides a common language in which different
concerns can be expressed, negotiated, and resolved at a level that is
intellectually manageable even for large, complex systems (see the sidebar What
Happens When I Push This Button?). Without such a language, it is difficult to
understand large systems sufficiently to make the early decisions that
influence both quality and usefulness.
2. Early design
Software architecture represents a system's earliest set of
design decisions. These early decisions are the most difficult to get correct
and the hardest to change later in the development process, and they have the
most far-reaching effects.
The Architecture Defines Constraints
1. An implementation exhibits an architecture if it conforms to the
structural design decisions described by the architecture.
2. This means that the implementation must be divided into the
prescribed elements, the elements must interact with each
other in the prescribed fashion, and each element must fulfill its
responsibility to the others as dictated by the architecture.
3. Resource allocation decisions also constrain implementations.
4. These decisions may be invisible to implementors working on
5. The constraints permit a separation of concerns that allows
management decisions to make the best use of personnel and computational
6. Element builders must be fluent in the specification of their
individual elements but not in architectural tradeoffs.
7. Conversely, architects need not be experts in all aspects of
algorithm design or the intricacies of the programming language, but they are
the ones responsible for the architectural tradeoffs.
The Architecture Dictates
1. Not only does architecture prescribe the structure of the system
being developed, but that structure becomes engraved in the structure of the
development project (and sometimes, the structure of the entire organization).
2. The normal method for dividing up the labor in a large system is
to assign different groups different portions of the system to construct.
3. This is called the work breakdown structure of a system.
4. Because the system architecture includes the highest-level
decomposition of the system, it is typically used as the basis for the work
breakdown structure, which in turn dictates units of planning, scheduling, and
budget; interteam communication channels; configuration control and file system
organization; integration and test plans and procedures; and even minutiae such
as how the project intranet is organized and how many team picnics there are.
5. Teams communicate with each other in terms of the interface
specifications to the major elements.
6. The maintenance activity, when launched, will also reflect the
software structure, with teams formed to maintain specific structural elements.
A side effect of establishing the work breakdown structure is to
freeze some aspects of the software architecture. A group that is responsible
for one of the subsystems will resist having its responsibilities distributed
across other groups. If these responsibilities have been formalized in a
contractual relationship, changing them can become expensive. Tracking progress
on a collection of tasks being distributed also becomes much more difficult.
Once the architecture has been agreed on, then, it becomes
almost impossible, for managerial and business reasons, to modify it. This is
one argument (among many) for carrying out a comprehensive evaluation before
freezing the software architecture for a large system.