C                     Example Viewpoints

C.1                Basic Viewpoints in the ArchiMate Language

A viewpoint in the ArchiMate language is a selection of a relevant subset of the ArchiMate elements and their relationships. This is the representation of that part of an architecture that is expressed in different diagrams.

The most basic type of viewpoint is a simple selection of a relevant subset of the ArchiMate concepts and the representation of that part of an architecture that is expressed in this selection, geared towards the stakeholders that will use the resulting views.

The following are examples of stakeholders and concerns as a basis for the specification of viewpoints:

•               End user

For example, what are the consequences for their work and workplace?

•               Architect

What is the consequence for the maintainability of a system, with respect to corrective, preventive, and adaptive maintenance?

•               Upper-level management

How can we ensure our policies are followed in the development and operation of processes and systems? What is the impact of decisions (on personnel, finance, ICT, etc.)?

•               Operational manager

Responsible for exploitation or maintenance; for example, what new technologies are there to prepare for? Is there a need to adapt maintenance processes? What is the impact of changes to existing applications? How secure are my systems?

•               Project manager

Responsible for the development of new applications. What are the relevant domains and their relationships? What is the dependence of business processes on the applications to be built? What is their expected performance?

•               Developer

What are the modifications with respect to the current situation that need to be done?

In each basic viewpoint, concepts from the three layers of Business, Application, and Technology may be used. However, not every combination of these would give meaningful results. In some cases, for example, separate viewpoints for the different layers are advisable. Based on common architectural practice and on experiences with the use of ArchiMate models in practical cases, useful combinations in the form of a set of basic viewpoints have been defined. These are listed in Table 21. The table also shows the perspective for the viewpoint. Some viewpoints have a scope that is limited to a single layer or aspect, when others link multiple layers and/or aspects. The different viewpoints are grouped into categories that indicate which direction and which elements the viewpoint is looking at:

1.             Composition: viewpoints that define internal compositions and aggregations of elements.

2.             Support: viewpoints where you are looking at elements that are supported by other elements, typically from one layer and upwards to an above layer.

3.             Cooperation: towards peer elements which cooperate with each other, typically across aspects.

4.             Realization: viewpoints where you are looking at elements that realize other elements, typically from one layer and downwards to a below layer.

Table 21: Basic Viewpoints

In the following sections, the ArchiMate viewpoints are described in more detail. For each viewpoint the comprised elements are listed, guidelines for the viewpoint’s use, and the stakeholders and concerns addressed by the viewpoint are indicated. In addition to the specified elements, the grouping element, junction, and or junction can be used in every viewpoint. For more details on the goal and use of viewpoints, refer to Chapter 14 of [1].

These basic viewpoints are starting points for modeling efforts. They can accelerate architectural efforts, support organizational standards, facilitate peer review, and aid new modelers. However, these basic viewpoints should not constrain modeling activities. Organizations and individual modelers should address stakeholder concerns by selecting from the basic viewpoints, modifying them, or defining new ones. The viewpoints listed here are therefore intended as examples, not as a normative or exhaustive list.

As outlined before, a viewpoint’s representation should be geared towards the intended stakeholder(s). This means that these basic viewpoints are mainly useful for architects and their peers. Other stakeholders may require a different representation, even if they are interested in the same content.

C.1.1             Organization Viewpoint

The organization viewpoint focuses on the (internal) organization of a company, department, network of companies, or of another organizational entity. It is possible to present models in this viewpoint as nested block diagrams, but also in a more traditional way, such as organizational charts. The organization viewpoint is very useful in identifying competencies, authority, and responsibilities in an organization.

Table 22: Organization Viewpoint Description

Elements

•               Business actor

•               Business role

•               Business collaboration

•               Location

•               Business interface

C.1.2             Application Structure Viewpoint

The application structure viewpoint shows the structure of one or more applications or components. This viewpoint is useful in designing or understanding the main structure of applications or components and the associated data; e.g., to break down the structure of the system under construction, or to identify legacy application components that are suitable for migration/integration.

Table 23: Application Structure Viewpoint Description

Elements

•               Application component

•               Application interface

•               Application collaboration

•               Data object

C.1.3             Information Structure Viewpoint

