Five Key IoT Strategies To Add To Your 2019 IoT Roadmap

Recently I have been focusing on Internet of Things (IoT) strategy to develop a secure IoT platform to streamline capability development from a collection of certified IoT sensors. The platform seeks to reduce the barriers to IoT innovation by providing end-customers or application developers access to a variety of pre-provisioned sensors for which sensor data can be visualized within the platform or used for custom application development via secure APIs. The following five strategies are suggested for consideration to ensure sustainability and security of IoT application development.

#1 - Develop IoT Capabilities Behind A Layer of Abstraction

If you are developing an IoT capability at this time, you should assume that your capability will consume data from sensors that have yet to be released and likewise, sensors you are currently testing with may no longer be available when your application goes live. Hence a best practice is to ensure that your IoT application accesses its sensor data through a secure IoT platform or hub. Including this recommended layer of abstraction improves the sustainability of your application by allowing for pluggable configuration of new sensors as they become available. Leveraging an IoT platform / hub as part of your IoT capability, enables you to keep up with the ever increasing rate of sensor innovation with less effort, as the IoT platform will allow you to configure or transform data from new sensors to be compatible with your existing application without the need to change the code.

#2 - Have A Strategy to Keep Your Data Private

It is no secret that everyone from large enterprises to start-ups that you have never heard of are chasing an IoT payday and one of the primary strategies to increase potential value from IoT activities is to have access to all sensor data. Consequently, the market offers many publicly hosted IoT platforms which provide data access, storage and analytics for your capabilities, but such platforms can also allow the hosting organization to mine your data for additional trends and insights to support their overall strategies. Hence my recommendation is to carefully review the terms, conditions and privacy policy of any public IoT platform that you are considering to ensure they are supportive of your overall business strategy. Additionally, consider if your IoT capability would benefit from a hybrid data access & persistence strategy. By such a strategy, you persist critical / sensitive data in a private environment / platform (which more than likely has a higher cost of operations), but then you leverage a lower cost public IoT platform for access / persistence of non-critical data. Determining such a hybrid strategy to split data between private / public platforms may complicate initial design & development of your capability; however, long-term it can ensure continued relevance & competitive advantage by ensuring you retain ownership of your most critical sensor data.

#3 - Ensure Your IoT Platform and Applications Enable Digital Twins

The high rate of innovation in the IoT space requires adoption of practices to enable virtualization at any level of the systems architecture – such virtualization of IoT capabilities is commonly referred to as creating a “digital twin” of your environment. As the name implies, a digital twin is a virtualized replication of your full environment or specific components in your environment that can be used for testing or development activities in a parallel to your live production environment. An example of how to put such virtualization into practice is suppose you have created a capability to visualize and trigger alerts based on data from water flow sensors to detect water main breaks. When a new water flow sensor becomes available, you should be able to provision a duplicate instance of your full environment (application, platform, data, and simulated data from existing sensors). Once this digital twin of your environment is provisioned, you can quickly test compatibility with the new flow sensor. In such scenarios, testing of new sensors requires virtualization of your current environment to avoid the risk to operations of testing in a live production environment. Lastly, a best practice to receive the full benefit from digital twins & virtualization is to seek to automate conformance testing and regression testing for IoT capabilities. With proper automation & integration in place between your IoT platform and your IoT application, conformance testing to confirm compatibility with a new sensor should require minimal or perhaps no manual effort.

#4 - Plan for a Wide Variety of Sensor Health & Network Connectivity

Continued innovation in network connectivity and IoT sensor capability is increasing the scope & complexity by which IoT capabilities and applications can consume sensor data. In many use cases, business value is not fully realized by limiting capability to a single quality of service. Consider a scenario where your IoT application optimizes irrigation control using low power wide area network (LPWAN) moisture sensors mounted near the ground. When initially deployed, each moisture sensor reports data six times daily (every 4 hours); however, over time sensors report data with less frequency due to low battery, failed data transmission, sensor destruction, etc. Hence the key strategy for consideration is for your IoT application to decide how to respond if the full dataset from a sensor is not received. For the irrigation example provided, I’ll suggest the application could continue to calibrate irrigation control but perhaps would warn that current calibration is based on an incomplete sensor data set which would trigger a recalibration of the system. In other use cases, such as autonomous driving, it may be appropriate for an application to stop or prevent device operation to avoid liability, if complete sensor data is not received. The IoT application development strategy to be mindful of in this scenario is that you should assume your IoT application will encounter scenarios where full sensor data is not received due to degrading sensor health and/or limited network connectivity – when such a scenario occurs, how should your application behave? While many IoT applications focus on development and testing of highly connected sensors on robust networks – ie: focusing on developing & testing in the “perfect” environment, scenarios with weakly connected sensors are becoming more common as technologies like LPWAN expand. Hence ensure that your IoT application development strategy considers scenarios where some limited sensor data could enable some limited capability.

