Share this Post
You know the Internet of Things (IoT) is advancing in the marketplace, enabling an industry-wide shift from products to real-time services. Envisioning an IoT application for your business enterprise is easy, building it, on the other hand, is a far different exercise. You wish it was as easy as throwing money at the problem.
IoT was built to solve real-world problems. It’s messy. Typical IoT solutions exist at the edge, where Operational Technology (OT) problems reside. The initial challenge is to build the IoT application into a broader ecosystem, instead of reinforcing a siloed approach to data.
Framework for Building an IoT Application
A simple IoT framework has been proposed to help Product Managers tackle the complexity of building IoT applications.
“Product Management for an Internet of Things product can be very daunting and confusing . . . because IoT products are more complex . . . you need to consider the complexity of five layers of technology: device hardware, device software, communications, cloud platform, and cloud applications.
In summary, the five layers can be described as follows:
- Device Hardware - Devices constitute the “things” in the Internet of Things. They act as the interface between the real and digital worlds.
- Device software - Device software is the part that turns the device hardware into a “smart device”. This part of the IoT technology stack enables the concept of “software-defined hardware”, meaning that a particular hardware device can serve multiple applications depending on the embedded software it is running.
- Communications - Communications refer to all the different ways your device will exchange information with the rest of the world. This includes both physical networks and the protocols you will use.
- Cloud Platform - The cloud platform is the backbone of your IoT solution. Your infrastructure will serve as the platform for key areas such as data collection and management, analytics, and cloud APIs.
- Cloud Applications - This is the part of the stack that is most easily understood by Product teams and Executives. Your end-user applications are the part of the system that your customer will see and interact with. These applications will most likely be web-based.
The Bifurcated Market Problem - Partial Familiarity
In the five-layer proposed framework, the two layers to the right (Cloud Platform and Cloud Applications) represent the familiar territory of SaaS Application developers. Domain expertise within these two layers is widely available as enterprises roll out cloud-based Application Services.
Much less familiar today are the three layers to the left (Device Hardware, Device Software, and Communications), which represent the focus of much IoT discussion today. Early players in the IoT phenomena focused on IoT device hardware that could capture data from sensors at the edge. An early explosion of IoT products “littered” the marketplace as companies sought to fill every market segment with uniquely-defined IoT solution. The uptake of those solutions was mixed at best.
This bifurcated market problem has continued to this day. SaaS Application development leads the way with familiarity, while IoT device hardware/software/communication remains a relative mystery.
Domain Expertise Merged with IoT Device Development?
SaaS application development inherently embodies domain expertise. Analytics, for example, represents the institutional knowledge of the enterprise in deriving informational insights from IoT data. For energy efficiency, subject matter experts (SMEs) would have assembled efficiency calculation methodologies or KPIs that would indicate the relative efficiency of HVAC equipment or buildings. In a sense, their subject matter expertise can represent the value-added portion of an IoT Application built on real-time data.
The assumed complexity of building an IoT application is predicated on the notion of merging areas of domain expertise (SaaS Application development) with areas outside of an organization’s core competency (IoT device development). For example, would a construction company, insurance company, energy service company, mechanical service contractor, etc. have expertise in or care about the development details of wireless communication protocols and networking? Unlikely.
Therein lies one of the main obstacles hindering the advance of IoT application development. Any insistence on merging the competencies of two different technology domains would saddle the IoT application development with the relative immaturity of organizations operating outside of their core competency.
Merge or don’t merge?
Conclusion
Building an IoT application is complex if an enterprise is responsible for all five layers of the proposed IoT framework. This need not be. Next week, we’ll examine a bifurcated development model that accelerates the rate at which IoT application development can proceed.