The information structure viewpoint is comparable to the traditional information models created in the development of almost any information system. It shows the structure of the information used in the enterprise or in a specific business process or application, in terms of data types or (object-oriented) class structures. Furthermore, it may show how the information at the business level is represented at the application level in the form of the data structures used there, and how these are then mapped onto the underlying technology infrastructure; e.g., by means of a database schema.

Table 24: Information Structure Viewpoint Description

Elements

•               Business object

•               Representation

•               Data object

•               Artifact

•               Meaning

C.1.4             Technology Viewpoint

The technology viewpoint contains the software and hardware technology elements supporting the Application Layer, such as physical devices, networks, or system software (e.g., operating systems, databases, and middleware).

Table 25: Technology Viewpoint Description

Elements

•               Location

•               Node

•               Technology collaboration

•               Device

•               System software

•               Technology interface

•               Communication network

•               Path

•               Technology process/function/interaction

•               Technology service

•               Technology event

•               Artifact

C.1.5             Layered Viewpoint

The layered viewpoint pictures several layers and aspects of an Enterprise Architecture in one diagram. There are two categories of layers, namely dedicated layers and service layers. The layers are the result of the use of the “grouping” relationship for a natural partitioning of the entire set of objects and relationships that belong to a model. The technology, application, process, and actor/role layers belong to the first category. The structural principle behind a fully layered viewpoint is that each dedicated layer exposes, by means of the “realization” relationship, a layer of services, which are further on “serving” the next dedicated layer. Thus, we can easily separate the internal structure and organization of a dedicated layer from its externally observable behavior expressed as the service layer that the dedicated layer realizes. The order, number, or nature of these layers are not fixed, but in general a (more or less) complete and natural layering of an ArchiMate model should contain the succession of layers depicted in the example given in Table 26. However, this example is by no means intended to be prescriptive. The main goal of the layered viewpoint is to provide an overview in one diagram. Furthermore, this viewpoint can be used as support for impact of change analysis and performance analysis or for extending the service portfolio.

Table 26: Layered Viewpoint Description

Elements

All core elements and all relationships are permitted in this viewpoint.

C.1.6             Physical Viewpoint

The physical viewpoint contains equipment (one or more physical machines, tools, or instruments) that can create, use, store, move, or transform materials, how the equipment is connected via the distribution network, and what other active elements are assigned to the equipment.

Table 27: Physical Viewpoint Description

Elements

•               Location

•               Node

•               Device

•               Equipment

•               Facility

•               Path

•               Communication network

•               Distribution network

•               Material

C.1.7             Product Viewpoint

The product viewpoint depicts the value that these products offer to the customers or other external parties involved and shows the composition of one or more products in terms of the constituting (business, application, or technology) services, and the associated contract(s) or other agreements. It may also be used to show the interfaces (channels) through which this product is offered, and the events associated with the product. A product viewpoint is typically used in product development to design a product by composing existing services or by identifying which new services have to be created for this product, given the value a customer expects from it. It may then serve as input for business process architects and others that need to design the processes and ICT realizing these products.

Table 28: Product Viewpoint Description

Elements

•               Business actor

•               Business role

•               Business collaboration

•               Business interface

•               Business process/function/interaction

•               Business event

•               Business service

•               Business object

•               Product

•               Contract

•               Application component/collaboration

•               Application interface

•               Application process/function/interaction

•               Application event

•               Application service

•               Data object

•               Technology service

•               Artifact

•               Material

•               Value

C.1.8             Application Usage Viewpoint

The application usage viewpoint describes how applications are used to support one or more business processes, and how they are used by other applications. It can be used in designing an application by identifying the services needed by business processes and other applications, or in designing business processes by describing the services that are available. Furthermore, since it identifies the dependencies of business processes upon applications, it may be useful to operational managers responsible for these processes.

Table 29: Application Usage Viewpoint Description

Elements

•               Business actor

•               Business role

•               Business collaboration

•               Business process/function/interaction

•               Business event

•               Business object

•               Application component/collaboration

•               Application interface

•               Application process/function/interaction

•               Application event

•               Application service

•               Data object

C.1.9             Technology Usage Viewpoint

The technology usage viewpoint shows how applications are supported by the software and hardware technology: the technology services are delivered by the devices; system software and networks are provided to the applications. This viewpoint plays an important role in the analysis of performance and scalability, since it relates the physical infrastructure to the logical world of applications. It is very useful in determining the performance and quality requirements on the infrastructure based on the demands of the various applications that use it.

