TECH EXCHANGE | A ZDNet Multiplexer Blog What's this?

Before the IoT leap - Architectural principles, devices and data

Before jumping on the boat with an IoT solution, it is critical for enterprise architects to understand the fundamental principals and concepts.

The concept of the Internet of Things has revolutionised the opportunities for businesses to take their operational efficiency to a new level. The combination of smart sensors, connected devices, and intelligent operation can unearth new dimensions of opportunities in this digital era.

Information Technology giants like Microsoft are investing heavily in software offering around IoT. This includes ready to consume SaaS solutions like Azure IoT Central, IoT components-as-a-service like IoT hub, Stream Analytics, and Events hub, and real-time analytics technologies like IoT Edge.

Before jumping on the boat with an IoT solution, it is critical for enterprise architects to understand the architectural layers, design principles, and subsystems involved in a solution.

Architecture Principles

To start with, let's first explore few fundamental principles and concepts which are relevant to an enterprise-grade IoT solution.

  • Support for heterogeneous devices - A scalable IoT solution should have the ability to support a vast verity of devices, environments, protocols and business scenarios.
  • Communication security - The limited capability of client devices or sensors and the high frequency of communication between sensors and hubs makes security critical in an IoT solution. Ensuring protection of device identity, user identity, and data has to be among the primary checkpoints while architecting the solution.
  • Supporting hyper-scale deployments - IoT applications can quickly grow in size. This demands the system to be hyper-scalable to accommodate millions of devices while performing gracefully to meet the business needs.
  • Enterprise integration - The ability for the IoT solution to integrate with existing business solutions is the key to improve operational efficiency. This will involve employing adapters and bridges to communicate with numerous existing LOB systems.

Understanding your data

The next step for a solution architect is to understand the data which will be ingested by the solution. This includes the understanding of the devices or sensors which generate the data, the semantics or structure of the data, the communication protocols and the data flow.

Devices

Every device in an IoT ecosystem will have the ability to be identified uniquely. It will also have specific capabilities about the data it can capture and transmit, communication model (uni/bi-directional) and the structure of the data. This information should be captured as device metadata and device schema for every device in the IoT solution. While deciding on the devices it is important to pay attention to the following things:

  • Device connectivity and all connections and network routes are secure
  • Devices peer with a secure gateway
  • Transport and application layer protocols are secured between the device and the gateway
  • Authentication and authorisation is implemented for each device

Streams

The data records which are transmitted by IoT devices to the IoT gateways are usually addressed as streams due to its continuous nature of propagation. Every record in the event stream will have information to identify the source device and a timestamp. These streams can have information about different types of events such as the following

  • Telemetry data - This is usually information captured by the device from its environment. This information is either transmitted in its raw form or pre-processed on the device before sending it to the IoT gateway.
  • State - A state is the last known status of an entity of interest. The state is usually transmitted by the IoT devices frequently compared to other events. It can be used to determine the health of an entity of interest in an IoT solution.
  • Alert - An alert is an event raised by an IoT device based on a pre-configured rule. This rule may evaluate the status of a parameter captured by a device/sensor against configured thresholds.
  • Action - An action is an event raised by the IoT server solution to one or more IoT devices. An action can be in response to an alert or any other event. To support actions, the device has to be capable of bi-directional communication.

Once there is enough understanding of the data, devices and the ingestion stream, the architecture can now focus device gateways. Choosing the right device gateway and configuring it will be covered in my next blog.

Read more about IoT for the enterprise.