IoT has generated a lot of interest recently and has moved from a purely academic pursuit to the point where real use cases are being realized. IoT implementation is inherently complex due to multiple and diverse technologies (embedded, cloud, edge, big data, artificial intelligence (AI), machine learning (ML), and so on) being involved and due to the range of deployment options that are available (constraint devices in the field to the almost unlimited availablity of compute and other resources in the cloud). IoT enables diverse use cases and spans multiple domains (home automation, healthcare, track-and-trace, connected vehicles, autonomous driving, and more).

The relevance of IoT is only going to increase in the coming years because of the following reasons:

• IoT use cases encompass physical and virtual worlds and as a result, interesting and rich use cases can be developed (compared to purely virtual/software systems such as word processors, ERP systems, and more). It can be said that the scope and variety of IoT use cases is only limited by a person’s imagination.
• The immense potential of IoT has been validated by both academics and implementors. This can be attributed to the following reasons:
  • The increased capability and efficiency of hardware components with a continous decrease in cost (and size) in line with Moore’s law. Efficient battery utilization by the current generation of hardware components has also reduced the hassles of frequent battery replacement.
  • The rise of commercial cloud providers (hyperscalers), which enables unlimited scalability in terms of compute, storage, complex analytics, high-speed data ingestion, and more. These characteristics are very well suited to the needs of IoT applications. The following are some of the services that are provided by public cloud providers/hyperscalers and that can be leveraged while developing IoT use cases:
    • Device management
    • Firmware updates
    • Edge management/analytics
    • Device/data security
    • Digital twins
    • IoT analytics
    • Data ingestion
    • Data visualizations
    • Data storage
    • Video analytics
    • Notifications
  • Ubiquitous and low-cost connectivity in the form of traditional connectivity options (for example, Wi-Fi, 3G, and 4G) as well as connectivity options such as LoRaWAN and NB-IoT. Technologies such as NB-IoT are especially useful for IoT as they support long-range connectivity and provide long battery life. The advent of 5G has further enlarged the scope of IoT use cases by providing high bandwidth and minimal latency.
  • The increased maturity of related technologies such as blockchain, robotics, AI/ML, energy harvesting, AR/VR, drones, social media, and more. These technologies enable IoT practitioners to augment IoT capabilities with the capabilities provided by these technologies to push the boundaries of innovation further and envisage non-conventional ideas.
  • The increased adoption of mobile and wearable devices. These devices enable anytime access to IoT data and help control and monitor IoT devices in real time.
• Increased market competition, which forces enterprises to treat data as the fulcrum for decision-making as well as monetization opportunities. IoT also acts as the foundation for operationalizing additional revenue models such as service revenue over and above product sale revenue.

It is important to understand how IoT systems are different from non-IoT systems. A few of the key differentiators are as follows:

• Humans play a vital role in operating and managing most non-IoT (traditional IT/OT systems) systems, whereas IoT systems are designed to operate on their own or with minimal human intervention.
• IoT devices are constrained in terms of the compute, storage, or both, whereas most non-IoT applications are deployed on standard workstations where an ample amount of storage and compute is available.
• IoT applications, once deployed, are expected to last for years (10 to 15 years is the norm in the manufacturing industry) compared to non-IoT applications, where the shelf life is less (typical refresh cycles range between 3 to 5 years). Accordingly, IoT systems must be architected by balancing both current and long term needs.
• Considerable heterogeneity is observed in the selection of the hardware/software components as well as connectivity protocols. This is because there are different technologies to choose from, and for each technology choice, there are multiple implementations and offerings available from vendors. In comparison, there are fewer technology options possible in non-IoT systems.
• There are differences in the characteristics of the data that is generated in IoT and non-IoT systems. All the seven V’s of big data (velocity, variety, variability, volume, veracity, visualization, and value) are high in IoT systems compared to non-IoT systems.
• Very few IoT systems operate in isolation and are generally integrated with other enterprise systems. In IoT systems, there is a need to integrate Information Technology (IT) and Operational Technology (OT), as well as hardware devices. This presents an entirely new level of integration complexity that is rarely seen in traditional systems.
• Security is important in any connected system, but it becomes much more important in IoT as the attacks can result in physical harm (industrial robots gone rogue) in addition to reputation/financial loss. Additionally, most IoT field devices are installed in vulnerable environments where they can easily be tampered with. Therefore, the attack surface in an IoT use case is much larger than that of a non-IoT use case.