Table 30: Technology Usage Viewpoint Description

Elements

•               Application component/collaboration

•               Application process/function/interaction

•               Application event

•               Data object

•               Node

•               Device

•               Technology collaboration

•               System software

•               Technology interface

•               Communication network

•               Path

•               Technology process/function/interaction

•               Technology service

•               Technology event

•               Artifact

C.1.10          Business Process Cooperation Viewpoint

The business process cooperation viewpoint is used to show the relationships of one or more business processes with each other and/or with their environment. It can be used both to create a high-level design of business processes within their context and to provide an operational manager responsible for one or more such processes with insight into their dependencies. Important aspects of business process cooperation are:

•               Causal relationships between the main business processes of the enterprise

•               Mapping of business processes onto business functions

•               Realization of services by business processes

•               Use of shared data

Each of these can be regarded as a “sub-viewpoint” of the business process cooperation viewpoint.

Table 31: Business Process Cooperation Viewpoint Description

Elements

•               Business actor

•               Business role

•               Business collaboration

•               Location

•               Business interface

•               Business process/function/interaction

•               Business event

•               Business service

•               Business object

•               Representation

•               Application component/collaboration

•               Application interface

•               Application process/function/interaction

•               Application event

•               Application service

•               Data object

C.1.11          Application Cooperation Viewpoint

The application cooperation viewpoint describes the relationships between application components in terms of the information flows between them, or in terms of the services they offer and use. This viewpoint is typically used to create an overview of the application landscape of an organization. This viewpoint is also used to express the (internal) cooperation or orchestration of services that together support the execution of a business process.

Table 32: Application Cooperation Viewpoint Description

Elements

•               Location

•               Application component/collaboration

•               Application interface

•               Application process/function/interaction

•               Application event

•               Application service

•               Data object

C.1.12          Service Realization Viewpoint

The service realization viewpoint is used to show how one or more business services are realized by the underlying processes (and sometimes by application components). Thus, it forms the bridge between the business products viewpoint and the business process view. It provides a “view from the outside” on one or more business processes.

Table 33: Service Realization Viewpoint Description

Elements

•               Business actor

•               Business role

•               Business collaboration

•               Business interface

•               Business process/function/interaction

•               Business event

•               Business service

•               Business object

•               Representation

•               Application component/collaboration

•               Application interface

•               Application process/function/interaction

•               Application event

•               Application service

•               Data object

C.1.13          Implementation and Deployment Viewpoint

The implementation and deployment viewpoint shows how one or more applications are realized on the infrastructure. This comprises the mapping of applications and components onto artifacts, and the mapping of the information used by these applications and components onto the underlying storage infrastructure.

Table 34: Implementation and Deployment Viewpoint Description

Elements

•               Application component/collaboration

•               Application interface

•               Application process/function/interaction

•               Application event

•               Application service

•               Data object

•               System software

•               Technology interface

•               Path

•               Technology process/function/interaction

•               Technology service

•               Artifact

C.2                Motivation Viewpoints

A number of standard viewpoints for modeling motivational aspects have been defined. Each of these viewpoints presents a different perspective on modeling the motivation that underlies some Enterprise Architecture and allows a modeler to focus on certain aspects. Therefore, each viewpoint considers only a selection of the elements and relationships that have been described in the preceding sections.

The following viewpoints are distinguished:

•               The stakeholder viewpoint focuses on modeling the stakeholders, drivers, the assessments of these drivers, and the initial goals to address these drivers and assessments

•               The goal realization viewpoint focuses on refining the initial, high-level goals into more concrete (sub-)goals using the aggregation relationship, and finally into requirements and constraints using the realization relationship

•               The goal contribution viewpoint focuses on modeling and analyzing the influence relationships between goals (and requirements)

•               The principles viewpoint focuses on modeling the relevant principles and the goals that motivate these principles

•               The requirements realization viewpoint focuses on modeling the realization of requirements and constraints by means of core elements, such as actors, services, processes, application components, etc.

•               The motivation viewpoint covers the entire motivational aspect and allows use of all motivational elements

All viewpoints are separately described below. For each viewpoint, its elements and relationships, the guidelines for its use, and its goal and target group are indicated. Furthermore, each viewpoint description contains example models. For more details on the goal and use of viewpoints, refer to Chapter 14 of [1].

