This diagram in a process variant on an ArchiMate diagram/viewpoint. This diagram can be modelled using the PLUS license.
The diagram is similar to the classic BusinessProcessNetwork template, enabling you to model your processes using the relevant subset of the ArchiMate stencil.
Nodes are active structure elements that perform technology behavior and execute, store, and process technology objects such as artifacts. For instance, nodes are used to model application platforms, defined by the TOGAF framework as: “a collection of technology components of hardware and software that provide the services used to support applications”.
Nodes can be interconnected by paths. A node may be assigned to an artifact to model that the artifact is deployed on the node.
The name of a node should preferably be a noun. A node may consist of sub-nodes.
Artifacts deployed on a node may either be drawn inside the node or connected to it with an assignment relationship.
Node properties
The Node tab
| Property | Metamodel name | Description |
| Short description | ShortDescription | |
| Implements | Implements | Links to: All templates. |
| BreaksDownTo | BreaksDownTo | Links to: All templates. |
The specialization relationship has been inspired by the generalization relationship in UML class diagrams, but is applicable to specialize a wider range of concepts. The specialization relationship can relate any instance of a concept with another instance of the same concept.
A specialization relationship is always allowed between two instances of the same element.
Alternatively, a specialization relationship can be expressed by nesting the specialized element inside the generic element.
Purpose: Designing, deciding
Concerns: Dependencies between business processes, consistency and completeness, responsibilities
Scope: Multiple layer/Multiple aspect
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:
Each of these can be regarded as a “sub-viewpoint” of the business process cooperation viewpoint.
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
Concerns: Architecture mission and strategy, motivation
Purpose: Designing, deciding, informing
Scope: Motivation
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.
Concerns: Architecture mission, strategy and tactics, motivation
Purpose: Designing, deciding
Scope: Motivation
The goal realization viewpoint allows a designer to model the refinement of (high-level) goals into more tangible goals, and the refinement of tangible goals into requirements or constraints that describe the properties that are 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.
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.
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.
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.