In this article

Recently, I've been focusing on strategies to develop a secure Internet of Things (IoT) platform to streamline application development based on certified IoT sensors. The platform seeks to reduce barriers to IoT application development by providing end-users and/or application developers access to a variety of pre-provisioned sensors from which data can be pulled and visualized within the platform or used for custom application development via secure APIs.

To ensure the sustainability and security of IoT application development, I recommend considering the following five key strategies:

key strategies for sustainable iot applications

1: Develop IoT capabilities behind a layer of abstraction

As you are developing an IoT capability, you should assume that your capability will consume data from sensors that have yet to be released and that the sensors you're currently testing with may no longer be available when your application goes live. Hence, it's a best practice 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. It also helps you keep up with the ever-increasing rate of sensor innovation with less effort, as an IoT platform allows you to configure or transform data from new sensors to be compatible with your existing application without the need to change the code.

Develop IoT capabilities behind a layer of abstraction

2: Have a strategy to keep your data private

It's no secret that everyone—from large enterprises to start-ups you've never heard of—is chasing an IoT payday. One of the primary strategies to increasing the potential value from IoT activities is to have access to all sensor data. As a result, the market offers many publicly hosted IoT platforms that provide data access, storage and analytics for your applications. Such platforms also likely allow the hosting organization to mine your data for additional trends and insights to support their overall strategies.

My recommendation is to carefully review the terms, conditions and privacy policy of any public IoT platform you're considering to make sure it supports your overall business strategy.

You should also consider whether your IoT capability would benefit from a hybrid data access and persistence strategy. This type of strategy allows critical or sensitive data to persist in a private environment or platform.

Establishing a hybrid strategy to split data between private and public platforms may complicate initial development of your capability; however, this strategy can help ensure continued relevance and competitive advantage in the long term by helping you retain ownership of your most critical sensor data.

strategy to keep your data private

3: Ensure your IoT platform and applications enable digital twins

The high rate of innovation in the IoT space requires adopting 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 of specific components in your environment (sensors, applications, etc.). Once created, the digital twin can be used for testing or development activities in parallel to your live production environment.

For example: Suppose you've 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 virtual sensors). Once this digital twin of your environment is provisioned, you can quickly test compatibility with the new flow sensor. In this type of scenario, virtualizing your current environment is done to avoid the risks of testing in a live production environment.

To receive the full benefit from digital twins and virtualization, a best practice is to automate conformance testing and regression testing for IoT capabilities. With the proper automation and integration in place between your IoT platform and IoT applications, conformance testing to confirm compatibility with new sensors should require minimal (or perhaps no) manual effort.

IoT platform and applications enable digital twins

4: Plan for a wide variety of sensor health and network connectivity

Innovation in network connectivity and IoT sensor capability is increasing the scope and complexity by which IoT applications can consume sensor data. In many use cases, business value can be increased through the ability to consume data from a variety of qualities 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 four hours). Over time, we know that sensors will report data with less frequency due to low battery, failed data transmission, sensor destruction, etc. Therefore, you need to consider how your IoT application responds when it does not receive a full dataset from a sensor.

For the irrigation example above, I might suggest allowing the application to continue calibrating irrigation control while at the same time warning that current calibration is based on an incomplete sensor data set and triggering a recalibration of the system or perhaps even notifying support to replace failed sensors. In other use cases where complete sensor data is not received, such as autonomous driving, it may be more appropriate for an application to stop or prevent device operation to avoid liability.

The general IoT application development strategy to be mindful of is this: 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 this occurs, be proactive to think and design how your application should behave.

While many IoT applications focus on development and testing highly connected sensors on robust networks (i.e., in "perfect" environments), test scenarios involving weakly connected sensors are becoming more common, especially as technologies like LPWAN expand. Hence, your IoT application development strategy should take into consideration these types of real-world scenarios, too.

Plan for a wide variety of sensor health and network connectivity

5: Consider scenarios through the full lifecycle of device management

Another key strategy for IoT capability and application development is to contemplate the full lifecycle of device management—from beginning to middle to end.

full lifecycle of device management

Beginning: How will you scale provisioning?

Let's start at the beginning of the device lifecycle with sensor provisioning. At this stage, my suggestion is to keep asking yourself "How will this capability scale?" When you're starting out, manually provisioning 10 sensors to transmit data to your IoT application can enable initial application development. But when someone wants to deploy your application for their enterprise organization, how will you provision 10,000 sensors for installation across their facilities?

Two strategies to consider in this scenario include: (1) pre-provisioning and pre-configuring sensors as part of supply chain activities when obtaining sensors from suppliers, or (2) including capabilities to automate sensor provisioning using software.

When beginning to develop an IoT application, a best practice to keep in mind is that new sensors can be provisioned without any direct support from members of the development/operations team. Aligning to this best practice will lead you to delegate provisioning to others, or to automate it with software.

Middle: How do you confirm sensor security?

Once sensors are online, it's important to confirm that device or sensor configuration hasn't been compromised. In this scenario, sensor configuration integrity can be verified using blockchain technology. Similar to other blockchain applications within the supply chain context, encrypted configuration records are persisted to a blockchain during provisioning. Later, applications accessing sensor data check those records for tampering at the time data is consumed; this confirmation allows data to be rejected from sensors whose configuration has been modified.

While it's possible for individual IoT applications to confirm sensor configuration integrity, 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 architecture is recommended to ensure consistent verification of configuration integrity without the need to include verification checks in each IoT application developed.

End: What happens when your application or sensors are gone?

The last phase of the IoT device lifecycle is sensor end of life. 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's important to consider two scenarios: One where an application outlives the sensors for which it was initially designed, and one where an application is retired, yet the sensors that enabled it remain deployed and active. Both scenarios present unique IoT lifecycle considerations.

As a best practice, when an application outlives the sensors that provide the 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 its continued use.

Conversely, when sensors outlive the application for which they were deployed, the best practice is to consider whether the remaining sensors create any potential security risks to networks or other applications if they remained online.

The mitigations for these two end-of-life scenarios will necessarily vary based on use case.

My recommendation is to think through each scenario proactively with the understanding that everything you deploy to enable your IoT solution (applications, platforms and sensors) will eventually reach an end-of-life scenario where you may be liable should components of your solution remain online 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 applications. If you're building an IoT application, you don't need to do everything on your own. Rather, you can streamline your IoT application development by leveraging building blocks, platforms and strategic partners focused on the space.

Don't miss an opportunity to employ the lean principle of "maximizing the amount of work not done." Considering the five key strategies above while building your IoT application will guide you to focus on your customer's needs while leveraging available services and IoT platforms to provide the necessary infrastructure.