Unique requirements of 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.