These unique characteristics of IoT systems can be visualized in the following diagram:

Figure 1.1 – Unique characteristics of an IoT system

This complexity can be quite daunting to anyone who has just ventured into the IoT domain. Although a rich variety of IoT use cases (or solution domains) is possible, there is also a certain degree of commonality that is present in most of the IoT use cases and related architectures. We have mentioned these similarities so that anyone who is new to this domain can understand the existing architectures and use cases.

The IoT reference architecture follows a layered model, as shown in the following diagram:

Figure 1.2 – Layered IoT reference architecture

Let’s look at these layers in more detail:

• Perception/actuation layer: This layer indicates the physical layer where sensors (pressure, temperature, and so on) gather information about the environment. In turn, the environment is affected by the actuators (electric motor, thermostat control, and so on).
• Connectivity layer: This layer provides the connectivity required to send data (perception data from sensors and control commands to actuators, and so on) to/from the aggregation/processing layer. This layer is realized by leveraging connectivity options (5G, Wi-Fi, NB-IoT, LoRA, and so on). The decision to choose a specific connectivity option depends on various factors such as range and bandwidth.
• Processing layer: The processing layer ingests, analyzes, and stores data received from the connectivity layer. The processing can be performed either near the data source (edge computing) or in a private/public cloud. Data processing and storage elements, such as databases, data streaming engines, and AI/ML algorithms, form part of this layer.
• Services layer: This layer connects the processing layer to the application layer. Another way of looking at this layer is considering it as a set of APIs that can be consumed by the application layer to develop IoT applications such as smart homes, precision agriculture, smart manufacturing, and more.
• Application layer: This layer represents the applications that are to be used by end users. These applications are typically hosted at the edge or in the cloud (central server) and are consumed using mobile devices as mobile apps. Alternatively, they can be deployed on a web server and accessed using browsers.

The IoT patterns listed in subsequent chapters will align with the IoT reference architecture that we just discussed. Additionally, other important IoT topics listed in the latter part of the book (such as data analytics and IoT security) will also build upon the understanding of this concept.

The layered reference architecture provides various benefits, such as independent scalability of different layers and enhanced maintainability as change is restricted to specific layers. The IoT patterns will help you develop the required functionality at the specific layer in less time and in a reproducible fashion. The architectural patterns (detailed in subsequent chapters) that are relevant to the different layers of the reference architecture are shown in the following diagram:

Figure 1.3 – IoT patterns realized at different layers of the reference architecture

Next, we will look at the unique requirements that we should be aware of while implementing IoT use cases.

IoT use cases tend to have very unique requirements concerning power consumption, bandwidth, analytics, and more. Additionally, the inherent complexity of IoT implementations (computationally challenged field devices on one end of the spectrum vis-à-vis almost infinite capacity of the cloud on the other) forces architects to make difficult architectural decisions and implementation choices. The diversity of the available implementation technologies and the absence of well-established standards are additional challenges that makes architecture decisions difficult.

This book attempts to alleviate some of the challenges associated with architecting IoT use cases by identifying the commonalities between the architectures that can support these use cases. It is important not to get blindsided by the diversity of the use cases and recognize the fact that diversity exists at the superficial level and under the hood. This book intends to bridge this gap in the current understanding by demonstrating how the implementation of diverse IoT use cases can be traced back to a handful of architectural patterns.

Before presenting the various IoT patterns, it is worth mentioning the unique expectations from IoT architectures that are different from non-IoT architectures:

