Introduction

The term architecture is now widely used outside its traditional connotation of building, and there are many definitions of "architecture" (in the context of systems) and "system (or systems) architecture," for example:

"Systems architecture: the fundamental and unifying system structure defined in terms of system elements, interfaces, processes, constraints, and behaviors." 
[baseline definition approved by the INCOSE Systems Architecture Working Group at INCOSE '96 in Boston, MA on July 8, 1996]

"System architecture comprises the major physical properties, style, structure, interactions, and purpose of a system."
[Process for System Architecture and Requirements Engineering, Derek Hatley, Peter Hruschka, Imtiaz Pirbhai, Dorset House Publishing 2000]

"Architecture: the concepts and rules that define the structure, semantic behavior, and relationships among the parts of a system; a plan of something to be constructed. It includes the elements that comprise the thing, the relationships among those elements, the constraints that affect those relationships, a focus on the parts of the thing, and a focus on the thing as a whole."
[Architecting with RM-ODP, Janis Putman, Prentice Hall PTR 2001, which references ISO/IEC 10746-2: Information Technology - Open Distributed Processing - Reference Model: Foundations, as the source]

"Architecture: the structure of components in a program/system, their interrelationships, and the principles and guidelines governing their design and evolution over time."
[DoD 5000.59-P, "Modeling and Simulation Master Plan," October 1995]

An architecture is "the structure of components, their relationships, and the principles and guidelines governing their design and evolution over time."
[IEEE STD 610.12, extended slightly by the Integrated Architectures Panel (IAP) of the C4ISR Integration Task Force (ITF) in DoD Architecture Framework, Version 1.0]

Different words and constructions are used, and not all the definitions cover exactly the same aspects, but there are significant overlaps. These definitions reveal that system architecture is about the following:

• the structure of the system in terms of the elements, components, and parts
• the relationships between these elements
• the constraints affecting the elements and their relationships
• the behavior exhibited by the system and the interactions that occur between the elements to yield that behavior
• the principles, rules and rationale that made the system the way it is (and govern its evolution)
• the system's physical and logical characteristics and properties
• the purpose of the system

So, to completely convey all these aspects requires a rich and potentially complex information set, but it is necessary to be mindful that not all stakeholders need to see or understand all aspects simultaneously. The idea of viewpoints enables separation of these various concerns and presentation to a class of stakeholders of only what they need for effective participation. From the perspective of a particular viewpoint, you can also view the system at different "resolutions," from low resolution, corresponding to a high level of abstraction, to high resolution, corresponding to a concrete specification (of parts, and so on) for implementation.

Viewpoints

A viewpoint (on a system) is "a form of abstraction achieved using a selected set of architectural concepts and structuring rules, in order to focus on particular concerns within a system" [ISO/IEC 10746-2: Information Technology - Open Distributed Processing - Reference Model: Foundations]. The table lists some of the viewpoints chosen to capture the various concerns. These viewpoints are aligned with those found in ISO/IEC 10746-1: Information technology - Open Distributed Processing - Reference Model: Overview.

Common System Viewpoints.

These viewpoints are some of the most common for software-intensive systems. Many system architectures also require additional, domain-specific viewpoints. Examples include safety, security, and mechanical viewpoints. Viewpoints represent different areas of concern that must be addressed in the system architecture and design. If there are system stakeholders or experts whose concerns are important to the overall architecture, there is likely to be a need for a set of viewpoint work products to capture their design decisions. 

It is important to build a system architecture team with staff who are competent to look after the various viewpoints. The team might consist of business analysts and users who take primary responsibility for the worker viewpoint, software architects who attend to the logical viewpoint, and engineers who concern themselves with the physical viewpoint, as well as experts on domain-specific viewpoints.

Levels of abstraction

In addition to viewpoints, a system architecture requires levels of specification. As the architecture is developed, it evolves from a general, abstract specification to a more specific, detailed specification. RUP identifies four architectural levels, as shown in the table below.

Through these levels, the design goes from the abstract to the physical. The Context Model captures all of the external entities (actors) that interact with the system. These actors might be external to the enterprise that deploys the system or might be internal to the enterprise. In both cases, the actors might be human workers or other systems. At the Analysis level, the partitions do not reflect choices of hardware, software, and people. Instead, they reflect design approaches for dividing up what the system needs to do and how the effort must be distributed. At the Design level, the decisions are made as to the sorts of hardware and software components and worker roles that are needed. At the Implementation level, specific choices of hardware and software technology are made to implement the design. For example, at the Design level, a data server might be specified. At the Implementation level, the decision is made to use a specific platform running a specific database application.

Models and diagrams

A model is a representation of a system, typically addressing some particular area of concern. A system, then, is usually represented by a set of models, because there are multiple concerns for the system's development or use. Each model can be constructed with varying levels of abstraction, from the more general, hiding or encapsulating detail, to the more specific, exposing more detail and explicit design decisions.

A viewpoint, as its name implies, is a notional "position" from which some aspects or concerns about the system are made visible, implying the application of a set of concepts and rules to form a conceptual filter. Usually, it is not sufficient (for understanding) simply to examine the real system—models will have been (or will have to be) constructed to represent and describe the concerns.

Views are projections of models which show entities that are relevant from a particular viewpoint. These projections are typically illustrated by diagrams of some kind.

The intersection of viewpoint and model level of abstraction or specificity contain (or at least identify) views of one or more models relevant to that viewpoint or concern, at that level of abstraction.

The system architecture then is captured in a set of models (and diagrams that visualize them) that express the architecture from various viewpoints and levels. As shown in the model framework table below, there is not a model/diagram for every viewpoint-level combination. At the Implementation level, a single model captures the realization of hardware and software components for each system configuration.

Many of the views specified in the table are derived from standard UML models. For example, in the Analysis level of the Logical viewpoint, the system is decomposed into subsystems that collaborate to meet user requirements. The subsystems are used with the same semantics as in the UML standard. These subsystems, in turn, are decomposed into either subsystems or (ultimately) classes. The Design level of the Logical viewpoint is the view of the detailed Class Model. The Process Model is also a standard UML class model, with the focus on active classes in the system. The domain-specific viewpoints need also have views of work products in place for one or more of the levels. The set of project work products , within this framework, needs to be a part of the project's development case.