Architecture

(Alias: System Architecture, Software Architecture, Hardware Architecture, Architecture Views)

We are now ready to come to grips with the most basic problem of a building or a town: what is it made of? What is its structure, what is its physical essence? What are the building blocks of which its space is made?
- Christopher Alexander, The Timeless Way of Building

p 81

In the context of software and electronic systems an architecture is a particular arrangement of various hardware and software components that makes up a unique system. All systems are designed to achieve some human purpose: The web application Facebook connects people in a social network, an aircraft transports people long distances. A Boeing spokesman once quipped, "We view a 777 airliner as a collection of parts flying in close proximity." The job of a systems architect is to manage the design of these complex systems, and systems of systems such as the 777, to make sure that when put into service a particular system fits its assigned purpose and that none of its parts "break formation" to cause harm to people or property.
Architectural descriptions deal with complexity by decomposing systems into design entities such as sub-systems and components. Architectural blueprints describe this decomposition in terms of physical and logical structures, their components, their interfaces and the mechanisms they use to communicate both internally and with external systems and human beings.

Figure 1. An Example of a Physical System Architecture

Describing an Architecture

Architectural structures are described in terms of:

Physical arrangement of components. Figure 1 depicts the physical arrangement of an underground railway station Environmental Control System (ECS).
Logical arrangement of components. Figure 2 depicts the logical arrangement of an Air Traffic Control System described with a layered architecture model. At the next level of detail, assuming an object oriented approach, this arrangement may be fleshed out with object models such as class diagrams, communication diagrams and sequence diagrams.
Physical arrangement of code. For software intensive systems the arhcitecture maps the various code units onto the physical processors that execute them and describes the high level structure of the code.
Component interfaces. Interactions between components including, communications protocols, message structures, control structures and synchronisation. Figure 1 identifies communications links between the various components of the ECS and identifies communications protocols. The scope of interfaces also includes the modes of interaction with human operators and the associated human factors.
System behaviour. The dynamic response of the system to events. System behaviours are typically described with use cases that illustrate how various components of the architecture interact to achieve some required result.
Design styles. Selection of appropriate architectural styles and design patterns. For example, client/server model, supervisory control, direct digital control, pipe and filter architectural style, layered architecture, model-view-controller architecture. The rationales for design decisions are also recorded.
Allocation of system requirements to components. A detailed mapping of all system requirements to system components.

Figure 2. A Logical Architecture for an Air Traffic Control System

Architectural Views

The latest thinking in architecture descriptions recommends the concept of architectural design views. Views describe a system from the viewpoint of different stakeholders such as end-users, developers and project managers. Philippe Kruchten [Kruchten 95] describes an architecture for software intensive systems called "the 4+1 Architectural View Model". It is based on the use of multiple, concurrent views. Other examples of view based architectural descriptions can be found in:

The US Department of Defense Architecture Framework [DoDAF]
UK Ministry of Defence Architecture Framework [MoDAF]
UK Department for Transport Enterprise Architecture Framework [TRAK]
ISO/IEC 42010 Systems and software engineering - Architecture description [IEC 42010]. This standard aims to standardise the practice of architecture description by defining standard terms, presenting a conceptual model for expressing, communicating and reviewing architectures and specifying requirements that apply to architecture descriptions, architecture frameworks and architecture description languages.

Describing the Nonfunctional Characteristics of the Architecture

An architecture description also indicates how non functional requirements will be satisfied. For example:

Specification of system/component performance. For example, data throughput and response times as a function of concurrent users.
Consideration of scalability. For example, can an air traffic control system designed to manage 100 aircraft be extended to manage 1000 aircraft?
System availability. For example, elements of the design that enable a system to operate 24/7.
Safety integrity. Elements of the design that reduce the risk that the system will cause (or allow causation of) harm to property and human beings.
Fault tolerance. Elements of the design that allow the system to continue to operate if some components fail (e.g. no single point of failure).
Consideration of product evolution. The facility for individual components to be modified or dynamically reconfigured without the need for major modification of the system as a whole. Further, the ability to add functionality with new components in a cost effective manner.
Consideration of the emergent qualities of the system as a whole when components are assembled and operated by human beings. For example, can the missile launch system be effectively operated in a high stress combat situation?

Why Architecture Descriptions are Important

A detailed and on-going consideration of architecture is necessary as we build larger, more complex and more life critical systems involving both hardware and software. An architecture description is the most important artifact for achieving design understanding in a development team. It is also a thinking document performing high-level analysis and providing a vehicle for validating the architectural design and identifying any design deficiencies.

Architectural Documentation

To fulfill its role in the design effort an architecture must be formally documented. Figure 3 depicts a typical documentation tree for a large software and electronic system and highlights the relationships of architectural descriptions to other product specifications. The architecture is first described in a System Architecture Specification (SyAS). The SyAS allocates system level requirements to hardware and software components. These requirements are fleshed out further in Hardware and Software Requirements Specifications. The hardware and software architectures are then described in Hardware Architecture Design Descriptions (HADDs) and Software Architecture Design Descriptions (SADDs).

A pure software product is described with a Software Architecture Design Description.