• Sensing events and actuation commands have a wide range of latency expectations – from real-time to fire and forget.
• Data analysis results need to be reported/visualized/consumed on a variety of consumer devices – mobiles, desktops, tablets, and more. Similarly, data consumers have diverse backgrounds, data needs, and application roles (personas).
• One is often forced to integrate with legacy as well as cutting-edge devices and/or external systems – very few trivial use cases have isolated/standalone architectures. There is a considerable difference in the way the data is extracted from legacy versus non-legacy systems – legacy systems may internally collate the data and then push it to the external port (file transfer), whereas newer systems may push the data in a continuous stream (time-series data). This variability is one of the critical considerations when choosing a particular IoT architectural pattern.
• Varied deployment requirements – edge, on-premise, hybrid, the cloud, and more.
• Adherence to strict regulatory compliances, especially in medical and aeronautical domains.
• There are expectations considering immediate payback, return on investment (ROI), business outcomes, and new service business models.
• Continuous innovation, which results in new services or offerings (especially by cloud vendors), forcing IoT architectures to be in continuous sync mode with these new offerings or services.
• The scarcity of skilled architects who can formulate end-to-end IoT solutions – although people with specific skills sets might be available (device architects, connectivity architects, and cloud architects); however, there are very few end-to-end IoT architects.
• No common standard for devices, device connectivity, IoT protocols, or the message transport layer leads to complex device management.
• Typically, IoT stacks don’t operate in isolation and any non-trivial deployed IoT solution would need to integrate with other external systems (ERPs, AMDBs, MESs, and so on). Even here, there is no standard for how to integrate these systems seamlessly. The external systems typically predate IoT deployments by decades and are heavily customized with no consideration for integration needs.
• From one perspective, IoT implementation is a process automation initiative. In general, the process exists but is performed manually and IoT is expected to automate the process either partially or fully. Generally, these existing workflows are not documented and exist as part of tribal knowledge of the process practitioners, which poses challenges for IoT architects as they don’t have clarity regarding the processes and workflows. Hence, they face a dilemma regarding which subprocesses should be automated to maximize their ROI – they have to decide if they are content with minor improvements (local optimization) and forgo benefits that can be accrued by considering global optimizations.
• Device life cycle management is a challenge in domains such as cardio medical devices as they can’t afford downtime but still need a timely firmware update (especially patches related to security fixes, which can’t be deferred beyond a certain point).
• The need to calibrate field sensors at regular intervals poses a challenge. The rate of drift varies from sensor to sensor and from one environment to another. There is a tendency to compensate for this drift by applying AI/ML models at the edge or in the cloud, but these steps are far from ideal as they lack accuracy and may not fully consider local or ambient conditions.
• Use cases that rely on positional information tend to have limited acceptance as all the locational sensors (indoor or outdoor) have limited accuracy.
• The migration of massive amounts of edge-processed historical data (accumulated over decades) to the cloud is another key architectural challenge that is observed in many Machine-to-Machine (M2M) to IoT transformation initiatives.
• The desired non-functional requirement (NFR) (scalability, availability, security, data residency/privacy, and so on) values vary from use case to use case and add another layer of complexity.
• Consumers of IoT data have diverse backgrounds (for example, the information needs of a home automation user would differ widely from an industrial user who wants to monitor plant uptime, which, in turn, would be different from the needs of paramedical staff using IoT for automated clinical trials), so they have different ways of operating and leveraging IoT systems. Although this may seem to have more bearing on device UI design, it can impact the solution architecture in subtle ways as well.

In the next section, we will list the architectural principles or considerations that will help you address the unique requirements of implementing IoT solutions.

Certain principles, which ensure that architectures, once realized, are scalable, modifiable, robust, and fault-tolerant are especially relevant for IoT architectures. Let’s take a look at some of these:

• Built on open communication protocols to support diverse device communication needs: As IoT is an amalgamation of real (hardware) and virtual (software) realms, each of which evolves at its own independent pace. Robust IoT architectures should be flexible enough to support current and possible future enhancements in both these realms – for example, on the one hand, continual advancements are made for connectivity/power capabilities on the device/hardware side, while on the other hand, there are central server side advances regarding analytics and AI/ML capabilities. Hence, there is an inherent impedance mismatch between real and virtual worlds (concerning the rate as well as nature of these enhancements). IoT architects should not only be aware of this mismatch but should also incorporate the required considerations to support the use case requirements for a longer time frame. These requirements are partially handled by adhering to a layered architecture whereby the components in a specific layer can be plugged in or plugged out with minimal impact on the overall architecture.
• Designed for “end-to-end” security: Security is an important consideration for any software system, especially in cases where data or commands are communicated over public communication channels. However, in terms of IoT, security requires deeper consideration, primarily due to two reasons:
  • Actions initiated in the real/physical world can’t be rescinded, unlike the actions in the virtual/software world: An irrigation pump that is instructed (maliciously) to start pumping water in an agriculture field would have pumped considerable water before someone detects the anomaly and initiates corrective action. This contrasts with the scenario in the software world, where a simple update instruction is sufficient to undo/roll back database changes. Scenarios can be even more disastrous in domains such as healthcare, where IoT systems often control human life (for example, an oxygen ventilator controlled by an IoT system).
  • The attack vector is considerably broader compared to pure software systems: This is because the complete data pipeline (end device > gateway > communication channel > central server > application) needs to be secured and each entity in the data pipeline has diverse applicable security requirements – end devices (with their inherently constrained compute/storage capabilities) can’t support the security rigor that the central server can support, so each component’s security vulnerabilities and the relevant security guardrails need to be independently analyzed. Similarly, data should be protected in transit as well as at rest at all times.
