"I am the Architect. I created the Matrix. I've been waiting for you. You have many questions, and although the process has altered your consciousness, you remain irrevocably human. Ergo, some of my answers you will understand, and some of them you will not."
— The Architect, in "Matrix Reloaded".
"The ideal architect should be a person of letters, a mathematician, familiar with historical studies, a diligent student of philosophy, acquainted with music, not ignorant of medicine, learned in the responses of jurisconsults, familiar with astronomy and astronomical calculations."
— Vitruvius, circa 25 BC
Vitruvius was not referring to a software architect, but the basic idea is that the architect should should be a person who is:
For architects to be well-rounded, they must have a working knowledge of the business or problem domain. They can gain this knowledge through experience or education. In addition, architects must have a broad knowledge of technology. An architect might have first-hand experience with a particular technology, but they must have at least a general understanding of competing technologies to make informed decisions about which technology can work best. A good architect evaluates all possible solutions to a problem regardless of the technology being used.
What does the architect do? What is the difference between an architect compared with a senior developer? These are some of the common questions asked. The designer is concerned with what happens when a user presses a button and the architect is concerned with what happens when ten thousand users press a button. An architect mitigates the technical risks associated with a system. A technical risk is something that is unknown, unproven, or untested. Risks are usually associated with the service-level requirements and can occasionally be associated with a business requirement. Regardless of the type of risk, it is easier to address the risks early in the project while creating an architecture, then to wait until construction when you have a large developer base that could potentially be waiting while risks are solved.
An architect must lead the development team to ensure the designers and developers build the system according to the architecture. As the leader, difficult decisions must be made about trade-offs in the system and the architect is the person who must make those decisions. To lead, the architect must be a good written and oral communicator. It is up to the architect to communicate the system to the designers and developers who will build it. This is typically done with visual models and group discussions. If the architect cannot communicate effectively, then the designers and developers will probably not build the system correctly.
Reference: [CADE]
A trade-off usually refers to losing one quality or aspect of something in return for gaining another quality or aspect. It implies a decision to be made with full comprehension of both the upside and downside of a particular choice. For example, in a shoe repair shop you might see something like this:
SPEED, PRICE, QUALITY: Pick two.
Reference: Wikipedia
A software architecture is a description of the subsystems and components of a software system and the relationships between them. Subsystems and components are typically specified in different views to show the relevant functional and non-functional properties of a software system. The software architecture of a system is an artifact. It is the result of the software design activity.
Reference: [BUSCHMANN]
"[Software] architecture, like other architecture, is the art of determining the needs of the user of a structure and then designing to meet those needs as effectively as possible within economic and technological constraints. Architecture must include engineering considerations, so that the design will be economical and feasible; but the emphasis in architecture is on the needs of the user, whereas in engineering the emphasis is on the needs of the fabricator."
— Frederick Brooks
A component is an encapsulated part of a software system that serves as a building block for the structure of a system.
Components have the following properties:
At a programming-level, components may be represented as modules, objects or a set of related functions. The term "component" is — at least at first sight — independent of its eventual manifestation in source code.
Reference: [BUSCHMANN]
A relationship denotes a connection between two components. A relationship may be:
Reference: [BUSCHMANN]
A view represents a partial aspect of a software architecture that shows specific properties of a software system.
Reference: [BUSCHMANN]
Architectural views can be divided into three groups, depending on the broad nature of the elements they show:
These three views correspond to the three broad types of decisions that architectural design involves:
Reference: [BASS]
In addition to the business requirements of a system, you must satisfy the service-level or quality of service (QoS) requirements. As an architect, it is your job to work with the stakeholders of the system during the inception and elaboration phases to define a quality of service measurement for each of the service-level requirements. The architecture you create must address the following service-level requirements: performance, scalability, reliability, availability, extensibility, maintainability, manageability, and security. You will have to make trade-offs between these requirements. For example, if the most important service-level requirement is the performance of the system, you might sacrifice the maintainability and extensibility of the system to ensure that you meet the performance quality of service. As the expanding Internet opens more computing opportunities, the service-level requirements are becoming increasingly important as the users of these Internet systems are no longer just the company employees, but they are now the company's customers.
Reference: [CADE]
A pattern describes a particular recurring design problem that arises in specific contexts and presents a well-proven generic scheme for its solution. The solution scheme is specified by describing its constituent components, their responsibilities and relationships, and the ways in which they collaborate.
Software patterns can be classified in three categories:
Reference: [BUSCHMANN]
A framework is a partially complete software (sub-)system that is intended to be instantiated. It define the architecture for a family of (sub-) systems and provides the basic building blocks to create them. It also defines the places where adaptations for specific functionality should be made. In an object oriented environment, a framework consists of abstract and concrete classes.
The instantiation of a framework involves composing and subclassing the existing classes. A framework consists of:
Reference: [BUSCHMANN]