All software architectures exhibit a common set of characteristics. Let us look at some of the most important ones here.
An architecture of a system is best represented as structural details of the system. It is a common practice for practitioners to draw the system architecture as a structural component or class diagram in order to represent the relationships between the subsystems.
For example, the following architecture diagram describes the backend of an application that reads from a tiered database system, which is loaded using an ETL process:
Structures provide insight into architectures, and provide a unique perspective to analyze the architecture with respect to its quality attributes.
Some examples are as follows:
A well-defined architecture clearly captures only the core set of structural elements required to build the core functionality of the system, and which have a lasting effect on the system. It does not set out to document everything about every component of the system.
For example, an architect describing the architecture of a user interacting with a web server for browsing web pages—a typical client/server architecture—would focus mainly on two components: the user's browser (client) and the remote web server (server), which form the core elements of the system.
The system may have other components such as multiple caching proxies in the path from the server to the client, or a remote cache on the server which speeds up web page delivery. However, this is not the focus of the architecture description.
This is a corollary to the characteristics described previously. The decisions that help an architect to focus on some core elements of the system (and their interactions) are a result of the early design decisions about a system. Thus, these decisions play a major role in further development of the system due to their initial weight.
For example, an architect may make the following early design decisions after careful analysis of the requirements for a system:
Early design decisions need to be arrived at after careful analysis of the requirements and matching them with the constraints—such as organizational, technical, people, and time constraints.
A system is designed and built, ultimately, at the behest of its stakeholders. However, it is not possible to address each stakeholder requirement to its fullest due to an often contradictory nature of such requirements. Following are some examples:
The system structures an architecture describes, quite often have a direct mapping to the structure of the teams that build those systems.
For example, an architecture may have a data access layer which describes a set of services that read and write large sets of data—it is natural that such a system gets functionally assigned to the database team, which already has the required skill sets.
Since the architecture of a system is its best description of the top-down structures, it is also often used as the basis for the task-breakdown structures. Thus, software architecture often has a direct bearing on the organizational structures that build it:
The following diagram shows the mapping to the team structure which would be building this application:
An environment imposes outside constraints or limits within which an architecture must function. In the literature, these are often called architecture in context [Ref: Bass, Kazman]. Some examples are as follows:
Architecture choices also arise from one's own education and professional training, and also from the influence of one's professional peers.
Every system has an architecture, whether it is officially documented or not. However, properly documented architectures can function as an effective documentation for the system. Since an architecture captures the system's initial requirements, constraints, and stakeholder trade-offs, it is a good practice to document it properly. The documentation can be used as a basis for training later on. It also helps in continued stakeholder communication, and for subsequent iterations of the architecture based on changing requirements.
The simplest way to document an architecture is to create diagrams for the different aspects of the system and organizational architecture such as Component Architecture, Deployment Architecture, Communication Architecture, and the Team or Enterprise Architecture.
Other data that can be captured early include the system requirements, constraints, early design decisions, and rationale for those decisions.
Most architectures conform to certain sets of styles which have had a lot of success in practice. These are referred to as architectural patterns. Examples of such patterns are client-server, pipes and filters, data-based architectures, and others. When an architect chooses an existing pattern, he/she gets to refer to and reuse a lot of existing use cases and examples related to such patterns. In modern day architectures, the job of the architect comes down to mixing and matching existing sets of such readily available patterns to solve the problem at hand.
For example, the following diagram shows an example of a client-server architecture:
The following diagram describes another common architecture pattern, namely, the pipes and filters architecture for processing streams of data:
We will see examples of architectural patterns later in this book.
3.21.104.183