Some Background on IoT
We’ll first set a little bit of background on the subject and what’s happening in the IoT space. And then I want to get into some real examples of how these things are actually developing and working.
You already know about graphs of people and social networks, but there’s also massive graphs around things, devices and machine-to-machine relationships.
This reality is happening because chips are getting cheaper and power requirements are going down. Now it’s easy to have embedded intelligence into almost anything. (I think when we get to the stage where toothbrushes connect to the Internet, probably that’s about as far as it’s going to go.)
We’re also now acutely aware of the value of connectivity. Probably the cloud has done more than any other single thing to produce the mindset that connectivity equals value. And therefore one way or another, we are all Internet of Things users.
Uber is an example of an Internet of Things smart service. It knows where you are; it knows where the cab is; and it knows all of that information within a real-time process.
Every day we’re all using smart services like Uber, so a connectivity model is the Internet of Everything. What we’re adding to this model is Things, and today’s challenge is to use this IoT data to create valuable processes that we couldn’t have created before.
These efforts are all centered around relationships, and whether you diagram an IoT application or a graph, the pictorial representations look pretty much the same.
An IoT Example: Smart Buildings
A good example of a smart building is in Amsterdam, and it’s called the Edge which is Deloitte’s local head office. There are 22,000 IoT devices – or data points, if you like – in that smart building.
Now if you imagine that data model for a moment, the relationships between 22,000 things couldn’t possibly be mapped within a conventional database. You just couldn’t write down in detail how every single sensor and thing is connected to everything else.
Think about what would happen if one sensor reported that a room was getting colder. What would follow could be a chain reaction similar to this flow of questions:
- Why could it be getting colder?
- Is the cooling and the heating system not coming on?
- Has someone left the doors open?
- Have the lights – a source of heat – been turned down?
- How many people are in the room?
The same goes for events as it does for smart buildings. You’ll not be surprised to know that IoT events have a very similar data model and that they don’t figure terribly well in any conventional database. But the data model of IoT events do fit very well with a graph database.
We hear all the numbers and the talk around IoT, but in reality, it’s already happening if we consider examples like Uber, Hive or Nest.
Smart Cities and the IoT Difference
The other way of looking at it is to say some of this is not new. Industrial operational automation has been going on for some time.
But this also presents a new challenge: People think they already know what the IoT is all about, coming from one direction or another. However, the reality is quite different. The IoT is about having the kind of data we haven’t had before and using that data in a way we haven’t done before.
As an example, let’s talk about smart cities. A smart city is a wonderful theory which isn’t working terribly well because city authorities are imposing stuff top-down, and that doesn’t work half as well as smart services coming up.
Let’s take a closer look at one smart city app I hope at least some of you are using: Citymapper. Why would you use Citymapper? Because for you as a person, it works really well. Now turn the argument on its head and say, “What powers that?”
Citymapper has to get all their information from city authorities, but what could city authorities get back? They could know who asked what question about where to go from one point to another. And if they’re really smart, there might even be a correlation between other sensors that noticed if you decided to get on a bus or take a different transport option. Case in point: a smart city should be responsive to this sort of data.
If we change our example question towards car park, and you ask Citymapper, “I want a car park near the QEII Centre,” then, in doing that, we could understand where you’re coming from because that also pulls up the routing algorithm.
We understand whether or not there are free bays in the car park, which are all a dynamic and are constantly changing. We understand traffic flows are constantly changing, so during the process of your journey, you may have the route changed because of traffic, or you may have the destination changed because all those parking slots that were once available are now full.
The “smart” part of a smart city is if city authorities start to think differently about their IoT data. That includes collecting data about things that didn’t happen as well.
You need to know whether someone abandoned the journey because they couldn’t get to the destination or if they decided it wasn’t worth the difficulty. You’ll know how many first choices for parking didn’t happen; you’ll know where people came from, etc. With this sort of data, you can now decide on something.
This even applies to real-time situations. With smart city data, you can decide on questions like: “Do I start to change the traffic flow pattern? Do I start to adjust traffic lights?” If there’s an event happening and traffic volume is going up in an area, you now have the chance to decide to change it.
In all of these examples, you have a city that’s reacting, and you’ve also got a lot of data of a kind you’ve never had before.
Now we return to the link from industrial automation and why the IoT isn’t just the same thing happening over again. That’s because the IoT doesn’t work in the same kind of way, and therefore if you’re in the IoT startup sector graph database technology looks very, very attractive.
Complex Event Processing and New Architectures in the IoT
The most important part of IoT is what you do with the data, and that often involves complex event processing. Let’s look at a car example just to demonstrate what and why the IoT handles events differently than before.
A car, if you buy one today at the thin end of the market, has 150 sensing points on board, most of them have about 200. Move it up to the new Mercedes E or the BMW 7, and you’re up to around 400-450 sensing points. Plus, of course, the fact that they’re now connected to the Internet.
(It’s now EU law that if we ship cars, they have to have Internet connectivity. Did you know that? No? Fact.)
Here’s our car, and we’re going to look at just three sensors on it. We’re going to know what the tire pressure is, whether it’s occupied and being driven and at what speed.
From the three sensors, if we get a report that says the tire pressure’s going down, we’re not moving, and there’s no one in the driver’s seat, then it’s a null event. Until someone gets in the driver’s seat and turns on the ignition, we don’t want to know.
On the other hand, if we get the report that the pressure is going down in the tire very gently, and we’re doing 30 miles an hour (45 km/hr), then the driver is going to get an alert. They’re going to get told they have a tire pressure dropping.
Change that to an almost total loss of tire pressure in a very short period of time doing 70 miles an hour and the reactions will be very different. At that point, you’ll start to do things like pull the seat belt down, turn off the fuel supply in event of a crash, even adjust the braking.
That’s where the value comes out of IoT systems: the ability to get an outcome from the sensors that wouldn’t have been present in a standard process.
Now that’s a very simplistic example, but it gets the point across that we don’t use data in a procedural way; rather, we have events that cause us to decide on a chain of reactions. From that chain of reactions, we need an effective data model.
Now let’s look at the bigger picture. I mentioned earlier that people aren’t always recognizing what’s happening in the IoT space. Really in our brave new world of IoT, there are two or three worlds colliding.
In our earlier example of building management and industrial automation, we can agree that it’s a pretty well-developed science. These smart systems read and respond, just like a reflex: temperature goes down, heating goes on, etc.
But now, with IoT, we have a lot more ways to interact with a building than just single-response reflex. We can ask (and get the answer to) why a particular event is happening. This is where smart services really start to shine.
Let’s go back to our Uber example. Not only does Uber have to locate you and the nearest car that meets your requirements, but they also has to do a lot more calculations. They have to process your credit card through a payment system. They have to process weather forecast data and decide whether to jack up the price if it’s raining. They’ll also pull in event data and calculate increased demand within a certain radius of any large events.
All these layers of calculation now add up to something quite complicated because we’ve got three different areas (illustrated above) across which an activity can happen, and you’ll recognize that we also have – on the far right – traditional big data analytics and traditional databases, but we don’t want to use them in quite the same way we did to support the middle zone of relatively real-time reaction and smart services.
So architecturally, the IoT introduces a very different set of architectures onto the kind of systems we’re using. And the underlying assumption is that one architecture is no longer enough.
Developing Data Models in the IoT Space
A lot of different service companies are going to fall into the middle region in the above illustration, and a lot of different data sources are going to fall into the outer regions on both sides.
The key challenge is to determine a data model that not only works within your own region of the IoT space, but that efficiently interacts with other IoT sectors and leverages the value of all regions at once. It’s no good trying to build a conventional data model to do all that; you’ll need a different model altogether.
Let’s return to our smart building example and ask the question, “What information do you want to store?” The picture below looks at an air-conditioning unit and the five ways you can describe that single device.
These five main categories include:
- Location: We need to know where it is in the building or if it’s physically out on the street.
- Device description: For service purposes, we need to know what model number is it? What type is it?
- Associated customer(s): Who is it we’re working on? Who owns it? What do they do with it?
- Network settings: Many IoT networks are not traditional IT networks. They’ll be on something like ZigBee or another similar low-power network.
- Permissions: With all of these other dimensions, you of course need to know if there’s any associated permissions about who can access what.
The Shift to IoT Smart Services (vs Passive Web Processes)
So what happens when the IoT gets bigger and bigger? Why do we want this? What does it give us that’s different? The answer: It shifts us from what I call a web-based process into a smart service analytics model.
Here are just two examples of a smart service analytics model illustrated below:
Let’s start with the preventative maintenance use case on the right. If you do maintenance today, then you typically manage it by having a plan. And in our example, that plan says that every six months you visit this unit, you do certain service work on it, etc. If it goes down in between, then you have to panic react.
The classic – and absolutely true – story of this involves a particular heat pump in Canary Wharf. It failed, and an engineer went and rebuilt it on site. They’re not terribly complicated; the piston ring had cracked and that was the failure. So the service team had it stripped and rebuilt all the rings.
While the engineer was doing all this, he did the bearings, etc. and put it back into service. Approximately nine weeks later, another service engineer responded to the routine service pattern and took the heat pump apart all over again and did exactly the same replacement of the wearing parts, and put it back into service.
We see here the two contending thought patterns of plan or reaction. The whole business case about IoT is that we shift into the reactive pattern. We respond to events with an optimized capability, rather than a theoretical capability (that ended up costing this organization in terms of unneeded maintenance).
The same goes for production planning: With IoT smart services, you start to actually try and work in with what is happening on the production floor instead of having a disconnect between your past and present data that you only report on later. This means that traditional data analytics reporting needs to change significantly.
Yes, you still need backwards-looking analytics because you still need that for general direction and overall planning, but a lot more of analytics with IoT needs to become reactive. From those reactions, a certain amount of analysis improves your rules, so it’s an ever-improving circle if it’s created the right way. This is a very genuine business use case of the IoT.
John Deere: Precision Farming and the IoT
Now for our second example of IoT smart services: smart farming. I use a precision farming example because it usually surprises everyone that the farming or agriculture industry has done this so fast and so well.
I asked someone at John Deere how and why this happened so quickly, and he thought about it for a long time then replied that it was because they didn’t have an IT department. What he was actually trying to say was that they were freer to make moves in the IoT space because they didn’t have a lot of legacy technology that they had to consider as well, so don’t take his comment too far out of context.
What’s happening now is that John Deere equipment – while parsing a field – is measuring lots of things. These new devices know how fertile or how dry the soil is, what the temperature is, etc. Then, taken together, this data builds a picture of a farm and the local agribusiness.
This data helps a farmer decide on a planting pattern, and there’s a constant variability as the tractor goes across the field as to how much seed it or fertilizer it puts into the soil. Not surprisingly, it’s called precision farming because now they are applying resources with getting greater levels of precision that they’ve never had before.
But more importantly, it’s a great data exchange. Everybody’s got their finger in the data exchange of how they make this work. And that’s, again, the other principle that comes out of IoT: It’s not just me looking at the data, it’s me, my company, my industry, etc.
The Rising Trend in IoT: Analysis of Things (AoT)
When you start thinking about the IoT, you start realizing why there is so much excitement that connecting things together is going to take us to another level.
But the value has now changed: If you went back a year ago, everybody wanted to talk about sensors and their smart designs. Today, we’re past the hype about sensors and are now digging into the value created by the IoT.
There’s a new term for this IoT value creation: the Analysis of Things or AoT. If you look up AoT, you might be surprised, you’ll see some pretty decent names behind it like Teradata and IBM.
Why this new term? Because as we get more sensors, and we do more things with the IoT, the whole challenge shifts. It’s no longer just about sensing, it’s actually about what you do with the data from sensors.
We’ve stopped talking about one end of the model below, and we’ve started talking about the other.
We start with complex event processing; one step beyond that is cognitive reckoning which is what IBM Watson is; beyond that, there is whatever you like to think AI may or may not represent in the longer term.
But all of those changes rely on the fact that there is a continual interaction: there is no fixed model. You interact around what is needed, when it is needed, how it is needed. Every event causes a chain reaction across the model.
This is why I believe the IoT revolution is a revolution that depends totally on graph technology. It’s simply not a feasible answer to go beyond piloting with anything else. It has to be graph.
So when we look at what’s happening (in the illustration above), we can see a kind of chain across all these trends. At the moment we’ve got a kind of massive ad hoc move going into the way that we start to use IoT data.
Taken all together, the future of IoT is about much of the data you’ve likely worked with before, but now it’s coming from Things and the trick is to blend that into all the other data you’re already working with.
I’ve written extensively on the IoT, but the most relevant follow-up to this post is my piece on the rise of the Analytics of Things.
Inspired by Andy’s talk? Click below to download this white paper, Six Essential Skills for Mastering the Internet of Connected Things, and start extracting business value from your IoT deployment.
About the Author
Andy Mulholland, VP & Principal Analyst, Constellation Research
Andy Mulholland is Vice President and Principal Analyst of Constellation Research focusing on cloud business models. Formerly the Global Chief Technology Officer for the Capgemini Group from 2001 to 2011, Mulholland successfully led the organization through a period of mass disruption. Mulholland brings this experience to Constellation’s clients seeking to understand how Digital Business models will be built and deployed in conjunction with existing IT systems.