C.2.1             Stakeholder Viewpoint

The stakeholder viewpoint allows the analyst to model the stakeholders, the internal and external drivers for change, and the assessments (in terms of strengths, weaknesses, opportunities, and threats) of these drivers. Also, the links to the initial (high-level) goals that address these concerns and assessments may be described. These goals form the basis for the requirements engineering process, including goal refinement, contribution and conflict analysis, and the derivation of requirements that realize the goals.

Table 35: Stakeholder Viewpoint Description

Elements

•               Stakeholder

•               Driver

•               Assessment

•               Goal

•               Outcome

C.2.2             Goal Realization Viewpoint

The goal realization viewpoint allows a designer to model the refinement of (high-level) goals into more tangible goals, and the refinement of tangible goals into requirements or constraints that describe the properties that are needed to realize the goals. The refinement of goals into sub-goals is modeled using the aggregation relationship. The refinement of goals into requirements is modeled using the realization relationship.

In addition, the principles may be modeled that guide the refinement of goals into requirements.

Table 36: Goal Realization Viewpoint Description

Elements

•               Goal

•               Principle

•               Requirement

•               Constraint

•               Outcome

C.2.3             Requirements Realization Viewpoint

The requirements realization viewpoint allows the designer to model the realization of requirements by the core elements, such as business actors, business services, business processes, application services, application components, etc. Typically, the requirements result from the goal refinement viewpoint.

In addition, this viewpoint can be used to refine requirements into more detailed requirements. The aggregation relationship is used for this purpose.

Table 37: Requirements Realization Viewpoint Description

Elements

•               Goal

•               Principle

•               Requirement/constraint

•               Outcome

•               Value

•               Meaning

•               Core element

•               Course of action

•               Resource

•               Capability

•               Value stream

C.2.4             Motivation Viewpoint

The motivation viewpoint allows the designer or analyst to model the motivation aspect, without focusing on certain elements within this aspect. For example, this viewpoint can be used to present a complete or partial overview of the motivation aspect by relating stakeholders, their primary goals, the principles that are applied, and the main requirements on services, processes, applications, and objects.

Table 38: Motivation Viewpoint Description

Elements

•               Stakeholder

•               Driver

•               Assessment

•               Goal

•               Principle

•               Requirement

•               Constraint

•               Outcome

•               Value

•               Meaning

C.3                Strategy Viewpoints

To describe strategic aspects of the enterprise, the viewpoints below have been defined. Each of these viewpoints presents a different perspective on modeling the high-level strategic direction and make-up of the enterprise and allows a modeler to focus on certain aspects. Therefore, each viewpoint considers only a selection of the elements and relationships that have been described in the preceding sections.

The following viewpoints are distinguished:

•               The strategy viewpoint provides a high-level strategic overview of the strategies of the enterprise, its capabilities, value streams, and resources, and the envisaged outcomes

•               The capability map viewpoint provides an overview of the capabilities of the enterprise

•               The value stream viewpoint shows an overview of value-creating steps in the enterprise and the capabilities that support these

•               The outcome realization viewpoint describes how high-level, business-oriented results are produced by the capabilities and resources of the enterprise

•               The resource map viewpoint provides a structured overview of the resources of the enterprise

All viewpoints are separately described below. For each viewpoint, its elements and relationships, the guidelines for its use, and its goal and target group are indicated. For more details on the goal and use of viewpoints, refer to Chapter 14 of [1].

C.3.1             Strategy Viewpoint

The strategy viewpoint allows the Business Architect to model a high-level, strategic overview of the strategies (courses of action) of the enterprise, the capabilities, value streams, and resources supporting those, and the envisaged outcomes.

Table 39: Strategy Viewpoint Description

Elements

•               Course of action

•               Capability

•               Value stream

•               Resource

•               Outcome

C.3.2             Capability Map Viewpoint

The capability map viewpoint allows the Business Architect to create a structured overview of the capabilities of the enterprise. A capability map typically shows two or three levels of capabilities across the entire enterprise. It can, for example, be used as a heat map to identify areas of investment. In some cases, a capability map may also show specific outcomes delivered by these capabilities.

Table 40: Capability Map Viewpoint Description

Elements

•               Outcome

•               Capability

•               Resource

C.3.3             Value Stream Viewpoint

