Working Page for the Views & Viewpoints Working Group – All Materials are DRAFT. 


The most comprehensive set of viewpoints is provided in Rozanski and Woods Software Systems Architecture. The architect needs to represent complex systems in a way that is manageable and understandable by a range of business and technical stakeholders. In this approach, the architecture description is partitioned into a number of separate but interrelated views, each of which describes a separate aspect of the architecture. Collectively, the views describe the whole system. In any significant system there are a number of cross cutting concerns which are better described in a joined up way, this approach use the concept of perspectives to help with this. This is very well described in the book[1] describing how to approach developing and documenting the architecture of software applications.

The Viewpoints

This viewpoint set is an evolution of 4+1, and answers the following question:

  • What are the main functional elements of your architecture?
  • How will these elements interact with one another and with the outside world?
  • What information will be managed, stored, and presented?
  • What physical hardware and software elements will be required to support these functional and information elements?
  • What operational features and capabilities will be provided?
  • What development, test, support, and training environments will be provided?

The following viewpoints are included:


Viewpoint Definition
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 run time 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 architecture descriptions 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.


This viewpoint set is widely used in organisations involved in developing software intensive business systems, but this approach is applicable to most types of software project, provided that the architect is prepared to think carefully about the types of model required in each view.

General Advice

The use of views and viewpoints is primarily used in the software systems architecture space, and not enterprise architecture, even here they won’t solve all of your software architecture problems automatically, the following describes some of the potential pitfalls when using the viewpoint based approach:

  • Usefulness: Make sure that you only go into enough detail to be useful to the stakeholders, this means that there may be different levels of granularity across the views.
  • Inconsistency: Using a number of views to describe a system inevitably brings consistency problems. It is theoretically possible to use architecture description languages to create the models in your views and then cross-check these automatically, but this has not been effectively achieved in the mainstream, this means that achieving cross-view consistency within an AD is an inherently manual process.
  • Selection of the wrong set of views: It is not always obvious which set of views is suitable for describing a particular system. This is influenced by a number of factors, such as the nature and complexity of the architecture, the skills and experience of the stakeholders (and of the architect), and the time available to produce the AD. There really isn’t an easy answer to this problem, other than your own experience and skill and an analysis of the most important concerns that affect your architecture.
  • Fragmentation: When you start to describe your architecture, one temptation is to create a large number of views. This can lead to your architecture being described by many independent models, each in a separate view, making the AD difficult to follow. Each separate view also involves a significant amount of effort to create and maintain. To avoid fragmentation and minimize the overhead of maintaining unnecessary descriptions, you should eliminate views that do not address significant concerns for the system you are building. In some cases, you may also consider creating hybrid views that combine models from a number of views in the viewpoint set (e.g., creating a combined deployment and concurrency view). Beware, however, of the combined views becoming difficult to understand and maintain because they address a combination of concerns.


[1].  Rozanski, Nick and Woods, Eoin, Software Systems Architecture : Working With Stakeholders Using Viewpoints and Perspectives (2nd Edition). Addison-Wesley Professional, ISBN 978-0321718334


Chris Cooper-Bland