ArchiMate® 3.1 Specification
Copyright © 2012-2019 The Open Group

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

Category: Composition

Name

Perspective

Scope

Organization

Structure of the enterprise in terms of roles, departments, etc.

Single layer, single aspect

Application Structure

Shows the structure of a typical application in terms of its constituents.

Single layer, multiple aspect

Information Structure

Shows the structure of the information used in the enterprise.

Multiple layer, single aspect

Technology

Infrastructure and platforms underlying the enterprise’s information systems in terms of networks, devices, and system software.

Single layer, multiple aspect

Layered

Provides overview of architecture(s).

Multiple layer, multiple aspect

Physical

Physical environment and how this relates to IT infrastructure.

Multiple layer, multiple aspect

Category: Support

Name

Perspective

Scope

Product

Shows the contents of products.

Multiple layer, multiple aspect

Application Usage

Relates applications to their use in, for example, business processes.

Multiple layer, multiple aspect

Technology Usage

Shows how technology is used by applications.

Multiple layer, multiple aspect

Category: Cooperation

Name

Perspective

Scope

Business Process Cooperation

Shows the relationships between various business processes.

Multiple layer, multiple aspect

Application Cooperation

Shows application components and their mutual relationships.

Application layer, multiple aspect

Category: Realization

Name

Perspective

Scope

Service Realization

Shows how services are realized by the requisite behavior.

Multiple layer, multiple aspect

Implementation and Deployment

Shows how applications are mapped onto the underlying technology.

Multiple layer, multiple aspect

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

Organization Viewpoint

Stakeholders

Enterprise, process and domain architects, managers, employees, shareholders

Concerns

Identification of competencies, authority, and responsibilities

Purpose

Designing, deciding, informing

Scope

Single layer/Single aspect

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

Application Structure Viewpoint

Stakeholders

Application and solution architects

Concerns

Application structure, consistency and completeness, reduction of complexity

Purpose

Designing

Scope

Single layer/Multiple aspect

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

Information Structure Viewpoint

Stakeholders

Domain and information architects

Concerns

Structure and dependencies of the used data and information, consistency and completeness

Purpose

Designing

Scope

Multiple layer/Single aspect

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

Technology Viewpoint

Stakeholders

Infrastructure architects, operational managers

Concerns

Stability, security, dependencies, costs of the infrastructure

Purpose

Designing

Scope

Single layer/Multiple aspect

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

Layered Viewpoint

Stakeholders

Enterprise, process, application, infrastructure, and domain architects

Concerns

Consistency, reduction of complexity, impact of change, flexibility

Purpose

Designing, deciding, informing

Scope

Multiple layer/Multiple aspect

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

Physical Viewpoint

Stakeholders

Infrastructure architects, operational managers

Concerns

Relationships and dependencies of the physical environment and how this relates to IT infrastructure

Purpose

Designing

Scope

Multiple layer/Multiple aspect

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

Product Viewpoint

Stakeholders

Product developers, product managers, process and domain architects

Concerns

Product development, value offered by the products of the enterprise

Purpose

Designing, deciding

Scope

Multiple layer/Multiple aspect

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

Application Usage Viewpoint

Stakeholders

Enterprise, process, and application architects, operational managers

Concerns

Consistency and completeness, reduction of complexity

Purpose

Designing, deciding

Scope

Multiple layer/Multiple aspect

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

Technology Usage Viewpoint

Stakeholders

Application, infrastructure architects, operational managers

Concerns

Dependencies, performance, scalability

Purpose

Designing

Scope

Multiple layer/Multiple aspect

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

Business Process Cooperation Viewpoint

Stakeholders

Process and domain architects, operational managers

Concerns

Dependencies between business processes, consistency and completeness, responsibilities

Purpose

Designing, deciding

Scope

Multiple layer/Multiple aspect

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

Application Cooperation Viewpoint

Stakeholders

Enterprise, process, application, and domain architects

Concerns

Relationships and dependencies between applications, orchestration/choreography of services, consistency and completeness, reduction of complexity

Purpose

Designing

Scope

Application layer/Multiple aspect

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

Service Realization Viewpoint

 

Process and domain architects, product and operational managers

Concerns

Added-value of business processes, consistency and completeness, responsibilities

Purpose

Designing, deciding

Scope

Multiple layer/Multiple aspect

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

Implementation and Deployment Platform Viewpoint

Stakeholders

Application and domain architects

Concerns

Structure of application platforms and how they relate to supporting technology

Purpose

Designing, deciding

Scope

Multiple layer/Multiple aspect

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

Stakeholder Viewpoint

Stakeholders

Stakeholders, business managers, enterprise and ICT architects, business analysts, requirements managers

Concerns

Architecture mission and strategy, motivation

Purpose

Designing, deciding, informing

Scope

Motivation

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

Goal Realization Viewpoint

Stakeholders

Stakeholders, business managers, enterprise and ICT architects, business analysts, requirements managers

Concerns

Architecture mission, strategy and tactics, motivation

Purpose

Designing, deciding

Scope

Motivation

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

Requirements Realization Viewpoint

Stakeholders

Enterprise and ICT architects, business analysts, requirements managers

Concerns

Architecture strategy and tactics, motivation

Purpose

Designing, deciding, informing

Scope

Motivation

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

Motivation Viewpoint

Stakeholders

Enterprise and ICT architects, business analysts, requirements managers

Concerns

Architecture strategy and tactics, motivation

Purpose

Designing, deciding, informing

Scope

Motivation

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

Strategy Viewpoint

Stakeholders

CxOs, business managers, enterprise and business architects

Concerns

Strategy development

Purpose

Designing, deciding

Scope

Strategy

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

Capability Map Viewpoint

Stakeholders

Business managers, enterprise and business architects

Concerns

Architecture strategy and tactics, motivation

Purpose

Designing, deciding

Scope

Strategy

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

Value Stream Viewpoint

Stakeholders

Business managers, enterprise and business architects

Concerns

Architecture strategy and tactics, motivation

Purpose

Designing, deciding

Scope

Strategy

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

Outcome Realization Viewpoint

Stakeholders

Business managers, enterprise and business architects

Concerns

Business-oriented results

Purpose

Designing, deciding

Scope

Strategy

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

Resource Map Viewpoint

Stakeholders

Business managers, enterprise and business architects

Concerns

Architecture strategy and tactics, motivation

Purpose

Designing, deciding

Scope

Strategy

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

Project Viewpoint

Stakeholders

(Operational) managers, enterprise and ICT architects, employees, shareholders

Concerns

Architecture vision and policies, motivation

Purpose

Deciding, informing

Scope

Implementation and Migration

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

Migration Viewpoint

Stakeholders

Enterprise architects, process architects, application architects, infrastructure architects and domain architects, employees, shareholders

Concerns

History of models

Purpose

Designing, deciding, informing

Scope

Implementation and Migration

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

Implementation and Migration Viewpoint

Stakeholders

(Operational) managers, enterprise and ICT architects, employees, shareholders

Concerns

Architecture vision and policies, motivation

Purpose

Deciding, informing

Scope

Multiple layer/Multiple aspect

Elements

               Goal

               Requirement

               Constraint

               Work package

               Implementation event

               Deliverable

               Plateau

               Gap

               Business actor

               Business role

               Location

               Core element

 



return to top of page

Downloads

Downloads of the ArchiMate documentation are available under license from the Download link within the ArchiMate information web site. The license is free to any organization wishing to use ArchiMate documentation entirely for internal purposes. A book is also available from The Open Group Library as document C197.


Copyright © 2012-2019 The Open Group, All Rights Reserved
ArchiMate is a registered trademark of The Open Group.