IEEE 1471-2000™ Conceptual Framework for Architectural Description

For historical reasons, here is the conceptual framework that was a part of IEEE 1471-2000 (adopted by ISO as ISO/IEC 42010:2007).

See current conceptual model for ISO/IEC/IEEE 42010 [here].

IEEE 1471-2000 conceptual framework

The diagram above captures the conceptual framework of the 2000/2007 edition of the standard via a UML class diagram. The diagram has two purposes in the standard: to establish terminology for stating requirements on architectural descriptions (the subject matter of the standard); and to offer the community a conceptual basis for continued evolution of practices in the field. The discussion here will stick to the terms of the 2000/2007 edition, but may allude to some clarifications considered by subsequent joint IEEE and ISO revisions.

The standard takes no position on the question, What is a system? It could be an application, a subsystem, a service, a product line, a system of systems or an enterprise. The system may be man-made or natural. The premise of the standard is, If you have a system of interest, the standard provides guidance for documenting that system's architecture. Nothing in the standard depends upon a specific definition of system.
Most systems exist to fulfill one or more missions, or functions or objectives. The architecture should help the system meet its missions.
A system exists within an environment. The system acts upon that environment and vice versa. A system's environment determines the range of influences upon the system. In the standard we intend environment in the widest possible sense to include all relevant operational, developmental, regulatory, etc. influences.
Every system has an architecture. In fact, a system could have many architectures. In IEEE 1471, an architecture is a conception of a system. There may be many conceptions of a system. Within the scope of use of the standard, when one is sitting down to produce an architectural description (AD), there is exacly one architecture (concept) being documented.

NOTE: The entities above, System, Mission, Environment and Architecture, are all conceptual in nature. There are no requirements ("shalls") in the standard pertaining to these entities. The requirements in the standard apply to the items below which pertain to the concrete representation of an architecture.

Architectural Description
An architectural description (AD) is an collection of artifacts or work products used to describe an architecture. Architectural descriptions are the primary subject of the standard. Any architecture may be described by one or more architecture descriptions (not shown in diagram). In the standard, an AD describes exactly one architecture for a system of interest. An architecture description, per the standard, is made up of various contents: identification of stakeholders, architectural concerns, architectural viewpoints, architectural views and architectural models.
A stakeholder is any person, organization or group with an interest in the system. Examples of stakeholders: architect, designer, client, user, maintainer, auditor, and certification authority. Within the standard, a stakeholder has one or more (architectural) concerns pertaining to the system of interest.
(Architectural) Concern
A concern is any interest in the system. The term is derived from the phrase "separation of concerns" as in Software Engineering. A concern may be held by one or more stakeholders.

NOTE: Just as an architectural description is a concrete representation of an architecture, the identification of a system's stakeholders and concerns is a concrete representation of its environment in terms of its influences.

(Architectural) Viewpoint
A viewpoint is a set of conventions for constructing, interpreting and analyzing a view in terms of viewpoint languages and notations, modeling methods and analytic techniques to be used to address a set of concerns held by stakeholders. A viewpoint covers 1 or more concerns and stakeholders
(Architectural) View
A view is a representation of the whole system from the perspective of a related set of concerns. A view conforms to exactly one viewpoint.
(Architectural) Model
A view is comprised of one or more models. Each model is constructed in accordance with conventions established by the viewpoint. A model may be a part of one or more views. Models provide for sharing details between views and for the use of multiple viewpoint languages within a view.
Library Viewpoint
A library viewpoint is one that is predefined (reusable) and does not need to be spelled out within an AD in which it is used.
(Architectural) Rationale
Rationale captures the reasons why certain architectural choices have been made (such as viewpoints selected for use, and architectural decisions).
Resources for this website, in support of the revision of ISO/IEC/IEEE 42010, provided by Comments, corrections, suggestions on this site to: Webmaster.