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.
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:
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.
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?
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.