I generally find that most IoT discussions I’ve had with customers start with a high degree of emotion. Sometimes it’s about the possibility of amazing things that could be. Sometimes it’s fear that that a big opportunity is being missed. Sometimes it’s just general confusion around the technology. These patterns are pretty consistent in most verticals I’ve looked at. Funny enough, I find myself looking at certain processes that companies are running–and have been running for decades–that could very easily be called IoT… What I’ve found, regardless of the vertical, is that there are typically 4 types of IoT scenarios. Let me propose this taxonomy:
- M2A -> Machine to Analytic -> When a “Thing” or “Machine” needs to be monitored, it typically requires taking a look at sensor information. For example, in Oil & Gas, you would monitor the pressure of a well by reading the sensors of parts that regulate pressure. In automotive—let’s take race cars–you would monitor the engine temperature and status of electrical equipment such as lights. There are many scenarios where you need real-time monitoring of a device. I would even argue that the “Find My Phone” app for an iphone is a simple version of this. The thing is the phone and the analytic is a map that tells you where your phone is. This doesn’t require storing large amounts of data in Hadoop or looking back at data. The value is seeing what’s going on now. This could even be things like Dropcam where the machine is a video camera and the analytic is a “screen” for viewing a video. Lots of home security applications here. Also, there are modern analytical use cases leveraging predictive for fault tolerance or predictive maintenance, but you get the idea that it could be operational analytics to see what’s going on now or predictive analytics to predict future pattern.
- M2M -> Machine to Machine -> This is the scenario people talk about the most. Imagine your alarm clock going off and it triggering your coffee maker and toaster to get started making breakfast. Very cool! Very consumer oriented. However, this is not new. In reality, Machines have been talking to each other (without human intervention) for decades. In manufacturing-back in the 1980s– there was always a conveyor belt and a mechanical arm. If the mechanical arm broke, the conveyor belt stopped. If the belt broke, the arm stopped. So there you go – a machine to machine scenario. It wasn’t using the internet, but does anyone care? This was two machines talking to each other. What’s different now, with the introduction of the internet and some standardization, is that the type and amount of data you can collect is utterly enriched and it is much cheaper for two machines to talk to each other, which makes the technology cheap enough for consumer scenarios (like the alarm clock/toaster scenario). Cheaper is a result of adoption/scale as well as Internet connectivity. To put this into perspective I’ll ask the question you’ve all heard before: “if a tree falls in a forest and no one is there to hear it, does it make any sound?”. The fact that two machines talked in the past was limited to those two machines and possibly the operators on the shop floor. Now, everyone from the floor operator to the business executive can be made aware of the event (possibly with different alert levels) and suitably adapt their operations and processes.
- M2D -> Machine to Data Lake -> This one, I believe, is where most people go with IoT. They believe that machines are collecting a ton of data and if they don’t capture and store that data, they won’t be able to derive value in the future because they missed collecting all of it. Sometimes the idea and value of capturing the data is well understood up front, but most often, I find that people don’t identify the value of capturing information up front and therefore, spend a ton of time/money building out data lakes to look for future value. It’s a “fear driven” approach. I do find that a lot of folks who buy Hadoop do this for their IoT driven Big Data Scenario. Then they unleash data scientists and try to find the magic value. Usually, something meaningful can be derived, but it takes time.
- M2P -> Machine to Process -> The last scenario, where I believe there is a ton of value, is when machines can communicate directly with business processes and be part of that process. What if your washing machine broke and could trigger a warranty claim or a service technician call if you’re not in warranty? 9 times out of 10, the “process side” of this is already handled in an SAP system. The question is connecting the machine to generate the business process action.
Now some IoT scenarios may have an element of multiple categories. For example, you may want to do real-time analytics off a car engine (M2A), as well as store the data (M2D) to look for maintenance failure patterns over time, as well as trigger a service appointment if the engine fails (M2P), and finally display a light on the car dashboard that the engine died (M2M). So, some scenarios may only be categorized via one of the above taxonomies, but sometimes, a scenario will involve multiple approaches.
What this taxonomy allows you to do is build reference architectures of technology to solve these IoT problems. Typically, an M2A scenario involves connector/sensor monitoring and leverages Complex Event Processing (CEP) technology for streams and data visualization technologies from that stream (things like Panopticon). However, the architecture for an M2M scenario won’t typically involve analytics, but instead will include a set of CEP rules for what to send to what machine. A M2D scenario will typically involve some Hadoop + R + HANA, and a machine to process scenario will involve API management on connecting to business processes.
It is also important to understand that IoT doesn’t always mean “Big Data storage”. Scenarios 1, 2, and 4 (M2A, M2M, and M2P respectively) actually do not require storing large amounts of data, while Scenario 3 (M2D) does. So don’t think you need to buy a big Hadoop cluster just to get started with IoT. That isn’t the case. That said, an interesting perspective to consider around ensuring Big Data Capabilities are available to support IoT use cases is described in this blog: http://radar.oreilly.com/2015/01/the-internet-of-things-has-four-big-data-problems.html
Also, what I’m not including here is other big data scenarios, such as weblog analytics where the “Machine” is a computer—I’m leaving weblog scraping out of this taxonomy. Again, a matter of perspective.
What I’ve generally found is that this type of taxonomy allows you to categorize your scenario across almost any vertical, and a reference technical architecture can be re-used. This makes the applicability of IoT much simpler to understand in terms of how to actually get scenarios implemented. As well, it provides a framework for understanding the types of IoT problems that technology can solve.
Finally, it is important to understand that not all machines are created equal. There’s a big difference between machines built decades ago and a modern internet connected machine now. I’ll be digging into that in my next blog.
VN:F [1.9.22_1171]A Simple IoT Taxonomy --Part 1,