Appendix 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.

A basic type of viewpoint, is a simple selection of a relevant subset of ArchiMate concepts. The expressed representation of that part of an architecture in this section is geared towards the stakeholders that will utilize 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, 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 22. 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 22. 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 aspects

Information Structure

Shows the structure of the information used in the enterprise.

Multiple layers, single aspects

Technology

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

Single layer, multiple aspects

Layered

Provides overview of architecture(s).

Multiple layers, multiple aspects

Physical

Physical environment and how this relates to IT infrastructure.

Multiple layers, multiple aspects

Category: Support

Name

Perspective

Scope

Product

Shows the contents of products.

Multiple layers, multiple aspects

Application Usage

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

Multiple layers, multiple aspects

Technology Usage

Shows how technology is used by applications.

Multiple layers, multiple aspects

Category: Cooperation

Name

Perspective

Scope

Business Process Cooperation

Shows the relationships between various business processes.

Multiple layers, multiple aspects

Application Cooperation

Shows application components and their mutual relationships.

Application layer, multiple aspects

Category: Realization

Name

Perspective

Scope

Service Realization

Shows how services are realized by the requisite behavior.

Multiple layers, multiple aspects

Implementation and Deployment

Shows how applications are mapped onto the underlying technology.

Multiple layers, multiple aspects

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 stakeholder 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 23. 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 24. 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 aspects

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 25. 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 layers/Single aspects

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 26. Technology Viewpoint Description
Technology Viewpoint

Stakeholders

Infrastructure Architects, Operational Managers

Concerns

Stability, security, dependencies, costs of the infrastructure

Purpose

Designing

Scope

Single layer/Multiple aspects

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 27. 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 27. 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 layers/Multiple aspects

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 28. 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 layers/Multiple aspects

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. It 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 29. 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 layers/Multiple aspects

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 30. 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 layers/Multiple aspects

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 31. Technology Usage Viewpoint Description
Technology Usage Viewpoint

Stakeholders

Application, Infrastructure Architects, Operational Managers

Concerns

Dependencies, performance, scalability

Purpose

Designing

Scope

Multiple layers/Multiple aspects

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 32. 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 layers/Multiple aspects

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 33. 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 aspects

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 34. Service Realization Viewpoint Description
Service Realization Viewpoint

Stakeholders

Process and Domain Architects, Product and Operational Managers

Concerns

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

Purpose

Designing, deciding

Scope

Multiple layers/Multiple aspects

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 35. 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 layers/Multiple aspects

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 36. 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. The refinement of tangible goals into requirements or constraints, describe the properties that are then 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 37. 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.

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

Table 38. 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 39. 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 that 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 40. 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 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 41. 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 42. 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 43. 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 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 44. 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 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 45. 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 Chapter 12, here the migration viewpoint is only briefly described and positioned by means of Table 46.

Table 46. Migration Viewpoint Description
Migration Viewpoint

Stakeholders

Enterprise Architects, Process Architects, Application Architects, Infrastructure Architects, 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 47. 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 layers/Multiple aspects

Elements

  • Goal

  • Requirement

  • Constraint

  • Work package

  • Implementation event

  • Deliverable

  • Plateau

  • Gap

  • Business actor

  • Business role

  • Location

  • Core element

← Previous: Appendix B: Relationships (Normative) | ↑ Up: ArchiMate 3.2 Specification | ⌂ Home: ArchiMate® 3.2 Specification | Next: Appendix D: Relationship to Other Standards, Specifications, and Guidance Documents →