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: Structure of application platforms and how they relate to supporting technology
Purpose: Designing, deciding
Scope: Multiple layer/Multiple aspect
The implementation and deployment viewpoint shows how one or more applications are realized on the infrastructure. This comprises 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.
Concerns: Structure and dependencies of the used data and information, consistency and completeness
Purpose: Designing
Scope: Multiple layer/Single aspect
The information structure viewpoint is comparable to the traditional information models created in the development of almost any information system. It shows the structure of the information used in the enterprise or in a specific business process or application, in terms of data types or (object-oriented) class structures. Furthermore, it may 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; e.g., by means of a database schema.
Concerns: Added-value of business processes, consistency and completeness, responsibilities
Purpose: Designing, deciding
Scope: Multiple layer/Multiple aspect
The service realization viewpoint is used to show how one or more business services are realized by the underlying processes (and sometimes by application components). Thus, it forms the bridge between the business products viewpoint and the business process view. It provides a “view from the outside” on one or more business processes.
Concerns: Relationships and dependencies of the physical environment and how this relates to IT infrastructure
Purpose: Designing
Scope: Multiple layer/Multiple aspect
The physical viewpoint contains equipment (one or more physical machines, tools, or instruments) that can create, use, store, move, or transform materials, how the equipment is connected via the distribution network, and what other active elements are assigned to the equipment.
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.