IoT Architecture Principles
Photo by Jen Theodore on Unsplash
The practice of identifying architecture principles is paramount to defining the overall architecture of any software system. Many times, it is possible to create an architecture for an IoT domain in multiple ways. And all the outcomes are valid blueprints of a system being designed but what is apt is the one that complies with all the architecture principles. Therefore, it's critically important to approach an architecture by starting with identifying and comprehending all Architecture Principles.
Let’s take an example of a retailer who is interested in finding the count of visitors to her store in a given time frame. She can simply install a hardware people counter at the entrance to determine footfall into the premises. This device can be attached to a gateway that receives and aggregates data, and then transmits it to an IoT platform where processing on this data can determine the footfall of customers. However, the actual architecture to implement such a system would get affected by some of the following considerations:
How would the hardware module be fixed, if it malfunctions?
Where would the streaming data be processed, edge or cloud?
What are the enterprise systems to connect with the IoT platform, to enhance the data acquired?
Can the same data be used for other use cases?
How can the store employees be distinguished from visitors while counting?
How can the store visits be related to conversions?
How can it be ensured that people are not identified and privacy regulations are complied with?
Is there a data duplication with other data collected from systems already in the enterprise?
How can we configure the access control to the systems being built?
How can devices or gateways be controlled and reconfigured remotely ?
How would the system scale if the same technology is to be installed at multiple locations etc.?
These and more concerns highlight the importance of defining Architecture Principles prior to actually creating the architecture.
Following are some of the Architecture Principles related to IoT system design that I have come across in many years of designing IoT systems. This list is only indicative and in no way definitive for any particular IoT solution or domain. Here you go:
1. Standardized Integration
Some enterprises mandate the use of an enterprise service bus for all communication between systems while others may restrict integration to using API only. Whichever integration mechanism is employed, such a mandate ensures external and enterprise systems are integrated uniformly which enhances the maintainability of the overall IT inventory. Based on the enterprise mandate, a standard integration mechanism could be a guiding principle to follow while designing IoT solutions. It can considerably increase the speed of on-boarding new systems thereby adding more value to an IoT ecosystem.
2. Platform Agnosticism
While architecting IoT solutions based on AWS, Azure, GCP or any other cloud platform, the usage of PaaS services binds the solutions to that vendor. Avoiding such a vendor lock-in may be part of the enterprise directive but it entails that the full capability of the underlying platform is under utilized. A hybrid approach is sometimes followed where the business logic is at least made more portable than the rest of the components. For instance, using Kubernetes based on serverless (Functions as a Service) components instead of Azure Functions.
3. Data Residency and Compliance
Data Residency is a requirement that is gaining prominence across all organizations implementing IoT or any other cloud based solution. Set as a principle, it affects the choice of components or sometimes even the cloud provider itself, for implementing the solution. Some cloud services are not available in all regions or countries and in some cases a service could be available in a country but sub-processing of data by that service may happen outside the boundary of the country. Such strong mandates affect the vendor selection, technical architecture and design choices quite significantly.
4. Using existing investments
This is especially more frequent in case of Big Data Analytics and Data lake existing in an enterprise. Data Analytics and Big Data technologies have existed even before IoT entered the mainstream. Though all IoT platforms are capable of processing and storing big data and applying analytical models on this data, such capability already exists in many enterprises. The idea behind this principle is to utilize existing investments on such functionality.
5. Prefer Edge Intelligence to Cloud Processing
With most cloud platforms offering machine learning and serverless constructs on the edge, the acceptance of edge as a processing node is more than ever. The primary benefit being that this form of distributed computing reduces processing load in the cloud. Additionally, edge computing also reduces the network bandwidth consumption of sending every bit of raw data to the backend.
6. Security by design
Device and Data security is paramount in ensuring end to end security of an IoT system. Data security involves protecting data in transit and at rest. Device security usually involves device identity and authentication based on security certificates. With such a directive in place, all IoT development happens defensively. And hence it influences the low level design of IoT functions.
7. Real time processing of Alarms/Alerts
While the usual telemetry data from devices can take a path of ingestion, storage, processing, analytics and visualization, the device alarms and alerts must take an emergency path to notify business apps or configured email/sms route for quicker action. This entails multiple data processing pipelines with varying degrees of preferential treatment.
8. Support multiple connectivity protocols
High variability in devices and device types that connect to an IoT platform necessitates a protocol agnostic approach to connectivity. An enterprise grade IoT platform is expected to ingest and process data riding on any transport and with any data structure.
9. Support switch off mode
This mode implies that the system works even if there is a loss in connectivity between devices and platforms. It may result in reduced functionality but wouldn’t cause complete disruption of system availability. Such a feature is made possible by services like Device Shadow which maintain the current and intended state of devices. Devices and gateways are also designed so that they can sustain operations for a long time without being connected to the backend platform.
10. No downtime
It essentially means high availability of close to say 99.99% for an IoT solution. Many cloud services follow SLAs of 99.95% or less and therefore to reach the four 9s availability, the overall design of the platforms requires ingenious design. Such highly fault tolerant systems must take care of disaster recovery by ensuring redundancy of each service and all data across availability zones and regions.
While it's important to create architecture principles, not following or considering these enterprise forces while defining them can create an anarchical state. This state results in an IT landscape becoming a ‘bazaar’ of untenable components and services that perform duplicate jobs and cross functions that are not best suited for an efficient and an effective IoT solution.
Architecture Principles need to be carefully carved out based on the factors that influence them. In most enterprises, these are governed by larger business objectives of an organization and specific value proposition of the project being built. Moreover, an existing Enterprise Architecture also influences the principles to abide by.