Figure 30 gives an overview of the technology layer concepts and their relationships. Many of the concepts have been inspired by the UML 2.0 standard [8], [12], as this is the dominant language and the de facto standard for describing software applications. Whenever applicable, we draw inspiration from the analogy with the business and application layers.
Figure 30: Technology Layer Metamodel
Note: This figure does not show all permitted relationships: every element in the language can have composition and aggregation relations with elements of the same type; furthermore, there are indirect relationships that can be derived as explained in Section 8.5.
The main structural concept for the technology layer is the node. This concept is used to model structural entities in this layer. It is identical to the node concept of UML 2.0. It strictly models the structural aspect of a system: its behavior is modeled by an explicit relationship to the behavioral concepts.
An infrastructure interface is the (logical) location where the infrastructure services offered by a node can be accessed by other nodes or by application components from the application layer.
Nodes come in two flavors: device and system software, both taken from UML 2.0. A device models a physical computational resource, upon which artifacts may be deployed for execution. System software is classified as a behavioral concept, since it defines what a device “does”. Typically, a node will consist of a number of sub-nodes; for example, a device such as a server and system software to model the operating system.
The inter-relationships of components in the technology layer are mainly formed by the communication infrastructure. The communication path models the relation between two or more nodes, through which these nodes can exchange information. The physical realization of a communication path is a modeled with a network; i.e., a physical communication medium between two or more devices (or other networks).
A node is defined as a computational resource upon which artifacts may be deployed for execution.
Nodes are active processing elements that execute and process artifacts, which are the representation of components and data objects. Nodes are, for example, used to model application servers, database servers, or client workstations. They can consist of sub-nodes representing physical devices and execution environments for artifacts.
Nodes can be interconnected by communication paths. Artifacts can be assigned to (i.e., deployed on) nodes.
The name of a node should preferably be a noun. A node can consist of sub-nodes.
Artifacts deployed on a node may either be drawn inside the node or connected to it with an assignment relation.
Figure 31: Node Notation
Example
In the model below, we see an Application Server node, which consists of a Sun Blade device and a JBoss J2EE Server application.
Example 23: Node
A device is defined as a physical computational resource upon which artifacts may be deployed for execution.
A device is a specialization of a node that represents a physical resource with processing capability. It is typically used to model hardware systems such as mainframes, PCs, or routers. Usually, they are part of a node together with system software. Devices may be composite; i.e., consist of sub-devices.
Devices can be interconnected by networks. Artifacts can be assigned to (i.e., deployed on) devices. System software can be assigned to a device. A node can contain one or more devices.
The name of a device should preferably be a noun referring to the type of hardware; e.g., “IBM System z mainframe”.
A device can consist of sub-devices.
Different icons may be used to distinguish between different types of devices; e.g. mainframes and PCs.
Figure 32: Device Notation
Example
In the model below, we see a device IBM Systems z to which DB2 system software is assigned.
Example 24: Device
An infrastructure interface is defined as a point of access where the functionality offered by a node can be accessed by other nodes and application components.
An infrastructure interface specifies how the infrastructure services of a node can be accessed by other nodes (provided interface), or which functionality the node requires from its environment (required interface). An infrastructure interface exposes an infrastructure service to the environment. The same service may be exposed through different interfaces.
In a sense, an infrastructure interface specifies a kind of contract that a component realizing this interface must fulfill. This may include, for example, parameters, protocols used, pre- and post-conditions, and data formats.
An infrastructure interface may be part of a node through composition (not shown in the standard notation), which means that these interfaces are provided or required by that node, and can be used by other nodes. An infrastructure service can be assigned to an infrastructure interface, which exposes the service to the environment.
The name of an infrastructure interface should preferably be a noun.
Figure 33: Infrastructure Interface Notations
Example
In the model below, we see a Sybase Open Client infrastructure interface exposed, which is part of the Sybase system software.
Example 25: Infrastructure Interface
A network is defined as a physical communication medium between two or more devices.
A network represents the physical communication infrastructure. This may comprise one or more fixed or wireless network links. The most basic network is a single link between two devices. A network has properties such as bandwidth and latency. It embodies the physical realization of the logical communication paths between nodes.
A network connects two or more devices. A network realizes one or more communication paths.
A network can consist of sub-networks.
Figure 34: Network Notation, as Connection and as Box
Example
In the model below, a 100 Mb/s LAN network connects a mainframe and PC device.
Example 26: Network
A communication path is defined as a link between two or more nodes, through which these nodes can exchange information.
A communication path is used to model the logical communication relations between nodes. It is realized by one or more networks, which represent the physical communication links. The communication properties (e.g., bandwidth, latency) of a communication path are usually aggregated from these underlying networks.
A communication path connects two or more nodes. A communication path is realized by one or more networks. A communication path is atomic.
Figure 35: Communication Path Notation, as Connection and as Box
Example
In the model below, we see a communication path “message queuing” between an Application Server and a Client.
Example 27: Communication Path
An infrastructure service describes the externally visible and accessible functionality of a node.
System software (similar to the “execution environment” concept of UML 2.0, but with a slightly broader interpretation) represents the software environment for specific types of components and data objects that are deployed on it in the form of artifacts.
An infrastructure service is defined as an externally visible unit of functionality, provided by one or more nodes, exposed through well-defined interfaces, and meaningful to the environment.
An infrastructure service exposes the functionality of a node to its environment. This functionality is accessed through one or more infrastructure interfaces. It may require, use, and produce artifacts.
An infrastructure service should be meaningful from the point of view of the environment; it should provide a unit of functionality that is in itself useful to its users, such as application components and nodes.
Typical infrastructure services may, for example, include messaging, storage, naming, and directory services. It may access artifacts; e.g., a file containing a message.
An infrastructure service may be used by application components or nodes. An infrastructure service is realized by a node. An infrastructure service is exposed by a node by assigning it to its infrastructure interfaces. An infrastructure service may access artifacts.
The name of an infrastructure service should preferably be a verb ending with “‑ing”; e.g., “messaging”. Also, a name explicitly containing the word “service” may be used.
An infrastructure service may consist of sub-services.
Figure 36: Infrastructure Interface Notation
Example
In the model below, we see a Messaging service realized by Websphere MQ system software.
Example 28: Infrastructure Interface
System software represents a software environment for specific types of components and objects that are deployed on it in the form of artifacts.
System software is a specialization of a node that is used to model the software environment in which artifacts run. This can be, for example, an operating system, a J2EE application server, a CORBA ORB, a database system, a workflow engine, or COTS software such as ERP or CRM packages. Also, system software can be used to represent, for example, communication middleware. Usually, system software is combined with a device representing the hardware environment to form a general node.
System software can be assigned to a device. Artifacts can be assigned to (i.e., deployed on) system software. A node can contain system software.
The name of system software should preferably be a noun referring to the type of execution environment; e.g., “J2EE server”. System software may contain other system software; e.g., an operating system containing a database.
Figure 37: System Software Notation
Example
In the model below, we see DB2 system software assigned to (deployed on) an OS/390 mainframe device.
Example 29: System Software
An artifact is a physical piece of information that is used or produced in a software development process, or by deployment and operation of a system. It is the representation, in the form of, for example, a file, of a data object, or an application component, and can be deployed on a node. The artifact concept has been taken from UML 2.0.
An artifact is defined as a physical piece of information that is used or produced in a software development process, or by deployment and operation of a system.
An artifact represents a concrete element in the physical world. It is typically used to model (software) products such as source files, executables, scripts, database tables, messages, documents, specifications, and model files. An instance (copy) of an artifact can be deployed on a node.
An application component may be realized by one or more artifacts. A data object may be realized by one or more artifacts. An artifact may be assigned to (i.e., deployed on) a node. Thus, the two typical ways to use the artifact concept are as an execution component or as a data file. In fact, these could be defined as specializations of the artifact concept.
The name of an artifact should preferably be the name of the file it represents; e.g., “order.jar”. An artifact may consist of sub-artifacts.
Figure 38: Artifact Notation
Example
In the example below, we see an artifact Risk management EJB, which represents a deployable unit of code, assigned to (deployed on) an application server.
Example 30: Artifact
Table 3 gives an overview of the concepts at the technology layer, with their definitions.
Table 3: Technology Layer Concepts
|
Concept |
Definition |
Notation |
|
Node |
A computational resource upon which artifacts may be deployed for execution. |
|
|
Device |
A physical computational resource upon which artifacts may be deployed for execution. |
|
|
Network |
A physical communication medium between two or more devices. |
|
|
Communication path |
A link between two or more nodes, through which these nodes can exchange information. |
|
|
Infrastructure interface |
A point of access where the functionality offered by a node can be accessed by other nodes and application components. |
|
|
System software |
A software environment for specific types of components and objects that are deployed on it in the form of artifacts. |
|
|
Infrastructure service |
An externally visible unit of functionality, provided by one or more nodes, exposed through well-defined interfaces, and meaningful to the environment. |
|
|
Artifact |
A physical piece of information that is used or produced in a software development process, or by deployment and operation of a system. |
|
Downloads of the ArchiMate documentation, are available under license from the ArchiMate information web site. The license is free to any organization wishing to use ArchiMate entirely for internal purposes (for example, to develop an information system architecture for use within that organization). A book is also available (in hardcopy and pdf) from The Open Group Bookstore as document C091.