#5 - Consider Scenarios Through the Full Lifecycle of Device Management

A key consideration for IoT capability and application development is to consider the full lifecycle of device management.

• The Beginning – How Will You Scale Provisioning - Let’s start at the beginning of the device lifecycle with sensor provisioning, where my suggestion is to keep asking yourself “How will this capability scale?” When you are starting out, manually provisioning ten sensors to transmit data to your IoT platform and application can enable initial development or demonstrate a proof of concept; however, when someone wants to deploy your application for their organization, how are you going to provision 10,000 sensors for installation across their facilities. Several strategies for consideration in this scenario include: pre-provisioning and pre-configuring sensors as part of supply chain activities when obtaining sensors from suppliers, or including capabilities to automate sensor provisioning using software, such as the ability for users to self-provision and activate a sensor by scanning the sensor ID information on the sensor itself or its packaging. A best practice to target if developing an IoT capability / application is that new sensors for your capability can be provisioned without any direct support from members of the development / operations team – aligning to this best practice will guide you to delegate provisioning to others, or to automate it with software.
• The Middle – How Do You Confirm Security of Sensors - The next key phase of the IoT device lifecycle is ensuring the integrity of device or sensor configuration when consuming data from a sensor. It is an IoT security best practice to confirm that a sensor’s configuration has not been tampered since it was provisioned whereby data shared could be compromised.  In this scenario, sensor configuration integrity can be insured using Blockchain. Similar to other applications of Blockchain within the supply chain context, encrypted configuration records are persisted to a Blockchain during provisioning. Later, applications accessing sensor data check configuration records for tampering at the time that data is consumed – this confirmation allows data to be rejected from sensors whose configuration has been modified. While it is possible for functionality to confirm sensor configuration integrity be included in individual IoT applications, this scenario is best supported by an IoT platform that would confirm configuration integrity of connected sensors before making data available for consumption via API calls to the IoT platform. Such IoT platform capabilities and architecture are recommended to ensure consistent verification of configuration integrity without the need to include verification checks in each IoT application developed.
• The End – What Happens When Your Application or Sensors are Gone - The last phase of the IoT device lifecycle that warrants consideration for application developers is sensor end-of-life. Consider how have you architected your application to respond if specific sensors stop reporting data or the sensors are no longer available. Given the rate of innovation and change within the IoT space, it is important to consider scenarios where an application outlives the sensors for which it was initially designed and likewise an application may be retired, yet the sensors that enabled the application still remain deployed and active. Both scenarios present unique IoT lifecycle considerations. For the case where the application outlives the sensors that provide data to enable it, the application should leverage a pluggable architecture or IoT platform that enables transformation of data from new sensors to allow for continued use of the application. In the scenario where sensors outlive the application for which they were deployed, consider if the remaining sensors create potential security risks to networks or other applications if they remain online. The mitigations for these end-of-life scenarios will vary based on use case, so my suggestion is to think through them proactively, and realize that everything you deploy to enable your IoT solution (applications, platforms and sensors) will eventually reach an end-of-life scenario and you may be liable if components of your solution remain on-line and are used for unintended purposes by others.

Closing Thoughts

Sensor innovation, edge computing, and IoT platform development are reducing the barriers to developing IoT capabilities and applications. If you are building an IoT capability or application, you don’t need to do everything on your own; rather, you can streamline your development leveraging building blocks, products platforms, and partners focusing in the space. Hence don’t miss the opportunity to employ the lean principle of “maximizing the amount of work not done” whereby applying these strategies and leveraging available IoT platforms and partners can provide a foundation for you to focus on developing IoT applications for your customer needs while leveraging available services & platforms to provide necessary IoT infrastructure.