For decades, software designers have been taught to build system based exclusively on statements of the technical requirements. Conceptually, the requirements document gets tossed over the wall into the designer's cubicle, and the designer must come forth with a satisfactory design: Requirements begets design begets system. Of course, modern software development methods recognize the naivete of this model, and provide all sorts of feedback loops from designer to analyst. But they still make the implicit assumption that design is a product of the system's technical requirements, period.
Architecture has emerged as a crucial part of the design process But until recently, architectural design has been discussed in the same light: If you know the requirements for a system, you can build the architecture for it. This is short-sighted and fails to tell the whole story. If two different architects, working in two different organizations, were given the same requirements specification for a system they would almost certainly produce different architectures. This immediately belies the notion that requirements determine architecture. Other factors are at work, and to fail to recognize those factors is to continue working in the dark.
The focusing question is this: What is the relationship of a system's software architecture to the environment in which the system will be constructed and will exist? Software architecture is a result of technical, business and social influences. The existence of the software architecture in turn affects the technical, business, and social environments subsequently influence future architectures.
People often make analogies to other uses of the word architecture, about which they have some intuition. They commonly associate architecture with physical structure (building, streets, hardware) and physical arrangement. A building architect must design a building that provides accessibility, aesthetics, light, maintainability, etc. A software architect must design a system that provides concurrency, portability, modifiability, usability, security, etc., and the trade-offs among these needs. Analogies between buildings and software systems should not be taken literally; they break down fairly quickly. Rather, such analogies are used to help us understand that the viewers perspective is important and structure can have different meanings depending upon the motivation for examining it. A precise definition of software architecture is not nearly as important as what investigation of the concept allows us to do.
Fundamentally, there are three reasons why software architecture is important:
1. Communication among stakeholders. Software architecture represents a common high-level abstraction of a system that most if not all of the systems stakeholders can use as a basis for creating mutual understanding, forming consensus, and communicating with each other. Thus a representation for an architecture should be easy to understand, have a precise semantics, and have supporting software.
2. Early design decisions. Software architecture represents the manifestation of 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 systems remaining development, its deployment, and its maintenance life. It is also the earliest point at which 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 components work together; this model is transferable across systems; in particular, it can be applied to other systems exhibiting similar requirements and can promote large-scale reuse.