In the next interview in our series on the IoT ecosystem, we tackle what enterprise market participants need to consider when using IoT to help build out their business value beyond a single application — and for that, you need to think hard about your horizontal platform.
We spoke with Nokia’s Jason Collins, vice president of IoT marketing, and Frank Ploumen, IoT new product introduction and strategy, to get their take on how you might be limiting your IoT value with short-term thinking of you’re not thinking horizontal.
Readwrite: So, Jason, define how you see scalability for our enterprise clients that you guys may be talking to already; think in terms of product expansion or extension.
hack line password
Jason Collins: When most people think about scalability in the IoT space they would initially start thinking about the size of a deployment. In thinking about size they would take into consideration the problem they are trying to solve. For example, I want to measure temperature across a geographic landscape and I’m going to have X number of devices to do this. And that’s certainly one aspect of scalability, but more importantly, I think the first thing they should think about are the operational impacts of that kind of a deployment. If you’re going to deploy 20,000 devices and there is a security problem with those devices how do you update them, for example?
See also: If data is the new oil, who is your refiner?
And so scalability is also about operations. And then scalability is also across time. Nothing is ever static. Possible changes that may occur are: You may need to change a vendor out because they go out of business or a vendor becomes not suitable for something you want to do in the future. You may need new kinds of devices that support more features that you might be considering to improve your applications. So you need to support scalability across time, and across vendors, and you should think of scalability across efforts.
This last point needs a little more explanation. If you’re a company that has multiple IoT activities that you’re going to deploy over time, how do you ensure that by the time you get to the second, third and fourth business objective that requires a new and different deployment, that you’re actually leveraging what you did in that first deployment? When you take this into consideration, scalability is a big deal to ensure that your future deployments are less cumbersome and more efficient.
Frank Ploumen: I’ll have a few words. I want to particularly stress the point of multi-vendor interoperability. A lot of times when we talk to customers, the question that we get is, I can buy a solution from vendor XYZ that is turnkey and does everything from the application to the device, why would I want the hassle of this whole platform? And the discussion we usually get into is, ‘The last time I deployed a major platform or network, once it was finally deployed some things had changed causing higher hardware; higher integration costs; device OEM changes or all of the above.
So the cost of ownership over the whole lifetime heavily depends on the ability to mix and match hardware devices for many vendors to a single application, and we’ve become very used to this in other industries. If I’m talking about Wi-Fi for example, the fact that Wi-Fi on one side of the device needs to talk to a specific router on the other side doesn’t matter. Wi-Fi is Wi-Fi. Ethernet is Ethernet. Windows is Windows. So we’ve become very used to mix and matching anything. We all want the same mix and match capability in IoT solutions which require a horizontal platform capability. However, in the IoT space, we’re still stuck in very proprietary solutions where only certain permutations and combinations work.
RW: If that’s the case and obviously interoperability is the biggest challenge. I mean I literally spent two hours yesterday, just talking to three different folks at this conference yesterday who were doing different mesh network related hardware deployments for a certain basket of industries. And we should talk about that, I can feel them pulling back and saying I can’t sort out everything about interoperability, I’m trying to cover this space, for me to be able to explain it to my client. So in your minds what does the ideal platform look like, given that…?
JC: That’s exactly why you have a layered model. As an example, look at something as simple and well-known as the OSI network model. The fact is that there are already standards around the Internet but the way it starts is that you actually have a lot of different connectivity technologies and different layers that hide the complexity and hide the lack of standards from the layer beneath.
So part of this is, yes we need to have standards out of the bottom end of this platform, but another consideration is, the platform needs to be able to adapt to the standards and proprietary protocols that are there, and also account for the standards that are coming up.
FP: Let’s review some of the key layers that come with an IoT solution.
At the bottom layer, you have devices or sensors, and they are the source of the data. Then you have networks, and network is a very broad term for local networks, long distance networks, wired, wireless, licensed or unlicensed and so on, or a combination of any of the above, but ultimately networks.
Then you have a layer where networks feed into a data mediation or brokerage layer.
Then at the top level, we have the stuff that we all know very well and that’s the applications, the dashboards, the very visible stuff.
A very important design goal when we talk about scalability and horizontal platforms is that we basically figured an application should be completely agnostic on what happens underneath. Data is data. Temperature is temperature. You, as an application developer should not have to worry where temperature came from, what protocol is used, what device generated it. Your application cares about temperature, that’s all you need to know. Creating this level of segmentation will make interoperability easier.
JC: And by the way to that point, if you look at something like IoT versus a generic Internet application, the IoT application is different… because of things like battery life and the size and kinds of data that you’re getting from the devices. Actually, what most people in this industry are used to dealing with which is IP because it’s been around forever…but IP doesn’t actually become a good way of accessing devices as you go lower in the stack. So there’s a reinvigoration of the need to have an adaption layer because everybody is going to be analyzing and transporting this data using the IP layer and above once it hits the core network. Meanwhile, below that, when you get to the devices IP makes no sense because you’re running out of battery in a week.
FP: That’s a very interesting observation. The implication here is that the number of use cases in IoT is so vast, that it’s unrealistic to expect that there’s a one size fits all network typology type of solution. There will be many answers to many different things.
What I do on a battery constrained device that runs in the field (e.g. in oil and mining) versus a powered device used in the connected home is different from the physical layer point of view. But the application should not have to be tailored because otherwise, you keep redesigning and re-architecting applications for hybrid environments.
RW: You’re turning a hardware problem into a software problem
FP: Exactly. So if I build very simply let’s say an asset tracking application. In one city, I might be tracking over a cellular network. Why would I have to redesign that if I am deploying the same application in mining on a custom proprietary network. It’s the same application. Or maybe I have hybrids. I have networks that have some devices coming in over one network and then devices coming in over a new network. Like when we roll out 5G we will start rolling out devices. You don’t want to have to deal with applications that work in the old world and then different applications that work in the new world.
RW: A lot of what you just pointed out there is a story that I see over and over again. Some company has to do IoT strategy, so come let me explain it to you. And when I sit down with them and it’s a brand that you wouldn’t think of as being IoT right out of the box, it’s not one of the sort of pillars of IoT around communication or some aspect of big data or a specific hardware industrial, smart home marker, whoever, who you can see why they’d want to provide better connections or to create a network out of their core product.
You can see that they want to dig out the corner of the world that they can understand. if you were to say how do you build a horizontal platform, do they need to be told that, do they need to just be made aware that they already have one, how do you picture that conversation going? Obviously, it’s client specific, but do they really know what they have already?
You can see that they want to dig out the corner of the world that they can understand. if you were to say how do you build a horizontal platform, do they need to be told that, do they need to just be made aware that they already have one, how do you picture that conversation going? Obviously, it’s client specific, but do they really know what they have already?
What do you need as an enterprise client to build a horizontal platform? Do you just need to be made aware that you already have the beginnings of this and how to jump off from there?
JC: I would say the first thing is becoming convinced that you actually need a platform. So you see a lot of people going out and building siloed applications which I think is fine as long as all you’re doing is an experiment. It’s when you actually stop and think about how this will answer a real business problem and positively impact your business longer term, is when you should think about a need for a platform that can exist for the next 10 years or more and expand to meet my needs. When you start thinking about scalability issues you quickly come to the conclusion that you shouldn’t be just haphazardly bringing up siloed applications. It is the equivalent of a simplified analogy that goes like this: “I need these two computers to communicate with each other, so therefore I’m going to a string a wire down the wall and then down the hallway.”
In the short term that could be fine, until you realize what you wanted to do is to provide everybody in the office with PCs on their desktops and be able to do email. Suddenly you think, ‘Well, maybe stringing a wire isn’t the best idea. Maybe the first idea is to hook up the first two executives to see if they use e-mail as an application, but not such a good idea for actually deploying email for an enterprise.
So convincing somebody that they need a platform is first, and then I would say that you probably don’t want to build your own platform because there’s a lot of platforms out there. I should be looking for what I can hook into that already exists that could give me a leg up. And I should start that conversation by thinking about the things we’ve been talking about. Standards, support for existing proprietary stuff, data mediation: what’s going to make it easier for me to build applications on top of that? What’s going to make it easy for me to hook up my particular devices now and as we move forward into an unknown future?
It’s something that we haven’t talked about because I think we’ve been focused kind of on the data mediation piece of the whole problem, but device management is also really, really key to think about–and doing it in standards-based way so that as I increase the size and numbers and kinds of deployments, that I have a way of accessing these devices and doing updates and monitoring battery life in a way that is hidden from the application layer.
It’s something that we haven’t talked about because I think we’ve been focused kind of on the data mediation piece of the whole problem, but device management is also really, really key to think about–and doing it in standards-based way so that as I increase the size and numbers and kinds of deployments, that I have a way of accessing these devices and doing updates and monitoring battery life in a way that is hidden from the application layer.
FP: The examples that Jason gives are all examples that have to do with operations and the cost over the lifecycle of the service. First enterprises need to understand if they want to pursue IoT or not. Most people have already made that mental decision. And then they jump straight to the use case, like how awesome would it be if I can control or automate or analyze etc. and the operations often become an afterthought. Which is why the platform discussion doesn’t get a front row seat. We’re going to get started, we can control a few things, we hook up a few things, it looks really awesome. Like Jason’s analogy when we strung the two computers together we could get email and I’ll just roll it out to everybody.
If you don’t think about that operations problem up front, then you’re really going to get burnt down the road. And here’s where you see two different types of customers. The customers that either have been burnt before and start very carefully to delve into those operational questions. They’re very easily convinced they need a platform. And others are maybe a bit naive in operations and just focus on the use case per se and consider operations something that will come down the road. And that’s a very difficult conversation to have.
The second observation here is whether to build it ourselves or whether to buy it, and this is also not a new discussion. If you remember several years ago when a lot of embedded devices had their own custom operating systems and there was a lot of fragmentation in that area. The mindset of the developers often was ‘well I want to avoid paying for licenses, how hard could it be, I download some open source software to build my own version of what I need. We’ve all been there but at some point, you realize it can’t be just downloading an open distribution from Linux. The real value is in not having to maintain the lower layer itself. If it is done well by someone else you are more interoperable with the rest of the world which adds significant value.
RW: So that operations gap, I guess it’s been explained to me, I look at some of the Industrial concepts and I see people struggling that we are at a certain level of transparency and data awareness and usefulness. And we want to 2X that, so it’s like the same song but twice as fast. So they can string two computers together and that is functional but it is not ideal. And that pushback between the operations and the data management executive side of the discussion is a chasm that’s challenging them to bridge. Are these silos still too hard to knock down within an organization? Is it going to be a real challenge to have that internal discussion?
FP: Well you realize that the history in IoT is quite long. People might have deployed proprietary systems that are basically connected and seem to be very functional. The longer a system is in place without problems, the more afraid people get about dealing with it. When you’ve got let’s say an ancient building automation system from twelve years ago, that talks protocols that no one understands, but it works fantastic even though it should have been retired a long time ago.
RW: So we don’t want to open it up because we don’t know what will happen.
FP: The problem that comes is if you ever want to do anything more than what is designed for or for example connect new hardware to this platform, well good luck right? It’s a closed island and it is what it is. Now you’re stuck.
I’ve seen customers literally come to us, and one particular example a couple of years ago, a customer, I kid you not, told me that they had 37 different building automation systems that were gathering energy data from their real estate. And they could not come up with a way to aggregate and consolidate all of the data so that they could compare energy bills.
So you get into situations where nobody wants to touch it because it works. That’s one of the sad things about this old industrial stuff. It is really good at what it does, but you’ve lost all flexibility, and the opportunity to improve it and make it interact with other things in the world. As opposed to looking at the internet with anything connected to anything and which continues growing and picking up new data sources. I’m making a very extreme case here right. But look at something like Alexa in Amazon that we all know. Alexa connects to everything and anything and can control anything. It adds a few hundred different interfaces per month so it becomes richer and more powerful.
With Alexa, you’re tearing off a sheet and starting something new with being the leading voice commands platform,
What they’ve done is created a really good framework for integrating islands of data. Because otherwise, it wouldn’t be very good if Alexa could just do one thing, it would be a one trick pony.
The reason it’s so good is they’ve made it really easy to integrate Alexa against Philips lights, against thermostats, against you name it, so that’s the platform analogy power that you see there. If they hadn’t done that and they made it very narrowly defined, then it wouldn’t have had that power. The platform gives you that ability to very quickly and seamlessly integrate islands of data including those old legacy items that nobody wants to deal with.
Published in partnership with Nokia.
Phone Tricks 