Figure 77 gives an overview of the Technology Layer elements and their relationships. Whenever applicable, inspiration is drawn from the analogy with the Business and Application Layers.
Note: This figure does not show all permitted relationships: every element in the language can have composition, aggregation, and specialization relationships with element of the same type; furthermore, there are indirect relationships that can be derived as explained in Section 5.6.
The Technology Layer is typically used to model the technology architecture of the enterprise, defined by the TOGAF framework  as: “the structure and interaction of the platform services, and logical and physical technology components”.
10.2 Active Structure Elements
The main active structure element for the Technology Layer is the node. This element is used to model structural entities in this layer. It strictly models the structural aspect of a system: its behavior is modeled by an explicit relationship to the behavior element.
A technology interface is the (logical) place where the technology 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. A device models a physical computational resource, upon which artifacts may be deployed for execution. System software is an infrastructural software component running on a device. Typically, a node consists 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 path models the relation between two or more nodes, through which these nodes can exchange information. The physical realization of a path is modeled with a network; i.e., a physical communication medium between two or more devices (or other networks).
Nodes are active structure elements that perform technology behavior and execute, store, and process technology objects such as artifacts (or materials, as outlined in Chapter 11). 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.
A device is a specialization of a node that represents a physical IT 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. Devices can be assigned to artifacts and to system software, to model that artifacts and system software are deployed on that 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”.
Different icons may be used to distinguish between different types of devices; e.g., mainframes and PCs.
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 JEE application server, a database system, or a workflow engine. 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.
A device or system software can be assigned to other system software; e.g., to model different layers of software running on top of each other. System software can be assigned to artifacts, to model that these artifacts are deployed on that software. System software can realize other system software. A node can be composed of system software.
The name of system software should preferably be a noun referring to the type of execution environment; e.g., “JEE server”. System software may be composed of other system software; e.g., an operating system containing a database.
A technology collaboration specifies which nodes cooperate to perform some task. The collaborative behavior, including, for example, the communication pattern of these nodes, is modeled by a technology interaction. A technology collaboration typically models a logical or temporary collaboration of nodes, and does not exist as a separate entity in the enterprise.
Technology collaboration is a specialization of node, and aggregates two or more (cooperating) nodes. A technology collaboration is an active structure element that may be assigned to one or more technology interactions or other technology internal behavior elements, which model the associated behavior. A technology interface may serve a technology collaboration, and a technology collaboration may be composed of technology interfaces. The name of a technology collaboration should preferably be a noun.
A technology interface specifies how the technology services of a node can be accessed by other nodes. A technology interface exposes a technology service to the environment. The same service may be exposed through different interfaces.
In a sense, a technology 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.
A technology interface may be part of a node through composition (not shown in the standard notation), which means that these interfaces are provided by that node, and can serve other nodes. A technology interface can be assigned to a technology service, to expose that service to the environment.
The name of a technology interface should preferably be a noun.
Note: In previous versions of this standard, this element was called ‘infrastructure interface’. This usage is still permitted but deprecated, and will be removed from a future version of the standard.
A path is used to model the logical communication (or distribution) relations between nodes. It is realized by one or more networks, which represent the physical communication (or distribution) links. The properties (e.g., bandwidth, latency) of a path are usually aggregated from these underlying networks.
A path connects two or more nodes. A path is realized by one or more networks. A path can aggregate nodes.
A communication network represents the physical communication infrastructure. It represents ”a set of products, concepts, and services that enable the connection of computer systems or devices for the purpose of transmitting data and other forms (e.g., voice and video) between the systems”, as defined by the TOGAF framework .
A communication network connects two or more devices. The most basic communication network is a single link between two devices, but it may comprise multiple links and associated network equipment. A network has properties such as bandwidth and latency. A communication network realizes one or more paths. It embodies the physical realization of the logical path between nodes.
A communication network can consist of sub-networks. It can aggregate devices and system software, for example, to model the routers, switches, and firewalls that are part of the network infrastructure.
Note: Formerly, this element was called ‘network’. This usage is still permitted but deprecated, and will be removed from a future version of the standard.
Two Blade System devices are connected to a communication network Data Center Network. This in turn is connected to another communication network Wide Area Network through a node Data Center Switch. The two communication networks together realize a path Data Replication Path. Both Blade System devices and the Data Center Switch node have a technology interface Management Interface. Device Blade System 1 deploys Hypervisor system software for hardware virtualization. Two system software components are deployed on the Hypervisor: an Open Source Operating System and a Proprietary Operating System, creating two virtual hosts, modeled as nodes Quotation Virtual Host and Purchase Virtual Host.
Behavior elements in the Technology Layer are similar to the behavior elements in the other layers. Also here, a distinction is made between the external behavior of nodes in terms of technology services, and the internal behavior of these nodes; i.e., technology functions that realize these services.
A technology function describes the internal behavior of a node; for the user of a node that performs a technology function, this function is invisible. If its behavior is exposed externally, this is done through one or more technology services. A technology function abstracts from the way it is implemented. Only the necessary behavior is specified.
A technology function may realize technology services. Technology services of other technology functions may serve technology functions. A technology function may access technology objects. A node may be assigned to a technology function (which means that the node performs the technology function). The name of a technology function should preferably be a verb ending with “ing”.
Note: In previous versions of this standard, this element was called ‘infrastructure function’. This usage is still permitted but deprecated, and will be removed from a future version of the standard.
A technology process describes internal behavior of a node; for the user of that node, this process is invisible. If its behavior is exposed externally, this is done through one or more technology services. A technology process abstracts from the way it is implemented. Only the necessary behavior is specified. It can use technology objects as input and use or transform these to produce other technology objects as output.
A technology process may realize technology services. Other technology services may serve (be used by) a technology process. A technology process may access technology objects. A node may be assigned to a technology process, which means that this node performs the process. The name of a technology process should clearly identify a series of technology behaviors; e.g., “System boot sequence” or “Replicate database”.
A technology interaction describes the collective behavior that is performed by the nodes that participate in a technology collaboration. This may, for example, include the communication pattern between these components. A technology interaction can also specify the externally visible behavior needed to realize a technology service. The details of the interaction between the nodes involved in a technology interaction can be expressed during the detailed design using, for example, a UML interaction diagram.
A technology collaboration may be assigned to a technology interaction. A technology interaction may realize a technology service. Technology services may serve a technology interaction. A technology interaction may access artifacts. The name of a technology interaction should clearly identify a series of technology behaviors; e.g., “Client profile creation” or “Update customer records”.
Technology functions and other technology behavior may be triggered or interrupted by a technology event. Also, technology functions may raise events that trigger other infrastructure behavior. Unlike processes, functions, and interactions, an event is instantaneous: it does not have duration. Events may originate from the environment of the organization, but also internal events may occur generated by, for example, other devices within the organization.
A technology event may have a time attribute that denotes the moment or moments at which the event happens. For example, this can be used to model time schedules; e.g., to model an event that triggers a recurring infrastructure function such as making a daily backup.
A technology event may trigger or be triggered (raised) by a technology function, process, or interaction. A technology event may access a data object and may be composed of other technology events. The name of a technology event should preferably be a verb in the perfect tense; e.g., “message received”.
A technology service exposes the functionality of a node to its environment. This functionality is accessed through one or more technology interfaces. It may require, use, and produce artifacts.
A technology service should be meaningful from the point of view of the environment; it should provide a unit of behavior that is, in itself, useful to its users, such as application components and nodes.
Typical technology services may, for example, include messaging, storage, naming, and directory services. It may access artifacts; e.g., a file containing a message.
A technology service may serve application components or nodes. A technology service is realized by a technology function or process. A technology service is exposed by a node by assigning technology interfaces to it. A technology service may access artifacts. A technology service may consist of sub-services.
The name of a technology service should preferably be a verb ending with “ing”; e.g., “messaging”. Also, a name explicitly containing the word “service” may be used.
Note: In previous versions of this standard, this element was called ‘infrastructure service’. This usage is still permitted but deprecated, and will be removed from a future version of the standard.
A technology event Database Update triggers a technology process Remote Data Replication, which is served by a technology service Replicate Database Updates. This technology service is realized by a technology function Database Replication, which is composed of four other technology functions: Administrate Replication, Handle Local Updates, Handle Remote Updates, and Monitor Replication Status. There are information flows from the Administrate Replication technology function to the other three technology functions.
10.4 Passive Structure Elements
A technology object models the passive structure elements that are used and processed by the infrastructure. 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 element has been taken from UML .
Technology objects represent the “physical” objects manipulated by the infrastructure of an enterprise. Technology objects are abstract elements; i.e., they are not instantiated in models but serve as the generic type of the things manipulated by the Technology Layer. This may include both artifacts (e.g., files) and physical material.
Technology objects may be accessed by technology behavior (functions, processes, interactions, events, and services). A technology object may have association, specialization, aggregation, or composition relationships with other technology objects. A technology object may realize a data object or business object. It may be realized by an artifact or material (from the physical elements). The name of a technology object should preferably be a noun.
An artifact represents a tangible element in the IT world. Artifact is a specialization of technology object. 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 artifact could be used to represent a physical data component that realizes a data object.
An application component or system software may be realized by one or more artifacts. A data object may be realized by one or more artifacts. A node may be assigned to an artifact to model that the artifact is deployed on the node. Thus, the two typical ways to use the artifact element are as an execution component or as a data file. In fact, these could be defined as specializations of the artifact element.
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.
A Web Archive artifact (which may realize an application component) is composed of two other artifacts: Database Access Java Archive and Business Logic Java Archive. Two specializations of the Web Archive artifact are a Purchase Application Web Archive and a Quotation Application Web Archive. A Travel Insurance Database artifact (which may realize a data object) is associated with the Web Archive artifact.
10.5 Summary of Technology Layer Elements
Table 8 gives an overview of the Technology Layer elements, with their definitions.
Table 8: Technology Layer Elements
A computational or physical resource that hosts, manipulates, or interacts with other computational or physical resources.
A physical IT resource upon which system software and artifacts may be stored or deployed for execution.
Software that provides or contributes to an environment for storing, executing, and using software or data deployed within it.
An aggregate of two or more nodes that work together to perform collective technology behavior.
A point of access where technology services offered by a node can be accessed.
A link between two or more nodes, through which these nodes can exchange data or material.
A set of structures and behaviors that connects computer systems or other electronic devices for transmission, routing, and reception of data or data-based communications such as voice and video.
A collection of technology behavior that can be performed by a node.
A sequence of technology behaviors that achieves a specific outcome.
A unit of collective technology behavior performed by (a collaboration of) two or more nodes.
A technology behavior element that denotes a state change.
An explicitly defined exposed technology behavior.
A passive element that is used or produced by technology behavior.
A piece of data that is used or produced in a software development process, or by deployment and operation of a system.