IoT can be an amazing enabler for your product, but it’s important to make sure you get the architecture right. Because IoT solutions involve so many complex, integrated components, a sound IoT architecture is a make-or-break part of product development. A successful IoT architecture addresses a mix of technical requirements, business implications, and delivery considerations. Your IoT architecture should provide a roadmap for reliable, secure data transport, as well as methods to manage and deploy your devices.
Begin at The Beginning
So, where do you begin? At the beginning, of course! The very first thing you should consider when creating your IoT architecture is the use case of your device. How your product will be used should guide how you define your architecture and whether your networking should be local or cloud-based. Is your application local, where your data can be processed at the edge of your network, close to the source? Maybe you want to walk around a factory floor and check all the smart sensors. You could accomplish this using Bluetooth and a mobile application on a smartphone.
But, if you had a light switch that is installed in someone’s home so they can turn lights on and off while they are away, then a local architecture doesn’t make sense. You’d need to design it for the Cloud, where data is gathered and processed in a centralized location, and all devices that need to access this data or use applications associated with it must first connect to the Cloud.
The question of whether your device architecture should be local or cloud-based – or a combination of the two – can only be answered by considering its application. You should also take analytics into account when answering that question. If you want to gather analytics from your device without sending out a field engineer, then you need to be thinking about architecting to the Cloud.
Hardware Matters in IoT Architecture
Evaluating your device hardware and protocol is another important part of planning your IoT architecture. In a typical IT environment, we send as much data as we want with few restrictions. But, the amount of data we can send in an IoT environment is often limited because of battery size, distance, or accessibility. You need to consider several different factors: What is your power source? How much data are you sending? How far are you sending the data?
For example, if you are using a sensor to test pH levels in a remote bog, you may only need to send small amounts of data – the pH level results – once a day or once a week. Because sensors are equipped with very small batteries, you would want to choose a low-power networking protocol like MQTT so you reduce your bandwidth and maximize the battery life.
Or if you are connecting millions of devices, you may need to reduce bandwidth just because of the sheer volume of data you are collecting. Before choosing your hardware architecture you should analyze the type of sensors/actuators, the communication interface, the amount of data to be captured, and the frequency of the data transportation.
Phone Home
Communication between your server and your device is also a vital part of your IoT architecture. Technically, your server does not have the ability to reach out to your IoT device. If you drop a robot in the Pacific Ocean, how does your server know how to communicate with it? Or maybe you have a home intrusion detection system set up behind your firewall? How does your server know how to get through the firewall? Like Steve Speilberg’s infamous E.T., your device must “phone home” to your server to check for operations and events that need to be carried out on the device. The server can then respond with data back to the device.
Part of your architecture should include how often your device will “phone home”. If you are collecting pH levels from a remote bog, it might be fine if your sensor checks in once a day or once a week. But if you are trying to turn on a light in your home, you wouldn’t want to wait a day or an hour for the device to check in with the server to turn on your light. How many devices you have and how often they are “phoning home” all impact the time it takes to push out a message as well as server and resource allocation. The cost of your device-server communication becomes part of your architecture.
Plays Well With Others
Your IoT architecture will also be impacted by whether you will be integrating with other devices, components or services. Do you need to integrate with Google Home, Apple Home Kit, Alexa or some industrial software? What types of integrations you are supporting will impact whether you need to be in the Cloud. Beyond the question of integration, you need to decide whether you will expose a public API. By making your API public, users can build their own applications to your device. This is where the early adopters live and it represents an opportunity to get feedback on how customers are really interested in using your device and may provide ideas for additional business opportunities.
Safe And Sound
We hear about it every day: security. You must address security when creating your IoT plan. Adding security to your device adds cost. You need to decide if your data needs to be encrypted across the network, at rest, or not at all. If you are collecting pH levels in a bog, you probably don’t want to chew up battery life encrypting your data. But if you are designing a wearable insulin pump for diabetes, encryption is going to be critical.
In addition to security on the device, you also need to think about protecting your data in the Cloud. For instance, many manufacturers put their MySQL database right on the public Internet, collecting data from all their devices which are secured with the same password. If someone cracks the password, they have access to all the data from all your devices. This is a solved problem: simply put your database behind a Web API that will provide user authentication.
Many other security issues also have been addressed and resolved. Don’t reinvent the wheel – approach these issues with existing systems, methodologies, and technologies, or find an experienced IoT solutions provider to do it for you. For more information on IoT security, check out our blog article “IoT Device Security a Challenge as Device Numbers Rise”.
Planning out your IoT architecture at the beginning of your project is essential for success. Take the time to do it right the first time. Changing an architecture that doesn’t work is like changing the foundation of a house; sometimes it can be done, but it’s not easy. Other times you may find that your hardware is all wrong for the features you want to deliver, and you must start all over again. It’s important to design a scalable, flexible architecture that meets not only today’s requirements but will allow you to add features in the future without starting again from ground zero.
