While the average phone in America is quite powerful, in emerging markets devices are still, in many ways, limited. Even so, the same software runs across it all. Now IoT devices, which are about five to seven years behind smartphones, have a similar trajectory, but their diversity in CPUs and platforms are even greater. Most of the devices used for IoT development are small, low powered, and have limited batteries. Lower computational power is the tradeoff here. To deliver the connectivity and form-factor needed to succeed in the IoT business, your developers have to relearn many performance-enhancing techniques, while coming to terms with the fact that the latest tools which work exceptionally well on a development machine will most probably not run well in constrained environments.
From prototype to production:
With all the Tutorials out there and the number of platforms available, it becomes quite possible for almost anyone to build a quick prototype in a couple of hours. But you see, a prototype is merely the proof of concept, it isn't the proof of a product. Bringing your prototype to a place where it can be commercialized takes a lot of effort, planning, and expertise. You will have to make a host of decisions about hardware, which will eventually drive decisions about software.
IoT hardware comes in a huge variety of formats. The Arduino and Raspberry Pi, two of the most common platforms are completely different platforms, and you cannot architect your software and hardware the same way for them. The impact of higher-level decisions like which OS to adopt will prove to be lesser than the choice of your platform. Your critical first step is choosing the right one for your project.
An IoT initiative is almost like starting a new startup in itself, where cost control becomes paramount for success. Often the hardware you used in your prototype won't be the one in your final product due to cost issues. You might have made use of Raspberry Pi for your prototype since they are fast and easy to get begin with, but they can get quite expensive and could even be more powerful than you need. Even differences in component costs which seem trivial initially when you’re working on your prototype add up to a significant amount when you move into full production.
So, how to get ready for the big time? How to build a server that can handle twenty-five thousand devices talking to it? Your software architecture when you only had one prototype connected was entirely different, and chances are, that code won't scale up to a production environment. How will you handle the messaging between those devices? Will you employ a cloud-based solution? You have probably not put too much thought into these and many other questions when you were working on a prototype. However, the earlier you answer these questions in your productization planning, the better.
Now, when you're working with small battery-powered devices, every electron is precious, and power constraints must inform all decisions you make regarding components. Your power budget could be driven by size, cost or weight restrictions. Given a specific power budget, how will allocate it judiciously? For instance, if you need to access the network a lot, it could mean trade-offs for the type of display or the speed of the CPU you choose. On the other hand, if it's essential to have a power-hungry display, you might have to access the network, in short, offload certain tasks to a server or infrequent bursts to save battery power.
While working on a prototype, you most likely didn’t put too much thought into the security aspect of things. But now you're working on a commercial product, and people will try to hack it. At the least, the consequences of security flaws in your IoT product will be as huge as those in a typical software. Imagine a smart doorbell allowing entry to intruders, or think of a smart doorbell that would let intruders come in or vehicles which can be remotely controlled. Don't underestimate security threats. A high-profile breach will bring your company to its knees overnight.
When building an IoT solution, it becomes easy to overlook critical commercialization decisions. But you see, the product you're working on will deliver a lot of value to your users, only if you build it in a way that is scalable, flexible, and secure. We understand that managing the transition from something which works on a lab bench to a functioning IoT product is tricky. However, recognizing the technical gaps between conventional and IoT capabilities is the right place to start and from there you can take it one step at a time.