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:2011Systems 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 sometime 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.

Proven Practices

There are a number of architectural frameworks available to use, a comprehensive list is available here: For software intensive systems the following models are commonly used:

Kruchten’s 4 + 1 architecture view model

This approach forms the basis of the Rational Unified Process has a small set of fixed views defined, with viewpoints implied rather than being explicitly identified

The views of the model are concerned with:

  • Logical view: The logical view is concerned with the functionality that the system provides to end-users. UML Diagrams used to represent the logical view include Class diagramCommunication diagramSequence diagram.
  • Development view: The development view illustrates a system from a programmer’s perspective and is concerned with software management. This view is also known as the implementation view. It uses the UML Component diagram to describe system components. UML Diagrams used to represent the development view include the Package diagram.
  • Process view: The process view deals with the dynamic aspects of the system, explains the system processes and how they communicate, and focuses on the runtime behavior of the system. The process view addresses concurrency, distribution, integrators, performance, and scalability, etc. UML Diagrams to represent process view include the Activity diagram.
  • Physical view: The physical view depicts the system from a system engineer’s point of view. It is concerned with the topology of software components on the physical layer, as well as the physical connections between these components. This view is also known as the deployment view. UML Diagrams used to represent physical view include the Deployment diagram.
  • Scenarios: The description of an architecture is illustrated using a small set of use cases, or scenarios which become a fifth view. The scenarios describe sequences of interactions between objects, and between processes. They are used to identify architectural elements and to illustrate and validate the architecture design. They also serve as a starting point for tests of an architecture prototype. This view is also known as use case view.

Views and Beyond – Documenting Software Architectures

The V&B approach promotes a stakeholder-based view selection, but extends the concept to recognize that documentation beyond views is also essential to provide holistic insight into the overall design approach embodied by the architecture and the decision made in arriving at the architecture. The V&B approach takes a software centric stance and focuses on the structure of the software, the relationships between software components, and how the software relates to the external environment, it classifies views into 3 types:

  • Module views – Modules represent a code-based way of considering the system. Modules are assigned areas of functional responsibility, and are assigned to teams for implementation. There is less emphasis on how the resulting software manifests itself at runtime. Module structures allow us to answer questions such as: What is the primary functional responsibility assigned to each module? What other software elements is a module allowed to use? What other software does it actually use? What modules are related to other modules by generalization or specialization (i.e., inheritance) relationships?
  • Component-and-connector views – Here, the elements are runtime components (which are principal units of computation) and connectors (which are the communication vehicles among components). Component and connector structures help answer questions such as: What are the major executing components and how do they interact? What are the major shared data stores? Which parts of the system are replicated? How does data progress through the system? What parts of the system can run in parallel? How can the system’s structure change as it executes?
  • Allocation views – These views show the relationship between the software elements and elements in one or more external environments in which the software is created and executed. Allocation structures answer questions such as: What processor does each software element execute on? In what files is each element stored during development, testing, and system building? What is the assignment of the software element to development teams?


The most comprehensive set of viewpoints is provided in Rozanski and Woods Software Systems Architecture, and includes the following:

  • Context Describes the relationships, dependencies, and interactions between the system and its environment (the people, systems, and external entities with which it interacts). Many architecture descriptions focus on views that model the system’s internal structures, data elements, interactions, and operation. Architects tend to assume that the “outward-facing” information — the system’s runtime context, its scope and requirements, and so forth – is clearly and unambiguously defined elsewhere. However, you often need to include a definition of the system’s context as part of your architectural description.
  • Functional Describes the system’s functional elements, their responsibilities, interfaces, and primary interactions. A Functional view is the cornerstone of most ADs and is often the first part of the description that stakeholders try to read. It drives the shape of other system structures such as the information structure, concurrency structure, deployment structure, and so on. It also has a significant impact on the system’s quality properties such as its ability to change, its ability to be secured, and its runtime performance.
  • Information Describes the way that the architecture stores, manipulates, manages, and distributes information. The ultimate purpose of virtually any computer system is to manipulate information in some form, and this viewpoint develops a complete but high-level view of static data structure and information flow. The objective of this analysis is to answer the big questions around content, structure, ownership, latency, references, and data migration.
  • Concurrency Describes the concurrency structure of the system and maps functional elements to concurrency units to clearly identify the parts of the system that can execute concurrently and how this is coordinated and controlled. This entails the creation of models that show the process and thread structures that the system will use and the interprocess communication mechanisms used to coordinate their operation.
  • Development Describes the architecture that supports the software development process. Development views communicate the aspects of the architecture of interest to those stakeholders involved in building, testing, maintaining, and enhancing the system.
  • Deployment Describes the environment into which the system will be deployed, including capturing the dependencies the system has on its runtime environment. This view captures the hardware environment that your system needs (primarily the processing nodes, network interconnections, and disk storage facilities required), the technical environment requirements for each element, and the mapping of the software elements to the runtime environment that will execute them.
  • Operational Describes how the system will be operated, administered, and supported when it is running in its production environment. For all but the simplest systems, installing, managing, and operating the system is a significant task that must be considered and planned at design time. The aim of the Operational viewpoint is to identify system-wide strategies for addressing the operational concerns of the system’s stakeholders and to identify solutions that address these.