• Enterprise integration enabled by the “API-first” approach: Any production-grade IoT system will typically be integrated with other external systems to deliver full value. Real-world data collated by IoT systems is fed (data push) into external systems to enable richer use cases. Similarly, data from the external systems (data pull) is used to enrich the collated data. This type of integration is not possible unless the IoT system has been architected with API-first as one of the core architectural tenants whereby IoT data can be consumed by enterprise applications. These APIs also enable workflows that span both IoT and non-IoT (that is, external systems).
• Satisfy diverse data needs: IoT systems are leveraged by a diverse set of users, each with different backgrounds and information needs. Accordingly, it is important to capture the raw data needs of all the (current and future) stakeholders and to present the data in a way that is easily assimilable by a diverse set of stakeholders (personas). Role-based access control (RBAC) is one mechanism that shows the required information to stakeholders while at the same time obscuring non-relevant information. Also, some of the stakeholders will have real-time data needs (operators who want real-time notifications for emergency alarms), whereas others will want insights from consolidated data (batch processing). Decoupling data ingestion from data processing is one such principle that enables us to accomplish this need. Some of the other data collation/manipulation requirements are listed as follows:
  • Diverse (structured, semi-structured, and unstructured) operational data from sources such as Manufacturing Execution Systems (MESs) and Laboratory Information Management Systems (LIMSs) should be consolidated in a common data store (data lake) either at the edge, the cloud, or both.
  • Separating streaming, batch, and right-time data pipelines for scalability, efficiency, and cost optimization considerations. De-coupling data producers from consumers ensures a robust architecture as well as the flexibility of technology and implementation choices.
• Technology-neutral architecture providing deployment flexibility: IoT systems can be deployed in different configurations, such as on-premise, public cloud, private cloud, and/or hybrid multi-cloud configurations, depending on the customer’s sensitivity to security as well as governance and regulatory needs. Considering this, the architecture should be generic enough that it can cater to diverse deployment needs and can be supported by multiple technology stacks. This is generally achieved by creating an IoT reference architecture (devoid of specific technology choices) and then transitioning to a technical architecture (where generic architectural components are replaced by specific technology components).
• Design for high availability: Although the need for high availability varies widely from one IoT use case to another, some use cases are categorized as mission-critical with almost zero downtime expectations, whereas others can accommodate a considerable downtime period. The central server architecture should mimic the uptime expectations as typically, less downtime translates into higher costs. In the context of IoT, high availability must be considered from an overall system perspective. For example, in scenarios where longer central server downtime is acceptable, end devices need to have higher data buffering capabilities (that is, greater storage space) to minimize data loss.
• Support for “unlimited scalability”: IoT deployments start small with a few end devices but tend to scale to a large number in a short duration. As a result, generally, in IoT solutions, horizontal scalability is preferred over vertical scalability.
• Device communication considerations: Data is communicated over a bi-directional communication channel between the gateway and central server. This channel can be supported by multiple communication technologies (with some of the common ones being cellular, Wi-Fi, LoRa, and SigFox). Considerations such as range (physical distance from the central server), payload size, battery life, and ambient noise play a role in finalizing the ideal communication technology for a particular IoT implementation. Some of the other considerations from the device side include the ability to store/buffer data in case of connectivity loss to central server, sleep/wakeup logic for conserving battery power, and data aggregation/filtering needs.

The following diagram summarizes the key architectural principles/considerations discussed in this section:

Figure 1.4 – Architectural considerations for developing IoT solutions

This introductory chapter helped you understand the architectural considerations need to be considered while developing or deploying IoT solutions. Additionally, the chapter provided contextual knowledge that will help you understand the patterns listed in this book. The characteristics that make IoT solutions different from other traditional software systems or IT solutions were discussed, along with information about the different layers of the IoT reference architecture. In the next two chapters, we will dive deep into the IoT architectural patterns.