10 Tips For Successful IoT Projects
Building hardware and writing software for IoT is the same as doing so for any sort of system. It requires a fair bit of good design practice, as well as common sense. Here are 10 tips to help you on the road to getting IoT right for users and IT.
![](https://eu-images.contentstack.com/v3/assets/blt69509c9116440be8/blt1db896ad9c736d31/64cb42e1e717e6b6108bc572/Image_1.jpg?width=700&auto=webp&quality=80&disable=upscale)
Ahh, the Internet of Things. Whether you're talking about the Internet of Consumer Things (wearables, connected appliances, home control, etc.) or the Internet of Industrial Things (process control, predictive fleet maintenance, etc.) there's no question that a network of connected devices and processes is a huge piece of computing in 2016.
Unfortunately, one of the aspects of the IoT that hits the news most often is just how bad some of the hardware and software designs can be. From devices that stop functioning to systems that are horribly insecure, IoT failures have been as notable as great IoT successes.
If you want your IoT application to be noticed for success instead of failure what do you need to do?
There's an extent to which building hardware and writing software for IoT is the same as doing so for any sort of system. "Build hardware that doesn't break" works as good advice for lots of different circumstances. With that in mind, though, there are some things a design team can do to help vastly increase the chances that an IoT application will succeed.
[See 8 IoT Operating Systems Powering the Future.]
The tips that follow are taken from lots of different sources, ranging from conversations with IoT engineers to my own experience as a manager of programmers and engineers.
These tips aren't specific to any hardware architecture or programming language, and they're not really specific to any particular corner of the IoT. They lean heavily on good design practice and common sense, and I won't make any snarky comments about the scarcity of either when it comes to the IoT.
Say what you will about the consumer side of things, the IoT is a critical part of modern manufacturing, agriculture, transportation, resource extraction, and critical infrastructure management. It's important to get it right.
The community here at InformationWeek has proven to be full of hard-earned wisdom when it comes to software development. What do you think of these tips? What tips would you offer?
There's a lot of IoT development yet to come. Let's hope that as much of it as possible is recognized for all the right reasons.
Here's a shocking idea: Just because you can put a sensor or controller in something doesn't mean you should. Before you go off instrumenting everything you can get your hands on you should know precisely why you want data from that device or how you're going to use the device to control a process.
Once you know why a component should be connected to the IoT then you can focus your design and development efforts. Without focus, you're likely to install intelligent components that end up restricting your ability to do what you ultimately want and provide a security vulnerability that is far too easy to exploit. So before you begin any development, sit down with the rest of the team and ask some version of the critical question: "Is this processor really necessary?"
Once you've decided that a particular thing needs to be on the internet, it's time to ask whether you want to use the thing to gather data, to control a process, or a bit of both. The answer to that question will be the basis of the decisions and development efforts to follow.
Sometimes it's easy to decide that you only want to gather data -- there are some pieces of equipment where no meaningful automated control function is possible. There are many others, though, where the decision gets much murkier. If you're gathering a lot of data, do you want to store it on the device until downloaded or stream it to the internet?
Do you want to do some processing and compression while the data is still on the device, or just get data off the device as rapidly as possible? These questions will have an impact on how much processing is necessary -- at which point you start cascading decisions into areas like batteries and device longevity. These can be complicated discussions but they all start with what kind of electronics you'll put into place.
Enterprise workstations tend to be on a four- or five-year replacement schedule. Enterprise servers, network components, and storage devices are generally on a regular refresh cycle, as well. What do you think the refresh cycle will be on your IoT devices? The answer matters because, for many IoT devices, the fact is that they won't be replaced until they wear out or the system in which they live is replaced.
When you know that a piece of equipment will be replaced every few years, you know that the technology will be updated and any huge system software updates applied in the new hardware.
When you don't know the refresh cycle, then the hardware decision you make could be in the field for years or decades, and the operating software in place for the same amount of time. Designing and developing for a long, but undefined, time requires a rigorous process. Make sure yours is up to the challenge.
We just talked about the life span of the IoT device. Now, what about the life span of the data from that device? Do you know how you're going to use it? All of it? Do you know what you're going to do with it after the immediate use has passed? Your answers to these questions will have an impact on everything from your data storage infrastructure to the language in your user documentation.
We are fortunately well past the age of grabbing all the data possible and holding onto it forever. There are legal, financial, and marketing reasons to limit the data gathered and to have a clear policy for how long it will be kept. You should decide early how you're going to treat the data because this is the foundation issue for the architecture decisions that will follow.
It's easy to get wrapped up in the IoT end points. That's where most of the sexy hardware lives and that's the side of the IoT that most users see. If you're building IoT applications for industry and commerce, though, the backend processing will be at least as important as anything you're going to put into the field.
When you build end-to-end, you'll be looking at the field endpoint, the communications, the intermediate data processing, and the backend analysis as a whole, rather than assuming that the real job is one part and other pieces are incidental. For an IoT application to work properly, it does have to be developed as a whole. Applications developed piecemeal ultimately show themselves in poor performance and highly suspect security.
If you're moving data from the field to a central processing facility for analysis then you should seriously consider staging the data and performing intermediate processing along the way. By doing the intermediate processing you can minimize the data volume that has to be moved from one point to another, apply control commands closer to the control point, and eliminate many of the questions about security for personal information that can occur when you're just picking up vast quantities of data and shoving them down the pipe to the data center.
There are now a variety of protocols and open source frameworks that will help you build data aggregation and streaming into your applications. Take advantage of these and you'll find that you've boosted performance and removed a lot of security problems. Those are two good things for every IoT application.
Do you know how your IoT application will communicate with the internet? It's not a small question because the answer will stem from where and how your application is used and the technology that's available in those places. WiFi is good, but which generation? If your devices are going to be mobile, should you assume that they'll be away from WiFi and will need cellular data possibilities? What if your devices will be far afield? Do you need to plan on a satellite link for your application?
The answer to the comms question won't have an impact on the hardware designers alone. The more expensive the network, the smaller the data you want to move from place to place. The less certain the connection, the more you'll want to have processing and control capabilities at the endpoint. If you decide you'll wait and just tack on a network connection of some sort at the end of the development process, you'll likely find that you've developed yourself into a corner -- one that it will take serious work and revision to escape.
One of the communications technologies that deserves more attention is the mesh network. In a mesh, each node on the IoT application can talk to the others, and each can serve as a communications repeater to help move critical information from place to place along the most efficient and effective route. You have to think about the mesh early enough to choose the right radios, the right processors, and the right network protocols, but when you do you open up a world of possibilities for extending the least expensive networks much farther into the field.
There's an old chestnut in testing: Anyone who says his or her application is foolproof hasn't tested it with a really foolish user. This is an area in which agile discipline can be useful because you want to test early, test completely, and test often. Remember that you're creating applications that could control devices that have human safety implications. Remember that you're creating applications that may not be able to be updated once they're in the field.
The IoT is not an opportunity to use the method that's frequently employed in mobile apps, in which you use your first customers as your beta testers. Make sure that you have tested your application from end to end before you think of sending it into the field. The first step in creating a successful IoT application is creating an IoT application that works every time, in every situation, when it gets into the field.
If you want to make your testing regimen less painful, then build applications that contain quality software. I'm not talking about feel-good software development. There are standards, processes, frameworks, and regimens to choose from, any of which quantify what quality means when applied to software.
Pick the standards and processes that work for you and your organization, but pick something so that you know that you're building quality software. Make sure that quality isn't something that you apply after testing has proven that you failed. With the right processes, testing is much more a function of confirming that you did things right than showing what you did wrong.
The IoT is an unforgiving place. Make sure that your application is right when you set it free out there.
So there they are, 10 tips for building a successful IoT application. Are you ready to put a successful IoT application in the field? Do you think that my tips are enough? Let me know -- I've got some IoT ideas that I'm looking forward to trying and I'd love your input on the best practices for doing that.
If you want to make your testing regimen less painful, then build applications that contain quality software. I'm not talking about feel-good software development. There are standards, processes, frameworks, and regimens to choose from, any of which quantify what quality means when applied to software.
Pick the standards and processes that work for you and your organization, but pick something so that you know that you're building quality software. Make sure that quality isn't something that you apply after testing has proven that you failed. With the right processes, testing is much more a function of confirming that you did things right than showing what you did wrong.
The IoT is an unforgiving place. Make sure that your application is right when you set it free out there.
So there they are, 10 tips for building a successful IoT application. Are you ready to put a successful IoT application in the field? Do you think that my tips are enough? Let me know -- I've got some IoT ideas that I'm looking forward to trying and I'd love your input on the best practices for doing that.
-
About the Author(s)
You May Also Like