Scope: Multiple layer/Multiple aspect
Shows structure of a typical application platform and how it relates to supporting technology.
Stakeholder: Enterprise Architects
Application Usage Viewpoint : Archimate
Purpose: Designing, deciding
Concerns: Consistency and completeness, reduction of complexity
Scope: Multiple layer/Multiple aspect
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.
Abstraction Level
Coherence
Layer
Business and application layers
Aspects
Behavior, active structure, passive structure
Application Functionality Context
Purpose: The purpose of the Application Functionality Context template is to document the in which Activities and/or Business Processes a given Application Functionality is used.
Core concerns: The Application Functionality Context template can be used to create graphical views showing where Application Functionalities are used. The template enables you to model Application Functionalities, Activities and Business Processes. The Business Processes and Activities are connected to Application Functionalities using Functionality Usage.
Below, you can see an example of an Application functionality contest diagram, where the context for the DocCom – Create and Store Document functionality is shown:
The diagram shows which Business Processes use the Application Functionality as well as which Information System delivers it.
Relation to other templates: To map applications hardware, the Application Architecture Diagram or Infrastructure Diagram template should be used. The Application Functionality Context template graphically connects functionalities of Information Systems to the Processes and Activities in which they are used. It offers an additional view to Application Architecture Diagrams, Workflow Diagrams, Business Process Diagrams and Business Process Networks.
Properties and metadata: The Application Functionality Context template can for example retain the following information:
- A description of the diagram
- Audits (auto generated information regarding its current state and access rights)
- Associated documents, diagrams and other objects
- Inherent Risk detailing risk considerations
- Governance information detailing information about the published diagram and who has been involved in the approval of the diagram
The above picture shows the properties dialogue window for the Application Functionality Context template where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.
Resource Map Viewpoint : Archimate
Concerns: Architecture strategy and tactics, motivation
Purpose: Designing, deciding
Scope: Strategy
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.
Project Viewpoint : Archimate
Concerns: Architecture vision and policies, motivation
Purpose: Deciding, informing
Scope: Implementation and Migration
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 taken into account 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.
Migration Viewpoint : Archimate
Concerns: History of models
Purpose: Designing, deciding, informing
Scope: Implementation and Migration
The migration viewpoint entails models and concepts that can be used for specifying the transition from an existing architecture to a desired architecture.
Implement Migration Viewpoint : Archimate
Concerns: Architecture vision and policies, motivation
Purpose: Deciding, informing
Scope: Multiple layer/Multiple aspect
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. 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.
Organization Viewpoint : Archimate
Concerns: Identification of competencies, authority, and responsibilities
Purpose: Designing, deciding, informing
Scope: Single layer/Single aspect
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.
Application Cooperation Viewpoint : Archimate
Concerns: Relationships and dependencies between applications, orchestration/choreography of services, consistency and completeness, reduction of complexity
Purpose: Designing
Scope: Multiple layer/Multiple aspect
The application cooperation viewpoint describes the relationships between applications 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.
Abstraction Level
Coherence, details
Layer
Application layer
Aspects
Behavior, active structure, passive structure
Layered Viewpoint : Archimate
Concerns: Consistency, reduction of complexity, impact of change, flexibility
Purpose: Designing, deciding, informing
Scope: Multiple layer/Multiple aspect
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 below. 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.
All core elements and all relationships are permitted in this viewpoint.