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

ApplicationUsageViewpoint_1

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.

Requirements Realization Viewpoint : Archimate

Concerns: Architecture strategy and tactics, motivation
Purpose: Designing, deciding, informing
Scope: Motivation

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.

Motivation Viewpoint : Archimate

Concerns: Architecture strategy and tactics, motivation
Purpose: Designing, deciding, informing
Scope: Motivation

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.

Strategy Viewpoint : Archimate

Concerns: Strategy development
Purpose: Designing, deciding
Scope: Strategy

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 and resources supporting those, and the envisaged outcomes.

Capability Map Viewpoint : Archimate

Concerns: Architecture strategy and tactics, motivation
Purpose: Designing, deciding
Scope: Strategy

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.

Outcome Realization Viewpoint : Archimate

Concerns: Business-oriented results
Purpose: Designing, deciding
Scope: Strategy

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

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.