IoT is like the wild, wild west with leading innovators and startups flocking to the opportunity. This is both good and bad. Intense competition in IoT has progressed the quality of some product offerings, but has also created significant ‘noise.’ Cutting through this noise, let’s focus on one of the many ways to gain the required foundation for building and managing connected products: selecting an IoT platform.
The right foundation can greatly improve time to market and help you build your IoT application on a tried and tested platform without re-inventing the wheel. The platform may include stack design for connectivity protocols such as Wi-Fi or Bluetooth, network services, failsafe bootloaders, data transfer security, device security, cloud service APIs, file systems, RTOS and so forth to help skirt tedious and complex design.
Developing networking services or a TCP stack is not going to set your product apart from the others! The IoT stack is no insignificant beast. If your product is a smart home security system, your expertise is the code that differentiates your product from the rest, not the operating system stack on which it’s built. In any business, it’s important to stick to your core competencies, which is why IoT platforms exist.
During your search for the right IoT platform, consider these important tips.
- Consider your business strategy.
Don’t get caught up in the moment; connected products have a life after the sale. Just like your cell phone, your connected product needs to be securely updated for new features and bug fixes (that you lovingly call feature revisions). Connected products include benefits beyond their core functionality just as phone apps provide value (and revenue) beyond making phone calls. But, do you have a plan for these extended use cases?
Here are some business strategy questions to drive your IoT Platform decision:
- How will we progressively update the product’s security to thwart hacks while protecting the brand that took us years to build?
- How will our product managers and marketers assess the product’s performance beyond revenue stats and how can our product be the real-time source of that data?
- What will it take to retroactively implement features that address the questions above? It is significantly more difficult and less secure to do it later than to build them into the product from the start, so what do we need now to ensure we don’t have to backtrack?
- How will we obtain recurring revenue from the deployed products to cover the operating costs throughout the entire product lifecycle?
Of note, these questions should be addressed prior to the IoT development stage to avoid duplicate work.
- Consider security; it’s not cliché, I promise.
A 2016 blog by Brian Buntz on the Internet of Things Institute website stated that the top two reasons people aren’t embracing the IoT are because of data privacy concerns and security concerns. IoT platforms have very different levels and layers of security. Security is not and cannot be a stagnant fixture; security must progress faster than hackers can counter. This means that both the device and the data must be able to be continually updated with security that is built into the product’s fabric from day one. If you’ve added a new layer of security after the device was built, then you have not only added cost to the product, but you have provided a security hole that you are probably now fixing because – YOU WERE HACKED!
A product needs protecting during three key stages:
- During production in the factory. This is about ensuring your firmware and IP don’t escape. Hardware is somewhat easy to re-engineer since it’s a might be a copy/paste scenario, but ensuring your software is encrypted and enabled for only one single device in a fleet of products ensures your secret sauce doesn’t hit the grey market. A policy of per device enablement is also the foundation of post deployment feature licensing (see my blog on What Tesla and Apple got right)
- When the product is not active. This is all about securing the “data-at-rest,” such as when the product is sitting in your house, but is not actively being used.
- When the product is active and data is flowing. This is often called “data-in-motion,” and must be secure from the product to every cloud service to which it connects.
We get it, it’s painful and complex, but everyone reading this article can name at least one newsworthy article about a product hack. And what is it you remember most? Probably not the technical details of the hack, but you remember the brand that was hacked. Saving money and time during development by skimping on security is not worth jeopardizing years of hard work establishing a strong, trusted brand name.
- Consider the platform architecture.
IoT platforms can use an agent or an IoT-focused operating system. Cloud services vendors typically offer an agent approach since they want you to use their cloud service, whether it’s for cloud storage, analytics, or whatnot. They typically have a pretty nice cloud setup, but unfortunately this model can inherently create vendor lock-in and could generate security holes through lack of design focus at other points in the stack. In contrast, an IoT operating system will typically include security built from the ground up, reducing the opportunity for security holes. Operating systems tend to be better solutions for future proofing as its vendor is focused on the complete solution. Consider your phone or your laptop, security updates are continually fed to it, hooks are included to all your favorite cloud vendors, and moving from one vendor to another is a seamless process. The operating system approach offers flexibility far into the future no matter what path your company chooses to go.
- Prototyping CoGs vs. lean production CoGs.
Makers everywhere enjoy the benefits of Raspberry Pi and Arduino type tools but this approach is often not focused enough to provide minimal CoGs and/or power characteristics for production-ready, MVP (Minimum Viable Product) products. Using this fast but heavy approach is a fantastic way of enabling company divisions such as marketing or engineering to convince other company divisions of product viability. However, it’s important to recognize that these are not long-term solutions since they don’t meet market requirements in terms of security, scale, and CoGs. It’s very important for upper management of companies to understand the goal of the marketing/engineering teams but then fund them to get onto a focused platform sooner than later.
- Consider (and ensure) your freedom.
Determine the level of product freedom you want and need during hardware and cloud selection, development, and management, and throughout your product’s, portfolio’s, and company’s lifecycle. Will you ever need cloud services from several cloud vendors? Will you want to use Amazon AWS for data storage alongside Tableau for data analysis now or in the future? If so, will your IoT platform enable that at product launch and down the road? Platforms should have built-in APIs unless you plan on developing the integrations yourself.
You may also require hardware flexibility for multiple product lines. Some IoT platforms allow for this while others do not. Consider this in your IoT platform decision. Lack of flexibility may be fine if you only develop a single product, but it is not the right solution if you expand into a product family. For example, Adobe programs don’t care if Windows runs on Intel or AMD in the same way you wouldn’t care which hardware you were using if it worked and had a platform that provided the freedom to choose.
These five tips will help you think about how to select an IoT platform and leave options open for future connected product decisions. A key takeaway is that connected products are really about their benefit once the product is in market, but these benefits are only possible, or more readily possible, if the right steps are taken from day one.
To discover more tips or ask questions, we want to hear from you at https://www.zentri.com/contact-us/.
By: Julie Mullins