The value stream viewpoint allows the Business Architect to create a structured overview of a value stream, the capabilities supporting the stages in that value stream, the value created, and the stakeholders involved.

Table 41: Value Stream Viewpoint Description

Elements

•               Value stream

•               Capability

•               Outcome

•               Stakeholder

C.3.4             Outcome Realization Viewpoint

The outcome realization viewpoint is used to show how the highest-level, business-oriented results are produced by the capabilities and underlying core elements.

Table 42: Outcome Realization Viewpoint Description

Elements

•               Capability

•               Value stream

•               Resource

•               Outcome

•               Value

•               Meaning

•               Core element

C.3.5             Resource Map Viewpoint

The resource map viewpoint allows the Business Architect to create a structured overview of the resources of the enterprise. A resource map typically shows two or three levels of resources across the entire enterprise. It can, for example, be used as a heat map to identify areas of investment. In some cases, a resource map may also show relationships between resources and the capabilities they are assigned to.

Table 43: Resource Map Viewpoint Description

Elements

•               Resource

•               Capability

•               Work package

C.4                Implementation and Migration Viewpoints

The following standard viewpoints for modeling implementation and migration aspects are distinguished:

•               The project viewpoint is primarily used to model the management of architecture change

•               The migration viewpoint is used to model the transition from an existing architecture to a target architecture

•               The implementation and migration viewpoint is used to model the relationships between the programs and projects and the parts of the architecture that they implement

All viewpoints are described separately below. For each viewpoint the comprised elements and relationships, the guidelines for the viewpoint use, and the goal and target group and of the viewpoint are indicated. Furthermore, each viewpoint description contains example models. For more details on the goal and use of viewpoints, refer to Chapter 14 of [1].

C.4.1             Project Viewpoint

A project viewpoint is primarily used to model the management of architecture change. The “architecture” of the migration process from an old situation (current state Enterprise Architecture) to a new desired situation (target state Enterprise Architecture) has significant consequences on the medium and long-term growth strategy and the subsequent decision-making process. Some of the issues that should be addressed by the models designed in this viewpoint are:

•               Developing a fully-fledged organization-wide Enterprise Architecture is a task that may require several years

•               All systems and services must remain operational regardless of the presumed modifications and changes of the Enterprise Architecture during the change process

•               The change process may have to deal with immature technology standards (e.g., messaging, security, data, etc.)

•               The change has serious consequences for the personnel, culture, way of working, and organization

Furthermore, there are several other governance aspects that might constrain the transformation process, such as internal and external cooperation, project portfolio management, project management (deliverables, goals, etc.), plateau planning, financial and legal aspects, etc.

Table 44: Project Viewpoint Description

Elements

•               Goal

•               Outcome

•               Work package

•               Implementation event

•               Deliverable

•               Business actor

•               Business role

C.4.2             Migration Viewpoint

The migration viewpoint entails models and concepts that can be used for specifying the transition from an existing architecture to a desired architecture. Since the plateau and gap elements have been quite extensively presented in Section 13.2, here the migration viewpoint is only briefly described and positioned by means of Table 45.

Table 45: Migration Viewpoint Description

Elements

•               Plateau

•               Gap

C.4.3             Implementation and Migration Viewpoint

The implementation and migration viewpoint is used to relate programs and projects to the parts of the architecture that they implement. This view allows modeling of the scope of programs, projects, and project activities in terms of the plateaus that are realized or the individual architecture elements that are affected. In addition, the way the elements are affected may be indicated by annotating the relationships.

Furthermore, this viewpoint can be used in combination with the programs and projects viewpoint to support portfolio management:

•               The programs and projects viewpoint is suited to relate business goals to programs and projects

For example, this makes it possible to analyze at a high level whether all business goals are covered sufficiently by the current portfolio(s).

•               The implementation and migration viewpoint is suited to relate business goals (and requirements) via programs and projects to (parts of) the architecture

For example, this makes it possible to analyze potential overlap between project activities or to analyze the consistency between project dependencies and dependencies among plateaus or architecture elements.

Table 46: Implementation and Migration Viewpoint Description

Elements

•               Goal

•               Requirement

•               Constraint

•               Work package

•               Implementation event

•               Deliverable

•               Plateau

•               Gap

•               Business actor

•               Business role

•               Location

•               Core element