Although primarily intend for Enterprise Architecture, TOGAF is used by some organisations for software projects, here the concept of Domain is sometimes used in a similar way to viewspoints, although this is not the correct use of Domains, as they are defined as being the commonly accepted  subsets of an overall enterprise architecture. The following are defined in TOGAF:

  • The Business Architecture defines the business strategy, governance, organization, and key business processes.
  • The Data Architecture describes the structure of an organization’s logical and physical data assets and data management resources.
  • The Application Architecture provides a blueprint for the individual applications to be deployed, their interactions, and their relationships to the core business processes of the organization.
  • The Technology Architecture describes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, standards, etc.


In support of TOGAF, Archimate defines 18 standard viewpoints to cover the enterprise architecture, focused on different sets of stakeholders. These are comprehensively documented on the Open Group Archimate website.

Sub-Components Skills

Selecting the Appropriate Set of Views or Viewpoints

Often an organization will mandate a framework which is frequently defined in the template for the architecture document, but sometimes it will be up to the architect to make the selection. This will depend on the level of the architecture being defined and the type of system or systems being described. However, experience will allow you to extend the set of views as needed, especially if the mandated framework only has a few views, in frameworks where Security is not explicitly defined as a perspective, it often gets added as an extra view.

Iasa Certification Level Learning Objective
CITA- Foundation
  • Learner will be able to describe views and viewpoints, and understand what they are
  • Learner will be able to name some of the different types of views and viewpoints
CITA – Associate
  • Learner will be able to describe the differences between various views and viewpoints
  • Learner will be able to describe the key elements of the commonly used views and viewpoints (covering functional, information and deployment as a minimum)
CITA – Specialist
  • Learner will be able to describe when it is most appropriate to use which views and viewpoints, and highlight the advantages and disadvantages of each
  • Learner will be able to describe how use at least one of the sets of views and viewpoints in detail for a project and be able to produce them
CITA – Professional
  • Learner will be able to identify new views and viewpoints for groups of stakeholders
  • Learner will know the risk of missing out some views and viewpoints and be able to justify this where appropriate

Application of Views and Viewpoints

When the appropriate viewpoints have been selected, the architect needs to be able to produce the models defined and apply any techniques identified. This will usually entail using modelling languages like UML, Archimate or BPMN, and the tools which support these.

Iasa Certification Level Learning Objective
CITA- Foundation
  • Learner will be able to name the various activities which are covered by the commonly used Viewpoints
CITA – Associate
  • Learner will be able to describe the activities and how they relate to each other across different Viewpoints
  • Learner will be able to use the commonly found models to produce Views on medium complexity projects
  • Learner will be able to use at least one of the modelling tools, like Enterprise Architect, Magic Draw, Rational Software Architect or Archi to define the models
CITA – Specialist
  • Learner will be able to use all the appropriate Viewpoints on the development of large and complex project environments
  • Learner will be able to define in detail all of the activities
  • The Learner will be able to relate the Views to the stakeholders objectives
CITA – Professional
  • Learner will be able to suggest significant specializations in the Viewpoints for an organization
  • Learner will be able to propose new combinations of Veiwpoints

View and Viewpoint Management

Within the organization there should be processes to manage viewpoints for re-use and leverage views that have been produced by capturing construction and usage of views, the information needed, modeling techniques that can be used and a rationale for these choices.  This will typically be in some sort of repository.

Iasa Certification Level Learning Objective
CITA- Foundation
  • Learner will be able to describe the management process at their organization
  • Learner will be able to explain the reasons for managing Views and Viewpoints
CITA – Associate
  • Learner will be able to construct simple Views for inclusion in the process
  • Learner will be able to describe how and why they applied the Viewpoints for a project
CITA – Specialist
  • Learner will be able to critique content for inclusion in the repository
  • Learner will be able to define the principles to apply governing inclusion
CITA – Professional
  • Learner will be able to create meta-models for use by others
  • Learner will be able to invent and reinforce the management process

Capabilities Resources

Related Capabilities:


Rozanski & Woods: Software Systems Architecture (2nd Edition)

Software Engineering Institute: Software Architecture in Practice (3rd Edition)

Blogs/Webcasts/News/Reference sources:

The Open Group web site:



Rozanski & Woods Web site:


Chris Cooper-Bland
Group Head of Architecture – Endava