The concept of views and viewpoints is widely used across the architectural community, having originated back in the 1970’s where Ross’s Structure Analysis and Design Technique used them, the concept of Views became widely accepted following the development of Kruchten’s 4 + 1 architecture view model, they have since been formalized in the  ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description.

The principles of views and viewpoints are defined in slightly different ways in different places; the definitions adopted by IASA are:

  • An architectural view is a representation of one or more aspects of an architecture that illustrates how the architecture addresses the concerns held by one or more of its stakeholders.
  • A viewpoint is a collection of patterns, templates, and conventions for constructing one type of view. It defines the stakeholders whose concerns are reflected in the viewpoint and the guidelines, principles, and template models for constructing its views.

An example would be to use an operational viewpoint to create a view targeted at the Help Desk manager. The viewpoint is the template that contains information relevant to the operations of the system, and a view is the end product delivered to someone interested in maintaining the operational capability.

IT architects must have the ability to compare/contrast concept of views, viewpoints, and perspectives, understand the differences between them and how they work together to describe an architecture. They must be able to discern various stakeholder groups typical of IT development projects, describing the typical viewpoint of each group, and determine the set of views needed to satisfy project requirements.

One of the main activities and responsibilities of the architect is to present the vision of the system to the stakeholders interested in it. In anything other than the most trivial of systems it is not possible to show this in a single diagram, although sometimes this is attempted, so the concept of views and viewpoints has been developed to provide the appropriate information in an appropriate way for each set of stakeholders.

The architect has to understand the organization and the problem space to identify the appropriate framework to use for a particular architectural problem. The ISO 42010 defines the relationship between the elements of an architecture, its stakeholders and the description, as shown below:

Figure 1. Excerpt from Conceptual Framework of ISO42010

Most architecture documents include a set of views and viewpoints which comprise the main content of the document. In a general sense the key viewpoints common to many architectural frameworks will include a description of the functions required, the data structures to be held, a description of the processing to be carried, how the software is developed and managed and how the software is deployed on the infrastructure.

There are a number of architectural frameworks available to use, a comprehensive list is available here: http://www.iso-architecture.org/42010/afs/frameworks-table.html. For software intensive systems the following models are commonly used:

  • Kruchten’s 4 + 1 architecture view model
  • Views and Beyond – Documenting Software Architectures
  • Rozanski and Woods Software Systems Architecture

For Enterprise Architecture there is a wide range of frameworks, some of the commnly used ones include:

  • TOGAF 9.1
  • Architmate
  • FEAF

A description of the viewpoint sets listed above are provided in this catalogue.