How to model devices in Ardoq

This article describes how to extend the Ardoq Solutions metamodel to include a representation of network-attached devices. A new component type, Device, is introduced along with additions to the metamodel to enable devices to be connected to your technology catalog and other components that represent data, applications, integrations and physical locations. The new component type can be used to represent a wide range of devices and operational technologies (OT) such as industrial control systems, building management systems, fire control systems and physical access control mechanisms. Examples include SCADA and Internet of Things (IoT) sensors, medical equipment and robots.

All of these share some common characteristics: they combine a deployed device in a physical location with hosted software that is attached to the network. They have potential to be considered AI Systems from a governance perspective, and their use of data might involve the processing or storage of personal data, bringing them within the scope of data protection regulations. There are good reasons, therefore, to include them within an Enterprise Architecture repository.

The Device component type represents the combination of the physical device together with the software it contains. Its representation in the metamodel looks very similar to that of an application, since it is through its embedded software that it acquires its connectivity to other components that are modeled in the repository.

The diagram above shows the new component type, Device, and its primary connections to other component types in the Solutions metamodel. The Device component type is the only new element here, so existing fields and many other reference types associated with all the other component types in the diagram have been left out to avoid overfilling the diagram.

Given the variety of device types that the Device component type can represent, we anticipate users choosing to add quite specific fields with which to describe them. We recommend adding the calculated checkbox field, AI System, if you have deployed the Enterprise AI Management Solution. The field is already defined in the Solution, so all you need to do is add the Device component type to the list of component types to which the field is applied. This caters for the possibility that a device is also an AI System, and should be governed as such. See the Enterprise AI Management Solution for details of how AI Systems are recognized in Ardoq.

Note that whilst adding the AI System field to the Device component type will bring your devices inside the scope of the AI Lens solutions, the solutions’ accompanying assets will need to be updated to make sure they include Devices among their content. This means that reports, viewpoints, surveys will need to have updates to the Workspaces they cover, and may need new questions or updated gremlin code to cater for the fact that Device components can now be AI Systems.

If you have chosen to maintain a technology catalog (see Technology Portfolio Management Solution for details), we recommend including your devices in the catalog alongside other technology components (Applications, Technology Services, Data Store and Servers). You may wish to add a new Category to your catalog to organize the Technology Products that represent your range of devices, but in all other respects the relationship between the catalog and your devices is the same as that for other technologies (i.e. it uses the Deploys To reference to link catalog items to deployed instances).

If you have complex composite devices that contain multiple elements (e.g. multiple sensors or multiple software components), you may wish to represent each of these elements as a separate Technology Product in the catalog, and link them together to a single composite catalog entry that then has the Deploys To reference to deployed instances. This article describes an example of this (a composite database server).

Like Application components, a Device may have a child Interface component. This is used to model its integration with Applications that initiate calls to send data to, or receive data from, the Device using a Connects To reference. The Interface component in the Device behaves in the same way as an Interface that is the child of an Application. It is used when the Application initiates the call, either pushing data to the Device, or pulling data from it. The data that is managed by the Interface can be represented with Supplies references to the relevant Data Entity components.

If the Device initiates the call, either to send or receive data, then the integration should be modeled with a Connects To reference from the Device to the Interface of the Application it is integrated with. Again, the data that is pushed or pulled is represented with Supplies references from the Application’s Interface component to the relevant Data Entities.

Data may be persisted on a Device, and recording this fact can be significant, especially when considering data sovereignty and the physical location of the device (and its stored data). An Is Stored On reference can be used to link a Data Entity to the Device on which that data is stored.

Data that is processed by, but not persisted on, the Device, can be represented with an Accesses reference from the Device to a Data Entity component.

The physical location of the Device is represented with an Is Located At reference from the Device to a Location component.

Combining these references, it is possible to identify where, geographically, different data entities are processed on devices, and separately, where they are persisted on devices.

Devices may rely upon supporting software infrastructure that is not deployed on the Device (e.g. authentication services running in the cloud). These relationships can be represented using Is Supported By references from the Device to the supporting services, which will be represented as Technology Service components. This allows you to make the distinction between integrations with Applications that involve exchanges of data, and reliance upon supporting services to enable the Device to function. This is the same approach that is adopted to represent infrastructure that supports Applications, Data Store or tiers of Technology Services.