Viewpoints is one of the very important concepts in ArchiMate. Each viewpoint contains a dedicated set of ArchiMate elements that allows architect designers to model a specific aspect of an enterprise architecture. The official ArchiMate 3 specification provides 23 ArchiMate example viewpoints for architecture designers to follow. In this ArchiMate viewpoints guide we will go over all these 23 ArchiMate viewpoints, with clear description and ArchiMate diagram examples for each of them.
All the ArchiMate diagram examples in this guide are drawn with Visual Paradigm 's certified ArchiMate tool
Visual Paradigm Enterprise Edition is a certified ArchiMate 3.1 enterprise architecture tool. It supports all ArcihMate 3 vocabulary, notation, syntax, and semantics.
Download NowIn the ArchiMate language, a viewpoint is a relevant subset of ArchiMate elements and relationships, put together on a diagram in representing a particular part of an architecture.
ArchiMate suggests a set of example viewpoints that can be used as starting points for modeling efforts. Each of these ArchiMate viewpoint comprises elements from different ArchiMate layers, addressing specific stakeholder concerns. Organizations are welcomed to apply any of these viewpoint examples in their architecture model, or to define their own ones.
The example viewpoints suggested by ArchiMate are grouped into four main categories:
It is important to note that the example viewpoints officially published in the ArchiMate specification should not constrain modeling activities. You should modify the example viewpoints or even to define your own viewpoints in addressing specific stakeholder concerns.
ArchiMate basic viewpoints cover ArchiMate elements and concepts of the three main ArchiMate layers: Business, Application, and Technology. Listed below is a table of ArchiMate 3.1 example viewpoints, grouped into four categories that indicate which the direction and scope they cover:
Composition:
| Name | Perspective | Concerns |
|---|---|---|
| Organization | Structure of the enterprise in terms of roles, departments, etc. | Identification of competencies, authority, and responsibilities |
| Information Structure | Shows the structure of the information used in the enterprise. | Structure and dependencies of the used data and information, consistency and completeness |
| Technology | Infrastructure and platforms underlying the enterprise's information systems in terms of networks, devices, and system software. | Stability, security, dependencies, costs of the infrastructure |
| Layered | Provides overview of architecture(s). | Consistency, reduction of complexity, impact of change, flexibility |
| Physical | Physical environment and how this relates to IT infrastructure. | Relationships and dependencies of the physical environment and how this relates to IT infrastructure |
Support:
| Name | Perspective | Concerns |
|---|---|---|
| Product | Shows the contents of products. | Product development, value offered by the products of the enterprise |
| Application Usage | Relates applications to their use in, for example, business processes. | Consistency and completeness, reduction of complexity. |
| Technology Usage | Shows how technology is used by applications. | Dependencies, performance, scalability |
Cooperation:
| Name | Perspective | Concerns |
|---|---|---|
| Business Process Cooperation | Shows the relationships between various business processes. | Dependencies between business processes, consistency and completeness, responsibilities |
| Application Cooperation | Shows application components and their mutual relationships. | Relationships and dependencies between applications, orchestration/choreography of services, consistency and completeness, reduction of complexity |
Realization:
| Name | Perspective | Concerns |
|---|---|---|
| Service Realization | Shows how services are realized by the requisite behavior. | Added-value of business processes, consistency and completeness, responsibilities |
| Implementation and Deployment | Shows how applications are mapped onto the underlying technology. | Structure of application platforms and how they relate to supporting technology |
In the coming sections, we will go over all the ArchiMate basic viewpoints in detail. For each viewpoint, the stakeholder(s) targeted, the concerns to address, the purpose and scope are covered. Besides, ArchiMate diagram examples will be provided.
In addition to the specified elements, the Grouping element, Junction, and Or Junction can be used in every viewpoint.
The organization viewpoint is used to present the organizational structure of an organization unit such as a corporate, company, a department, or even a network of companies. Typically, the structure is presented in nested way. However, it is not uncommon to present like a traditional organizational chart. The organization viewpoint is commonly used in identifying competencies and responsibilities of an organization unit.
The table below describes Organization Viewpoint in more detail.
| 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 |
The figure below shows an ArchiMate diagram drawn under the Organization Viewpoint.
The business process cooperation viewpoint is used to model the flow of main business processes of an enterprise. It can be used to create a high-level design of business processes, providing operational manager with insight into their dependencies. You can also model the mapping of business processes with business functions, and how business services can be realized by business processes.
The table below describes Business Process Cooperation Viewpoint in more detail.
| 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 |
The figure below shows an ArchiMate diagram drawn under the Business Process Cooperation Viewpoint.
The product viewpoint focuses on the value that the product will offer to the customers. It shows the composition product in terms of the constituting (business, application, or technology) services, and the contract(s) or other agreements involved. You can also show the interfaces through which this product is offered, and the events associated with the product. A product viewpoint is typically used to model the services involved in using the product, which can be a composition of existing services or new services required to be created.
The table below describes Product Viewpoint in more detail.
| 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 |
The figure below shows an ArchiMate diagram drawn under the Product Viewpoint.
The application cooperation viewpoint presents the information flows between applications components, and the services the components provide and require. People use this viewpoint to create an overview of the application landscape. Besides, this viewpoint can also be used to model the cooperation of services that together support the execution of a business process.
The table below describes Application Cooperation Viewpoint in more detail.
| 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 | Multiple layer/Multiple aspect |
| Elements | Location, Application component/collaboration, Application interface, Application process/function/interaction, Application event, Application service, Data object |
The figure below shows an ArchiMate diagram drawn under the Application Cooperation Viewpoint.
The application usage viewpoint shows how applications work together to support business processes, and how applications are used by other applications. It can be used to identify the services needed by business processes and other applications, or in designing business processes by describing the services that are available.
The table below describes Application Usage Viewpoint in more detail.
| 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 |
The figure below shows an ArchiMate diagram drawn under the Application Usage Viewpoint.
The implementation and deployment viewpoint shows the realization of applications on the infrastructure. This involves 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.
The table below describes Implementation and Deployment Viewpoint in more detail.
| 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 |
The figure below shows an ArchiMate diagram drawn under the Implementation and Deployment Viewpoint.
The technology viewpoint shows how the application layer is supported by the software and hardware technology elements like physical devices, networks, or system software (e.g., O/S, databases, and middleware).
The table below describes Technology Viewpoint in more detail.
| 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 |
The figure below shows an ArchiMate diagram drawn under the Technology Viewpoint.
The technology usage viewpoint shows how applications are supported by the software and hardware technology. This viewpoint is commonly applied when there is a need of performance or scalability analysis, since it relates the physical infrastructure to the logical world of applications.
The table below describes Technology Usage Viewpoint in more detail.
| 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 |
The figure below shows an ArchiMate diagram drawn under the Technology Usage Viewpoint.
The information structure viewpoint is works like a traditional information models commonly created in developing information system. The viewpoint shows the structure of the information used in the enterprise. It may also 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.
The table below describes Information Structure Viewpoint in more detail.
| 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 |
The figure below shows an ArchiMate diagram drawn under the Information Structure Viewpoint.
The service realization viewpoint models how business services are realized by the underlying processes / application components.
The table below describes Service Realization Viewpoint in more detail.
| Stakeholders | 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 |
The figure below shows an ArchiMate diagram drawn under the Service Realization Viewpoint.
The physical viewpoint shows the equipment that can create, use, store, move, or transform materials, and how the equipment is connected via the distribution network, and what other active elements are assigned to the equipment.
The table below describes Physical Viewpoint in more detail.
| 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 |
The figure below shows an ArchiMate diagram drawn under the Physical Viewpoint.
The layered viewpoint presents a bird-eye view of core elements of all layers and aspects of an Enterprise Architecture. 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. With this viewpoint, you 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 table below describes Layered Viewpoint in more detail.
| 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.> |
The figure below shows an ArchiMate diagram drawn under the Layered Viewpoint.
The ArchiMate motivation viewpoints defined a set of example viewpoints for modeling the motivational aspects of an enterprise architecture.
In the coming sections, we will go over all the ArchiMate motivation viewpoints in detail.
The stakeholder viewpoint is used to model the stakeholders, drivers of changes (both internal and external), and the assessments of these drivers, in terms of SWOT. It may also be used to model the links to the initial goals that address these concerns and assessments. 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.
The table below describes Stakeholder Viewpoint in more detail.
| 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 |
The figure below shows an ArchiMate diagram drawn under the Stakeholder Viewpoint.
The goal realization viewpoint models the refinement of high level goals into more specific goals, and the refinement of these specific goals further into requirements or constraints. The refinement of goals into sub-goals is modeled using the aggregation, while the refinement of goals into requirements is modeled using the realization.
The table below describes Goal Realization Viewpoint in more detail.
| 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 |
The figure below shows an ArchiMate diagram drawn under the Goal Realization Viewpoint.
The requirements realization viewpoint shows the realization of requirements by core elements such as business actors, business services, business processes, application services, application components, etc. Typically, the requirements result from the goal refinement viewpoint.
The table below describes Requirements Realization Viewpoint in more detail.
| Stakeholders | Enterprise and ICT architects, business analysts, requirements managers |
| Concerns | Architecture strategy and tactics, motivation |
| Purpose | Designing, deciding, informing |
| Scope | Motivation |
| Elements | Goal, Requirement/constraint, Outcome, Value, Meaning, Core element |
The figure below shows an ArchiMate diagram drawn under the Requirements Realization Viewpoint.
The motivation 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.
The table below describes Motivation Viewpoint in more detail.
| 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 |
The figure below shows an ArchiMate diagram drawn under the Motivation Viewpoint.
The ArchiMate strategy viewpoints defined a number of example viewpoints for use in modeling the strategic aspects of the enterprise. They can be used in modeling the high-level strategic direction and make-up of the enterprise.
In the coming sections, we will go over all the ArchiMate strategy viewpoints in detail.
The capability map viewpoint presents a structured overview of the capabilities of the enterprise. A capability map typically shows two or three levels of capabilities across the entire enterprise. Very often, capability map viewpoint is to be used as a heat map.
The table below describes Strategy Viewpoint in more detail.
| Stakeholders | CxOs, business managers, enterprise and business architects |
| Concerns | Strategy development |
| Purpose | Designing, deciding |
| Scope | Strategy |
| Elements | Course of action, Capability, Resource, Outcome |
The figure below shows an ArchiMate diagram drawn under the Strategy 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.
The table below describes Capability Map Viewpoint in more detail.
| Stakeholders | Business managers, enterprise and business architects |
| Concerns | Architecture strategy and tactics, motivation |
| Purpose | Designing, deciding |
| Scope | Strategy |
| Elements | Outcome, Capability, Resource |
The figure below shows an ArchiMate diagram drawn under the Capability Map 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.
The table below describes Outcome Realization Viewpoint in more detail.
| Stakeholders | Business managers, enterprise and business architects |
| Concerns | Business-oriented results |
| Purpose | Designing, deciding |
| Scope | Strategy |
| Elements | Capability, Resource, Outcome, Value, Meaning, Core element |
The figure below shows an ArchiMate diagram drawn under the Outcome Realization Viewpoint.
The resource map viewpoint shows a structured overview of the resources of the enterprise. A resource map typically involves two or three levels of resources across the entire enterprise. It can be used as a heat map to identify areas of investment.
The table below describes Resource Map Viewpoint in more detail.
| Stakeholders | Business managers, enterprise and business architects |
| Concerns | Architecture strategy and tactics, motivation |
| Purpose | Designing, deciding |
| Scope | Strategy |
| Elements | Resource, Capability, Work package |
The figure below shows an ArchiMate diagram drawn under the Resource Map Viewpoint.
The ArchiMate implementation and migration viewpoints are defined for modeling the management of architecture change, the transition from baseline to target architecture and relationships between programs and projects.
In the coming sections, we will go over all the ArchiMate implementation and migration viewpoints in detail.
A project viewpoint is primarily used to shows the management of architecture change, which involves the modeling of projects to be managed, governed and delivered during the migration from baseline to target architectural.
The table below describes Project Viewpoint in more detail.
| Stakeholders | (operational) managers, enterprise and ICT architects, employees, shareholders |
| Concerns | Architecture vision and policies, motivation |
| Purpose | Deciding, informing |
| Scope | Implementation and Migration |
| Elements | Goal, Work package, Implementation event, Deliverable, Business actor, Business role |
The figure below shows an ArchiMate diagram drawn under the Project Viewpoint.
The migration viewpoint entails models and concepts that can be used for specifying the transition from an existing architecture to a desired architecture.
The table below describes Migration Viewpoint in more detail.
| 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 |
The figure below shows an ArchiMate diagram drawn under the 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, project activities in terms of the plateaus that are realized or the individual architecture elements that are affected.
The table below describes Implementation and Migration Viewpoint in more detail.
| 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 |
The figure below shows an ArchiMate diagram drawn under the Implementation and Migration Viewpoint.
All the ArchiMate diagram examples in this guide are drawn with Visual Paradigm 's certified ArchiMate tool
Try Visual Paradigm Enterprise Edition, an enterprise architecture software that features a powerful ArchiMate drawing tool, ArchiMate viewpoint management tool and TOGAF Guide-through Process.
Try it Free
