Views and Viewpoints


This Reference Architecture for SOA follows the ANSI/IEEE Std 1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems [#]. An architectural description conforming to the ANSI/IEEE Std 1471-2000 recommended practice is described by a clause that includes the following six (6) elements:

  1. Architectural description identification, version, and overview information
  2. Identification of the system stakeholders and their concerns judged to be relevant to the architecture
  3. Specifications of each viewpoint that has been selected to organize the representation of the architecture and the rationale for those selections
  4. One or more architectural views
  5. A record of all known inconsistencies among the architectural description’s required constituents
  6. A rationale for selection of the architecture

The ANSI/IEEE Std 1471-2000 defines an architectural description (AD) as “a collection of products to document the architecture,” where architecture is defined as:

A system stakeholder is “an individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system,” where system is defined as:

A stakeholder concern (or care-about) should not be confused with a formal requirement. A concern is an area or topic of interest. Within that concern, system stakeholders may have many different requirements. In other words, something that is of interest or importance is not the same as something that is obligatory or of necessity.

When describing architectures, it is important to identify stakeholder concerns and associate them with viewpoints to insure that those concerns will be addressed in some manner by the models that comprise the views on the architecture. The ANSI/IEEE Std 1471-2000 defines views and viewpoints as follows:

In other words, a view is what the stakeholders see whereas the viewpoint defines the perspective from which the view is taken.

It is important to note that viewpoints are independent of a particular system. In this way, the architect can select a set of candidate viewpoints first, or create a set of candidate viewpoints, and then use those viewpoints to construct specific views that will be used to organize the AD. A view, on the other hand, is specific to a particular system. Therefore, the practice of creating an AD involves first selecting the viewpoints and then using those viewpoints to construct specific views for a particular system or subsystem. Note that the ANSI/IEEE Std 1471-2000 requires that all views correspond to exactly one viewpoint. This helps maintain consistency among architectural views; a normative requirement of the standard (see subclause 5 above).

A view is comprised of one or more architecture models. Each architectural model is developed using the methods established by its associated architectural viewpoint. An architectural model may participate in more than one view.

OASIS SOA-RA Viewpoints

An excellent example of viewpoint capture is described by the ITU-T Rec. X.903 | ISO/IEC 10746-3:1996(E) Reference Model for Open Distributed Processing (RM-ODP), which defines an architectural framework for distributed processing systems [#]. The RM-ODP framework defines five (5) viewpoints for specifying ODP systems: 1) Enterprise Viewpoint, 2) Information Viewpoint, 3) Computational Viewpoint, 4) Engineering Viewpoint, and 5) Technology Viewpoint. Each viewpoint includes a description of the major system stakeholders, the stakeholder concerns, main concepts, viewpoint language/notation, and the role of each viewpoint in the software engineering process (see Table x [#]).

Table x Summary of RM-ODP Viewpoints







Areas of concern

Enterprise needs of IS; Objectives and roles of IS in the organization.

Information models, Information structures, Information flows, Information manipulation.

Logical partioning of application, application components, component interfaces, component interactions ; service-oriented view of distributed application.

Distributed platform infrastructure; distribution transparency, communication support, and other distribution enabling regulating, and hiding generic mechanisms; sytesm-oriented view of distributed application.

Technological artifacts required for realizing engineering mechanisms.

Main concepts

Agents, artifacts, communities, roles, etc.

Schemas, relations, integrity roles, etc.

Computation object, computational interface, environment constraints, computational interactions, etc.

Basic engineering objects, transparency objects, protocol object, nucleus, etc.

Technological solutions corresponding to engineering mechanisms and structures.

Whom does it concern

System procurers, Corporate managers.

Information Analysts, System Analysts, Information Engineers.

Application Designers and Programmers.

Operating System Designers, Communication System Designers, System Designers.

System Integrators, System vendors.


Requirement description languages.

Entity-relationship models, conceptual schemas, etc.

Application programming environment, tools, programming languages, etc.

Distributed platforms, engineering support environments, etc.

Technology mappings, identification of technical artifacts, etc.

Role in Software Engineering

Requirement capture and early design of distributed system.

Conceptual design and information modeling.

Software design and development.

System design and development.

Technology identification, procurement, installation.

For this SOA reference architecture, the following set of n (n) architectural viewpoints are defined: (Note the leverage of one of the ITU-T | ISO/IEC RM-ODP viewpoints—Information Viewpoint—for capture of SOA data models, information structures and semantics, information flows, and information manipulation.)

  1. X Viewpoint: Directed
  2. Information Viewpoint: Focuses on the information content of SOA. The information modeling activity involves identifying information elements of the system, manipulations that may be performed on information elements, and the information flows in the system.
  3. X Viewpoint:
  4. X Viewpoint:
  5. X Viewpoint:

These viewpoints are used to construct the set of views used in organizing the architectural description of this SOA reference architecture. In addition, it is expected that these viewpoints will serve as a reference set (library) of viewpoints on which to construct architectural views for specific or concrete SOA-based architectures.

Candidate viewpoint sets (for subcommittee discussion):

Note: Variants of the above (not defined as viewpoints per se), e.g., “models,” or “service abstractions” come from Newcomer & Lomow and BAH ForeGov pitch (slide 30).

Should define viewpoints in following format:

Can also create a visual model of the views and viewpoints using the Systems Modeling Language (SysML) 1.0-DRAFT. We’ll want to organize the SOA-RA in this way and perhaps add such a diagram to each section (at the beginning or end).



[#] ANSI/IEEE Std 1471-2000, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, The Institute of Electrical and Electronic Engineers, Inc., New York, NY, 2000.

[#] ITU-T Rec. X.903 | ISO/IEC 10746-3:1996(E), Information technology—Open Distributed Processing—Reference Model: Architecture, International Telecommunication Union, International Organization for Standardization and International Electrotechnical Commission, Geneva, Switzerland, 1996.

[#] Farooqui, Kazi, Logrippo, Luigi and Jan de Meer, “The ISO Reference Model for Open Distributed Processing—An Introduction,” White Paper, Department of Computer Science, University of Ottawa, Ottawa, Canada and Research Institute for Open Communication Systems (GMD-FOKUS), Berlin, Germany, Feb. 14, 1996.

TheArchitecture/ViewsAndViewpoints (last edited 2009-08-12 18:05:13 by localhost)