Nobody knew the Internet of Things (IoT) was so complicated!

At least three years into the Hype Cycle, the Internet of Things is still a hot, rapidly evolving space everyone wants to be a part of but few fully understand. Nobody knew the Internet of Things (IoT) could be so complicated! Ask one person his definition of IoT and see how many answers you get. Ask a group of people and the conversation quickly devolves into a version of the story we tell each year at Seder: five rabbis debate how many plagues afflicted the Egyptians when Moses parted the Red Sea (if only Manishevitz tasted better!).

But I digress.

The fact is the Internet of Things is not a thing in and of itself. It’s a loose set of frameworks we use to tackle many disparate problems, using technologies that are getting ever cheaper, smaller and more connected. But the way you implement IoT devices can be vastly different depending on whether you’re turning on your living room lights, monitoring ground moisture in a remote field, regulating the temperature in a 200,000 square foot facility or building driver-less cars.

The Numbers: It’s Going to Be Yuuuuugeeee!!!
Regardless, the hype is real and it’s getting everyone frothed up to do something.

• McKinsey sets market potential at up to $11B by 2025.
• Bain predicts that by 2020 annual revenues could exceed $470B for IoT vendors selling hardware, software and solutions.
• General Electric predicts investment in the Industrial Internet of Things (IIoT) is expected to top $60 trillion over the next 15 years.
• IHS forecasts the IoT market will grow from an installed base of 15.4 billion devices in 2015 to 30.7 billion devices in 2020 and 75.4 billion in 2025.

$60 TRILLION seems like a lot (I’m not saying it’s inaccurate), but now you understand why everyone’s so eager to get a seat at the table.

What also makes everyone want to get involved with IoT is that everyone IS already involved with IoT. IoT ownership is messier than more traditional technoloies. In fact, only one-third of IoT initiatives are owned by IT. This Techanalysis chart shows ownership for IoT initiatives are split almost equally between IT, LOB/Business Strategy and Facilities/Operations, Manufacturing. Many of the processes, products, and business procedures expected to benefit from IoT-driven intelligence and controls fall into these other departments. So it’s logical they want to be in charge of projects that impact them directly. But what we need to avoid is a mad rush to be the first group to take the lead. Sometimes speed is the enemy of a good plan.

So let’s do a little framing before we run to the Board of Directors with a project idea.

Think Nervous System, Not Network Architecture

Some are actually moving forward with real and impactful IoT projects. Many are still trying to get their arms around what IoT is and how it will benefit them. Some device management providers want you to view the IoT as another set of manageable devices that feed data through existing backend systems. But even this definition doesn’t really do it justice.

Yes, a business needs all the above things to formulate a complete solution, but even this does not ensure success. They are necessary components, but not sufficient for success. A better metaphor is the human nervous system (an idea borrowed from Sanjay Sharma at MIT). Here’s why.

IoT is about sensing and taking action.

The nervous system is amazing. Nerve receptors (sensors) all over our bodies let us know what’s going on in our environment. They provide tremendous amounts of data that we constantly process and respond to. Some of them are autonomic responses–like breathing—which don’t require much processing power to maintain. Some are learned reflexes—like when we pull back our hand from a hot pot on the stove. Still other responses require more nuanced judgment.

This is more akin to the basic architecture of IoT. We can place sensors anywhere and everywhere we need them. Sometimes we are simply collecting data to understand our environment. Other times we sense and perform an action (e.g. a moisture sensor turns on sprinklers because the ground is dry). Reflex actions should ideally happen in real time—a local controller must make those decisions and turn on those sprinklers. In IoT terms this kind of local controller/local network is known as the “Fog.” It’s like the Cloud but closer to the ground and less dense/capable.

Situations bent on improving decision-making or establishing root cause (that don’t need to be in real-time) are best pushed to the Cloud where there’s vastly more computing power (i.e. the brain).

Now our network diagram looks a little more like this.

Why do we need the Fog or the Cloud? Famously, the chip inside your mobile device is a million times more powerful than that in the Apollo spacecraft. But most IoT sensors are waaaaay less powerful than the devices we take for granted. You can’t afford to utilize billions of sensors that cost $500 each. From a cost perspective they need to be in the single digits or below. This means they usually sport a fixed or limited functionality, are hard to upgrade, and have extremely limited resources (computational power, connectivity and energy). These resource constraints come back to bite us in innumerable ways, which we’ll get to in a bit.

POCs vs. Scaling
One final thought: we often understand our processes pretty well (and luckily IoT is more about process than it is technology). But the technology is a mess. Often, you need components from several companies, you run into connectivity issues (boy, is this part a mess!) and you obsess over battery life. POCs are a critical first step before rushing headlong into a rollout.

But POCs can also provide the false positive that you found a solution. Think about a manufacturing company with two dozen plants, each with equipment from different manufacturers bought at different times. Different configurations. Different products that you produce with different materials. It’s the “Too Many Moving Parts” syndrome.

So the solution you implement at one site may not be the same one you roll out everywhere else. Start your POCs on solving narrow problems and work your way out. Try to validate a baseline solution. Identify where differences amongst sites exist and test the impacts of various solutions against those characteristics. Prior to the POC, be sure to also evaluate your solutions on key platforms to see how they perform in real-world conditions (hint: I’m sure everyone’s demos will go great, but as Mike Tyson said “Everyone has a plan before they hit in the mouth.” And IoT hits you in the mouth pretty often.).

More to come next month when we’ll talk about the ‘iron triangle’ of IoT device, connectivity, and security (ah, security).

Any IoT topics you want to specifically learn about? Let me know! Tweet me at @ggruber66.