Purpose and Scope of Architectural Analysis

The purpose of the architectural analysis phase is to define the technological requirements of the problem domain. It is possible that the the architecture you will use for your implementation already exists. Mapping the requirements of the problem domain against the existing architecture will allow you to:

1. Identify specific deficiencies in the current architecture and provide a means to evaluate the cost/benefit of the needed changes, or
2. Validate the current architecture.

Mapping the needs of your problem domain against the existing architecture also prevents you from being blindsided in subsequent phases by limitations or shortcomings of the architecture.

The key task of the architectural analysis phase is to uncover user expectations that will place specific requirements on the architecture you will use for your implementation. Issues such as security, number of users, data and processing distribution, shared resources, response time, real-time versus batch processing. All these things directly affect your architectural choices and should be thoroughly analyzed.

The choices you make during the architectural analysis phase will in turn directly affect--and sometimes even dictate or eliminate--your choices during the object design phase.

The architectural analysis phase is not the time to discuss programming or design options. To proceed with object design without first defining the architecture of your implementation environment can lead to wasted development time and resources. Technology, topology, and the system resources that make up the architecture of the problem domain will dictate many of your design and programming options.

There are times when programming languages provide architectural options, for example, Java’s Remote Method Invocation (RMI) feature. If you choose to incorporate such programming language features, just remember that you are choosing to define your architecture by a current technology; technology whose hallmark is rapid and constant change. Architectural choices are by their very nature limiting. Defining your architecture according to requirements rather than according to a current technology option will always result in a more flexible architectural model.

Software application architecture is the process of defining a structured solution that meets all of the technical and operational requirements, while optimizing common quality attributes such as performance, security, and manageability. It involves a series of decisions based on a wide range of factors, and each of these decisions can have considerable impact on the quality, performance, maintainability, and overall success of the application.
Philippe Kruchten, Grady Booch, Kurt Bittner, and Rich Reitman derived and refined a definition of architecture based on work by Mary Shaw and David Garlan .Their definition is: Software architecture encompasses the set of significant decisions about the organization of a software system including the selection of the structural elements and their interfaces by which the system is composed; behavior as specified in collaboration among those elements; composition of these structural and behavioral elements into larger subsystems; and an architectural style that guides this organization. Software architecture also involves functionality, usability, resilience, performance, reuse, comprehensibility, economic and technology constraints, tradeoffs and aesthetic concerns.
In Patterns of Enterprise Application Architecture, Martin Fowler outlines some common recurring themes when explaining architecture. He identifies these themes as:
The highest-level breakdown of a system into its parts; the decisions that are hard to change; there are multiple architectures in a system; what is architecturally significant can change over a system's lifetime; and, in the end, architecture boils down to whatever the important stuff is.
In Software Architecture in Practice (2nd edition), Bass, Clements, and Kazman define architecture as follows:
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. Architecture is concerned with the public side of interfaces; private details of elements "details having to do solely with internal implementation" are not architectural.