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.

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.

 

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.

Application Architecture Diagram

Purpose: The purpose of an Application Architecture Diagram is to show the structure of an Information System and its relations to other Information Systems.

Core concerns: The Application Architecture Diagram is used to document the application/systems layer. It can show information flows and system dependencies between Information Systems as well as depict system components and system areas.

The above picture shows an example of an Application Architecture Diagram depicting an overview of the Information Systems related to BEO. The information systems are connected by arrows that symbolize system dependencies.

Other functionalities: Application Architecture Diagrams can be analyzed in QualiWare via the toolbar for Application Portfolio Management. The Application Portfolio Management tools offers analysis for redundant functionalities, performance matrix generation, system heat map generation, asset lifecycle view (se below picture), lifecycle dependencies, and capabilities delivered by multiple information systems.

The above picture shows the Asset Lifecycle of the Information System ‘BEO’ and the Information Systems related to it is shown. The information depicted is pulled from the Information Systems’ metadata.

Relation to other templates: The elements depicted in the Application Architecture Diagram can be described in further detail in another Application Architecture Diagram, or in related diagrams such as a Data Flow Diagram.

The above picture shows an example of a more detailed view of an information system. In this Application Architecture Diagram the System Components are visible.

For documentation of a physical or hardware layer, the Infrastructure Diagram template can be used.

Properties and metadata: The Application Architecture Diagram can for example retain the following information:

  • A description of the diagram
  • Link to the owner of the application architecture
  • Link to the one responsible for the application architecture
  • 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 Architecture Diagram where you can view and edit the diagram’s properties.