Podcasts
02 August 2023
IoT Leaders with Nick Earle, CEO of Eseye, Matt Hatton, Founding Partner of Transforma Insights, and SVP Strategy & Alliances Larry Socher
It is disheartening, but true: 84% find that hardware design is the number one barrier to IoT deployments. Why?
Simply put: it’s all about the device. If connectivity isn’t built into the device from the outset, and instead jammed in at the end, it won’t work.
Transforma Insights Founding Partner Matt Hatton and Eseye SVP Strategy & Alliances Larry Socher both join Nick Earle on the IoT Leaders podcast to share insight on why the IoT industry remains behind the curve on solving connectivity.
Together, Nick, Matt and Larry dive into:
Tune in to hear how Transforma Insights identifies the major challenges to the IoT industry — and how Eseye works to overcome them.
Join us on the IoT Leaders Podcast and share your stories about IoT, digital transformation and innovation with host, Nick Earle.
Contact usIntro:
You are listening to IoT Leaders, a podcast from Eseye that shares real IoT stories from the field about digital transformation swings and misses, lessons learned, and innovation strategies that work. In each episode, you’ll hear our conversations with top digitization leaders on how IoT is changing the world for the better. Let IoT leaders be your guide to IoT, digital transformation, and innovation. Let’s get into the show.
Nick Earle:
Hi, this is Nick Earle, CEO of Eseye. This week, we’re going to be talking about one of the big dilemmas in IoT. We start the podcast with that dilemma. To sum it up, when we learn the lesson the hard way that you have to put security in the device upfront rather than try and implement it afterwards because it doesn’t work, why have we not learned that lesson around connectivity with IoT? Or put it another way, if 80% of IoT projects fail, why haven’t we learned the lesson that one of the biggest reasons for it is that it’s all about the device? You’ve got to design the connectivity into the device, not jam it in at the end because that’s the number one reason why it doesn’t work. Survey after survey after survey keeps on making that point, but why is it not happening?
So, to join me on this week’s podcast, I’ve actually got two guests, both repeat visitors. Although as you hear when you listen to the podcast, I didn’t realize that Matt Hatton, the founder of Transforma Insights, who’s our main guest, has actually been on before, but they’re both twofers, as I call them, a second time round. Matt talks about all the reasons why you absolutely have to address connectivity at device design and the five different areas you have to think about. It’s all to do with a white paper that’s just been released on our website. Then Larry, Larry Socher, who, again, has been on here before. He’s very involved in our predictions report, which is our number one download, a piece of collateral on our website every year. Larry talks about how, at Eseye, we’re trying to solve that huge problem of how do you in a simple way… Actually, how do using software be able to let connectivity be built into any specification, into any device? So, it’s a really interesting one.
It’s backed up by a white paper and lots of case studies, which are all on our website, and we refer to them throughout the podcast. I think it’s going to be very interesting, and I hope it will be very interesting for all of you listening or indeed watching this. If you are watching it, we have a bit of fun at the beginning because Matt is wearing a really loud golf shirt, which is unusual for him. So, with that, let me hand over now to the podcast, IoT Leaders with Matt Hatton, the founder of Transforma Insights. Here we go. So, Matt and Larry, welcome to the IoT Leaders Podcast.
Matt Hatton:
Thank you, Nick. Delighted to be here.
Larry Socher:
Great to be here, Nick.
Nick Earle:
I think it’s your second appearance, Larry. So, you’re a twofer on this program, so you should be really good.
Larry Socher:
Expert.
Nick Earle:
You’ve done it before. So for the listeners-
Matt Hatton: Nick, I’m not sure, but I think I might have been on here before.
Nick Earle:
Oh, you are, Matt. You know what? You are a twofer. My apologies. Do you know what? My mind was distracted because, for those of you watching on video, Matt has got the world’s loudest golf shirt on, which he’s very proud of. He’s now adjusting it. It looks like an explosion in a feather factory with blue ink is the best way I can put it. But I’m very jealous, Matt, of your… You look like you’ve just stepped off the golf course actually.
Matt Hatton:
Thank you. Yes, I’ve come today as the club pro. That’s my outfit today. I thought this was a fancy dress party, but seemingly not.
Nick Earle:
For our American listeners, fancy dress means costume party, not-
Larry Socher:
Let me guess.
Nick Earle:
… fancying a dress. Okay, so listen, let me attempt to drag this back to the subject under discussion, which is actually, I would paraphrase it as the biggest single learning in the last 10 years of IoT. So how about that for an opening? Let me try and set it up, lay the table here. If we go back and look at the experience of implementing IoT, and all of us certainly and probably the vast majority of our listeners have been involved in IoT for a long time, one of the key lessons, and I’ll use the example of security, is that we used to think security was a bolt-on. Then, we actually realized that actually, you’ve got to design security in right up front. You just cannot do it as a bolt-on. We called it security by design. It was also known as DevSecOps. Now, everyone says, “Oh, yeah. I always knew that.” You have to start with security. It’s not an add-on. It’s not something you can stick onto the product at the end.
However, when it comes to IoT, connectivity is something that in the vast majority of use cases that we see, and we see hundreds, I would say 80%, maybe more, of people say, “Yeah, yeah, yeah. I’ve got my product. I’ve bought my product, or I’ve designed my product, or I’ve got the product sorted, and now, I want connectivity.” The question is, why is connectivity different to security? Our belief… This is where I’m delighted to have Matt Hatton on the line. I’ll introduce Matt in a second, not just his shirt, but our view is that it’s the same. Actually, you’ve got to design connectivity into the device, which has massive implications. But to get into this, I’m going to talk to both Matt and Larry. I’m going to start off with Matt.
For those of you who don’t know Matt, and he is a twofer, as we’ve said, he is the founding partner of Transforma Insights, and has been around the industry for a very long time. Let me just leave that there, Matt. That’s very diplomatic, isn’t it? As have I, a mature member of the community, as has Larry actually, and is very well known. He’s a speaker. He travels like crazy. He’s an author, and he’s someone who many parts of the industry go to for advice, so we’re delighted to have you back on the IoT Leaders Podcast. Matt, let me plunge in. We’re going to talk to you, then we’re going to talk to Larry. Then, I’m going to come back to you, Matt.
So Matt, that opening, connectivity by design, I know there’s a white paper that you’ve written that we’ve sponsored which goes into this a lot more detail. We give the listeners and the viewers a lot more info on that, so there is a big white paper on this subject for those of you listening. But if you could perhaps net out, I think you’ve got five key sort of conclusions of why this is important and what you need to do. So, for the podcast, perhaps you could go through those points to start us off.
Matt Hatton:
Of course, I can. Happy to. Yes, there’s a white paper which was published a couple of weeks ago called Connected-by-Design: Optimising Device-to-Cloud Connectivity. It actually doesn’t mention IoT in the title at all, which is rather radical for a paper about IoT, but there you go. Maybe we don’t talk about IoT anymore. Maybe we talk about device-to-cloud or even device-to-cloud function, which is something that we talk about a bit. But let me talk a little bit through the thought process that we went through. Larry and I had some extensive discussions about all things related to this during the process of putting this together, so it was an interesting exercise. Starting point is really… We kind of take a step back first to then kind of take two steps forward, if that makes sense.
So, first things first, we looked at a couple of dimensions of complexity for IoT, which sounds a very verbose way of describing what we’re looking at. But effectively, it’s a couple of things. One is IoT is very complex in terms of having a hugely diverse set of requirements for the applications that use it, even to the point of… I think we probably discussed this in previous sessions, maybe on this podcast, maybe elsewhere. I’ve certainly had conversations with people about whether even IoT is a useful term or whether it’s just an umbrella for a whole bunch of vertical applications that do all sorts of different things. Does somebody driving a connected car really think of their car as being an IoT device, or does somebody with a pet tracker think about that? Is somebody implementing a fleet management solution? Are they thinking about IoT? Are they just thinking, “I’m making use of connectivity to streamline my business processes or whatever”? The point is you’ve got all this diversity within IoT, even if you assume that IoT is a thing in its own right, but maybe debatable.
But all of those applications have very different deployment parameters, different needs, so you think about a connected car. That device has got to be in the field for 20 years maybe. It’s got to support high-bandwidth applications. It’s got to be ruggedized because it’s got to cope with a lot of vibration and probably some extremes of heat and temperature and sorry, and cold and so on. You contrast that maybe with an environmental sensing device, which is going to be put into one place, and it’s going to sit there for a few years. Now, the priority there is maybe low cost or the priority is long battery life because maybe you don’t have access to power, whereas you did have access to power with the connected car. There’s just a couple of examples. You could look at maybe smart watches. Smart watches, you need to minimize space. Also, you’re thinking about power consumption there as well. So, you’ve got all these kind of different dynamics and different considerations depending on which application you’re looking at. That’s one dimension of complexity within IoT.
The other dimension of complexity is that there’s just so many moving parts associated with IoT. Well, some moving and some not so moving as it were, but all the way through that full stack of IoT has an awful lot of parts to it. It’s the sensors in the devices. It’s the operating systems within those devices themselves. It’s the processing that might sit on there. It’s the networks, it’s the cloud storage, it’s the application, it’s the interface with the enterprise back-office system. It’s got all of these elements, all of which have to interact with each other. That’s only getting increasingly complicated as you have more requirements for putting, say, more compute closer to the edge device to make use of AI. So, you’ve got increasing questions of where your payloads sit, where AI functions sit, all of these sorts of questions, so you’ve got an increasing amount of complexity there. You’ve got these two dimensions, so that’s the first couple of points-
Nick Earle:
Actually, if I can jump in because I do want to link back to certain previous other podcasts. It may well have been one of the ones that you were on. When we say, “Why is this a big aha now? I mean, we’ve been doing this for years,” and I talked about when people come to us, it’s very, very common for people to say, “I just want connectivity.” What you’ve just said is, “Well, hold on a second. Every use case is different, so what do you mean by connectivity?” Connectivity is one word, but it can mean a hundred things.
Secondly, all the physical components and the software and the firmware and every device is different. We’ve all been conditioned by mobile phones, cell phones for 40 years. Connectivity is enabled by putting a SIM card in a device where someone’s done all that work for you, and you don’t design your own mobile phone. So, it’s not surprising that people say, “I just want SIMs and data.” It’s not surprising that many IoT companies’ websites, their homepage is, “How many sims do you want and how much data do you want?” I mean, they are just basically advertising that it’s just about the connectivity and the price. What those first two, and I know you’ve got five, those first two explain, like you said, it’s a two-by-two matrix. It’s a huge two by two. It’s not the little bottom left-hand corner which says, “Which mobile phone do you want, and which operator do you want?”
Matt Hatton:
Oh, completely. I will come on to exactly that point. Yes. Having set that kind of a framework, well, then the next thing to think is… Okay, well actually, the connectivity piece is probably the most complicated piece of both of those dimensions to get right. You think about the requirements of each application. Actually, probably the most complicated piece or the most diversity within the requirements of any of these applications that we think of within the weird and wonderful world of IoT is within that IoT… sorry, within the connectivity part of it, what bandwidth does it need? What’s the power consumption? Okay, power consumption… It will also be dictated by a bunch of other things, but really, the connectivity part is the overwhelming thing that will determine what the battery life is of a connected device.
The processing, where the processing sits, all of these different elements, the connectivity piece will be the overwhelming consideration for when you’re making your real tech choices to meet the requirements of the diversity in different IoT deployments. The constraints tend to be application specific, and therefore, coping with the constraints is generally the thing that the connectivity has to do. So that’s one aspect of it.
But also, the second aspect of it is with regard to the full stack. Well, within that stack, it’s probably the connectivity. Most certainly, our hypothesis is that it’s the connectivity piece that’s the most critical part of the whole stack because that determines all of the other decisions you make across all of the other parts, what functionality you need to have on the device and what capabilities you need to have on the device, where your payload sits, how you handle edge compute, how you handle all of the processing, what kind of data might be actually available to deliver into those enterprise back office systems. The main conclusion or one of the main conclusions, therefore, is that a lot of the dependency on of all this complexity is sitting on connectivity. Because of that, we get to this idea of Connected-by-Design.
Well, first off, we get to an idea of you need to optimize your connectivity piece. You need to be thinking about, “Well, how do I make sure that I’m using the right connectivity for the protocols I’m using, for the application logic that I’ve got, for all of the various different constituent parts of the proposition, so they all need to optimize?” But really, you need to be thinking about this stuff upfront, and that analogy you gave of secure by design, well, it’s not accidental that we’ve come up with the term Connected-by-Design because the principle is the same one. The principle being connectivity is that critical to all of these elements because of the diversity and because of the complexity of the number of moving parts within an IoT solution. Then, you need to be thinking about it from day one. You can’t just slap it on the top. You can’t just put your solution together and then hop over to a connectivity provider’s website, buy a bunch of SIM cards, and stick them in your device. Well, you can. Just please-
Nick Earle:
Well, you can, but then you’ll be part of the 80% of stats that we keep on quoting and the analysts keep on quoting, the 80% of people whose IoT project fails and then they come round the second time round, but it’s 18 months later and their bosses, if they’re still in the same position say, “Are you going to get it right this time?” It is interesting the way you describe it. It’s actually one of the big things that came out of the white paper is, I almost paraphrased it listening to you, there’s no such thing as a standard use case. There’s a standard use case for a telephone. There is a cell phone. There is no such thing as a standard use case for IoT. There’s no such thing as a standard device. In fact, it’s almost a build your own solution. There’s no such thing as a standard architecture for how you optimize the components within the device.
The fourth one you said was, “But actually, of all the things that the IoT device has to do, the most critical one to delivering the business outcome is the connectivity.” That’s a really, really key point. Then, the final one that says, “Given all of that,” in my words, not yours, “but if you want to maximize your chances of succeeding, you have to do connectivity by design. You have to focus on this upfront because otherwise, you just learn the lesson the hard way.” That actually brings me, if I can transition, to pivot to you, Larry, because… Of course, this is an Eseye podcast, but we bring experts onto it. Given what Matt said, all of that means that unless you happen to have a very large connectivity department, a very large group of firmware engineers and hardware designers and… Some big companies do. Matt quoted that automotive companies absolutely have this, but for the rest of us, you actually need to work with a partner who knows how to do this and has it at the core of their offerings. If I can ask you to talk about our company, this is the-
Larry Socher:
Sure.
Nick Earle:
… internal bit that we very rarely do on our podcast. We’ve maybe done it two or three times. I think this is number 35 or something. How does Eseye, Larry, address those points that Matt raised?
Larry Socher:
It’s a great question, Nick. I actually joined Eseye about a year and a half ago after 26 years at Accenture where we were doing a lot of this upfront design work, and we’re very used to it. When I joined, one of the things I realized that really separated Eseye from others, particularly smaller companies, is Eseye has always been doing this kind of upfront design work. In fact, if you actually look at a lot of the qualification processes that we’ve had historically, really helped our customers, “Hey, is the design right,” because we understood the importance of doing that.
But interestingly enough, last summer, we had sponsored a study with Kaleido Intelligence. It was basically looking at the challenges of IoT connectivity where they interviewed over 750 enterprises around the globe. While we were expecting to hear a lot about the challenges of cellular connectivity, low-powered networks, regulatory, commercial, et cetera, and those all came in around the 50th percentile in terms of those being challenges, the thing that really stuck out to us was they identified the top challenge. 84% of the respondents said device design and getting that right up front was a huge challenge. That was a huge wake-up call for us, so while we were doing it, and we had a lot of device capabilities right up front and doing a lot of advisory stuff, what we realized was the importance of device design and having the intelligence built right into the solutions.
So first, we stepped back and said, “Hey, we really need to amplify our focus on device intelligence, in particularly, the connectivity intelligence just in how we message in the market.” So, we amplified it to focus on device intelligence alongside our AnyNet connectivity, our Infinity Platform. We then stepped back and said, “Hey, we’re already doing all these services. We really got to look at our IoT services framework, the catalog of services, so we did a better job of structuring and going through everything from design, redesign. A lot of cases it’s redesigning a product that’s had issues in the market or the next generation of it. All the development, the integration capabilities, helping our customers test and validate, certification support, particularly when you’ve got to get to all the regulatory stuff, and then deploying, so we looked at that.
A great example is one where we were working very closely with our customer, Precision Animal Solutions… Nick actually released a podcast about a month ago, and we helped them design a solution for one of the biggest challenges facing cattle, bovine respiratory disease. This is a major issue for cows, and negatively impacts capital and livestock numbers. So we had Bluetooth sensors, and we helped them develop a ruggedized cellular gateway that would then communicate upstream to some backend machine learning in a dashboard to help prevent this. So, a great example of work that we were doing with customers and helping them upfront doing some services work. We then started to look at the actual software on the device itself, so if you need intelligent connectivity, what can we do to codify all the decades experience designing, building, deploying, working with different modem and technology providers and different operators around the globe?
This January, we actually released our SMARTconnect software, which essentially codifies all that experiences. It provides on-device connectivity intelligence that get embedded into the device, gives our customers and partners really simplified send and receive APIs so that they can then not worry about the connectivity, but really focus on the applications, the data, the machine learning models that deliver value. It does everything from handling the modem selection and optimization, provides higher layer protocols like MQTT, an implicit agent for managing the device with Lightweight M2M. What it can do is it can accelerate time to market. It helps with the design deployment and testing by integrating this code, and it also avoids the need to hire very expensive engineers where you’re competing with the likes of Tesla.
Great case study of this was the work, and there’s a podcast on this as well and we’ll get links at the end of the show, is American Pharma. They have a product called PharmaWatch that does tracking of medical stuff, so it could be transplants, could be COVID vaccines, so things that need strict environmental control, so temperature, humidity. They had implemented this on their PharmaWatch product to solve simplified APIs and provide connectivity. It turned out, if you’re familiar with the Rogers outage last July, not only were they down for 19 hours, but the radio access network was actually up.
Now, they had implemented SMARTconnect because they wanted simplified APIs, but because it had an embedded end-to-end protocol, it realized that the network was down. So, most of the modems, the multi-IMSI bootstraps, the logic to recover thought the network was talking, but didn’t realize there was no data plan. Because this had embedded intelligence, it knew the end-to-end path was down, they would be able to very quickly recover and get up and running on TELUS or Bells. So it’s a good example of this device intelligence being integrated in and having a huge benefit around resiliency, et cetera.
More recently, we actually launched a couple things. First of all, the IoT Readiness framework. I spent a lot of time at Accenture driving cloud and infrastructure offerings. In the IT world, there are models of maturity, so if you think about ITIL, does it for the IT world. Then, we looked at IoT and realized we don’t have the same kind of maturity model. You know at Accenture; we didn’t have it in our Industry X practice. Deloitte and others don’t have that. Now, it turned out we already had developed a very detailed set of questions that helped us qualify opportunities looking at the complete life cycles of services. We stepped back and said, “Hey, what if we added a maturity assessment, some grading, a scorecard?”
We then took a page out of NASA’s Technology Readiness Level, the TRL, and created this IoT Readiness Level, which was really essentially summarizing how far people are into the process based on the outcome of the scorecard from simple idea of a zero scale to full commercial application at nine. Then, what we do is we use the detailed scorecard to help customize, identify gaps, and propose projects for closing those gaps, essentially trying to get away from that 80% failure rate and up their chances of success. I recently conducted one of these with a battery measurement company. We spent about two hours, maybe closer to two and a half hours, going through the questionnaire. What amazed me was, just with the lack of this in the market, how enthusiastic they were. They wanted to not just answer the questions, they wanted to come up with their own scoring. They were pushing for that up and down. Then, anything they didn’t answer, they were able to chase down in a couple of hours. So, there really seems to be a big void in the market.
Nick Earle:
I think one of the learnings that what you’ve said is kind of like the other half of the jigsaw piece, if I can use bad analogy, to what Matt said because Matt talks about everything is a… It’s almost like a five-by-five matrix. I mean, everything is much more complicated and much more fragmented, not just more complicated, more fragmented. Therefore, if you’ve got many, many more permutations of all the components, what that says is there is no standard five-step process to success because every single person is starting off at a different place, and every single person is using a different solution to get to a different destination to everybody else. Therefore, every IoT project is by definition unique. No two IoT projects are the same. If no two IoT projects are the same, how on earth do you get best practices because whoever you talk to didn’t have the problems that you’ve got?
What you’re saying, and I know that we talked to Eric Goodness, who’s the head of research at Gartner, a distinguished fellow, I think. I’m probably using his… If you’re listening, Eric, sorry. I hope I’m using your correct title, and part of his remit is the MQ, the Magic Quadrant work. He said the biggest gap in IoT is how do you get projects that are totally unique under the umbrella of a standard framework? The answer is it has to be a customized journey, which starts off from an analysis of where they are. I think that’s what you’re saying, right?
Larry Socher:
Absolutely. In fact, I mean the high-level steps are the same, but when you get into the detail of those steps, everything has to be incredibly customized and more than just customized, it’s optimized. You go back to Matt’s paper. He talks about it’s not just tailoring the solution, it’s getting an optimal solution, what’s the battery lifespan, et cetera. Now, one thing I will say, go read the paper. Matt goes in incredible detail on each of the full stack as well as the connectivity optimization. He’s got like how different use cases require different power, bandwidth, latency, resiliency use cases, so it’s very well laid out in white paper. I highly encourage you to go read about the details of how customized and optimized each element from the full stack all the way through connectivity needs to be.
Matt Hatton:
But even that, we can’t hope to replicate the very specific requirements that any given organization will have. All you can do is say, “Oh, within this type of a use case, it will typically be this,” but everybody’s needs are different, which leads me back to your point, Nick, which is everything is, to some extent, customized. The question is how do you, as a provider of services in the space, kind of walk that tightrope between being effectively a consulting business and actually trying to be a scalable business? It’s a bit of a challenge. But what’s been noticeable in IoT is those companies, typically who have made their money elsewhere and decided to try dwell their way into IoT thinking that they could get in just as a infinitely scalable, universally applicable IoT typically platform, might be relevant in other spaces as well but typically in the platform space, have found that actually they can’t do that because in reality, everything is, to some extent, customized or at least we use the term contextualized.
So you might sell us a set of horizontal capabilities, but you still need to understand the way that the companies that are deploying it are going to be using it. So, being able to, like I say, contextualize those capabilities and say, “Okay, you are in the utility space. What you need is this technology. You need to deploy it in this way, and you need to apply it with this,” which means that actually, we’ll start getting more and more vertical sector expertise in the successful service providers rather than everything being a horizontal sale. You mentioned about the companies where it’s just, I’m going to sell you a SIM card. Well, that kind of business model I don’t think lasts very long.
Nick Earle:
It is interesting, isn’t it because there’s a lot of disruption. I don’t know if Transforma… Your website describes and your LinkedIn profile describes how you focus on business model disruption. If you look at what’s happening in the MVNO space, if you look at what’s happening in the MNO space with a lot of the traditional platform providers either exiting the business or spinning it out or whatever, there’s a huge amount of disruption going on. I mean, there’s just disruption everywhere. I think it is absolutely linked to what you said is that the market has got two fundamental dilemmas from a strategic point of view. Speaking as a CEO, you kind of got a two-by-two matrix, and you’ve got to decide which square you’re going to play on because there’s a volume-value play. There’s the industry vertical plays as you said.
If I use an example, EV (Electric Vehicles) chargers. We do a lot of EV chargers. We do all of Shell’s EV chargers. We do BP. Well, we’re not going through all the names. We have a lot of EV chargers, but you’d think that all EV chargers were the same, right? I mean, it basically does the same thing. But it doesn’t do the same thing. We have to go through this process every time. There’s no such thing as a standard IoT EV charger implementation, but there’s lots of people trying to get into the EV charger business, same with medical devices. The only one common thing on all of them is that the business case is predicated on how close you can get to 100% connectivity. But they’re all trying to solve different things.
I’ve used this example of it in other podcasts. You’d think, “Well, it’s cellular connectivity, right?” But if you’re doing a home charger, and it’s going on the outside of a garage wall, then you actually don’t want to use cellular. You want to use Wi-Fi because it’s free, but as I know and as we all know, Wi-Fi is not very good at going through bricks. Yeah, there’s going to be HaLow in the future, which is going to solve it, but it isn’t here yet. But sometimes, it does go through the bricks. Sometimes you get a signal for your little charger on the outside of your wall, and sometimes it doesn’t. So it comes back to Larry’s point about you really want is the rules-based engine and the intelligence to start with a device and from the device out.
One of our previous podcast guests said spontaneously, and I thought it was a great way of summarizing it, “Well, what you really want is to let the device choose the connectivity.” That is an upside down summary of the last 40 years of the industry because it was the operator chose the connectivity and the roaming agreements. Then, we’ve had about, I don’t know, let’s call it 10 years of the MVNO saying, “No, we’ll choose the connectivity, and we’ll bring you multi-IMSI.” Actually, the ultimate destination is the device chooses the connectivity because the rules-based intelligence says, “If Wi-Fi is available and it meets these technical criteria, then use it. If not, search for any network that’s available, not the one that you’re locked into” because it is eSIM, and its operator agnostic. But, I need this latency capability, and I need this signal strength capability. That’s just two of the radio-access types that are out there and many more coming in the future, so I think we certainly agree with you.
I think that what it comes down to, this is not about what our strategy is or another IoT company’s strategy is, it’s that from a user point of view, the lessons of this are that it’s all about the device. It’s actually all about the device. You said if you’re just selling the SIMs and the data, it’s not going to be successful. But you go on to Google 20 IoT companies and go to their website, I would say 18 of them say on the front page, “How many SIMs do you want and how much data do you want?” There’s definitely disruption coming, and that’s been the theme of almost all of these podcasts.
Matt, I wanted to actually, if I can ask you some questions because we don’t want this to be the Eseye show. We try hard not to be, but obviously, we’re commenting from our own perspective. But as an industry analyst and someone who has a very broad view of the market and talks to all the companies out there, the central premise of this podcast is you have to start with the device. You have to do connectivity by design. You don’t add it on afterwards. But the examples that we’ve used are that we were doing M2M in 2010. We’re now in 2023. Certainly, in terms of the inputs that we get, 80% prospects come to us. 80% of people say… They start up by saying, “How much is your SIM cards? How much is your data?” So they are starting with connectivity.
Why are we, after 13 years as an industry, having to do a podcast which says, “Duh, learn the lessons in security. It’s all about the device. If you don’t believe me, read the white paper”? There’s tons of case studies, but it still feels a bit like we’re pushing water uphill. I mean, maybe you have to fail to learn a lesson, but why do you think as an agnostic industry commentator that we are still at this stage?
Matt Hatton:
Well, there’s an element of, “If all you have is a hammer, everything looks like a nail,” but I’m being a little bit on a funk there.
Nick Earle:
That’s a little… Yeah, okay.
Matt Hatton:
But I think there’s an even more fundamental point, which is, okay, if I’m an OEM developing my first connected product, or if I’m a solution provider trying to develop a, I don’t know, smart parking solution or a CO2 monitoring solution for going in buildings or whatever, I’m trying to come up with that, what’s my starting point? My starting point… Well, first off, I’m kind of thinking about the application. Then, when I go to build it, it’s probably the device. Then, repeatedly, we hear from connectivity providers, “Oh, it’s so unfair. We’re only ever a commoditized part. People come to us last, and they’ve already built their solution. They just want to buy the connectivity to bolt into that, and they just want the cheapest because they’ve already made all the decisions about this, that, and the other.” But those two things are very closely linked, right?
If you want earlier consideration and you want to be providing the more sort of consultative parts, the presales, post sales, not just to be seen as a functional element to bolt into the solution, you have to be involved in the device. That hasn’t happened a lot. In part, I think… Well actually, if I’m perfectly honest, it doesn’t make much sense to me and never has done. There have been some device manufacturers that have made moves into connectivity. Sierra Wireless did many years. They’d been trying to get into the recurring revenue business, and they tried to do that. Well, they’ve been moderately successful.
Nick Earle:
Yeah.
Matt Hatton:
Yeah, but it does strike me that you have to span across these two things, but to a certain extent, maybe there wasn’t necessarily the absolute necessity of doing it before now because everybody was working with suboptimal technologies, right?
Nick Earle:
Yeah.
Matt Hatton:
So you weren’t working with technologies which were optimized for IoT, which meant that they were probably massively over spec’d for the requirements or not that appropriate or whatever. Using GPRS to connect a remote sensor, well, that device will last a couple of weeks, and there’s not much else you can do with it, right? You throw LoRaWAN or NB-IoT into the mix, and suddenly, you connect something for multiple months, possibly years. Then, you start thinking, “Okay. Well then, I’ve got to start thinking about this cross optimization of the various different elements because then I can really take advantage of the capabilities and the assets, that technology, that functionality gives me in order to actually address this application.” So, to a certain extent, this need to cross optimize has been forced on us by the availability of these technologies which are much more optimized for IoT.
Because if you had to do everything with a 5G connection, well, you could do whatever you like. You wouldn’t need to worry about protocols or on device processing or whatever, but your costs would be through the roof, and your battery life would be gone. A lot of it has to do with that. Now, there have been a few attempts, by the way, to think about this in the past, but really, I think it’s kind of coming to the fore because you’ve got that extra impetus to do it from having those technologies.
Nick Earle:
Do you think the adoption and the wide availability of eSIMs with eUICC standards, so the fact that suddenly, you actually can now, for the first time, have a serious attempt at producing a single SKU for a global deployment, has actually put more requirements? I mean, Larry, feel free to answer this. Do you think that has amplified the need to focus on the device, the fact that you can now in theory have a single device that works anywhere in the world?
Matt Hatton:
Well, there is a substantial element to it in as much as every device rolls off the production line with some connectivity baked into it with eSIM. Now, that might only be a bootstrap IMSI, but it does have some connectivity baked in. Therefore, the two things, the device and the connectivity, are inextricably linked from the point of production of the device rather than it being something that is plugged in at a later date. So that focuses everyone’s attention, not least because you’ve got the likes of TELUS and Dell doing quite well off the back of being able to sell that bundle of hardware with connectivity where previously they didn’t so much. They did a little bit, but not to the degree they do now. So I think it does drive the market somewhat in as much as you kind of linked those two things. Not ready to…
Nick Earle:
Larry, I know you’re dying to chip in.
Matt Hatton:
Yeah, let me step back.
Larry Socher:
Let me give a personal perspective on this because after 26 years at Accenture, I would come to the next problem, and I’d say, “Where have I seen this before?” So when we got to the web, I’m like, “Okay, 3270 mainframe.” There was always patterns. They looked the same, and there was uniformity. I’m like, “How did we solve this last time? How do we take the new technologies and apply it to this?” I always had a ground in basis, and I think people who’d been in the IT industry as long as us can relate to that, “Hey, we’ve seen this patent before; it’s not new.” The interesting thing about IoT is it’s so highly distributed. Every use case is unique as Matt has described very well in this white paper. I’m solving it again. I have to solve it differently every time, so we’re not on solid ground there.
We can’t say, “Hey, where did I see it.” Now, there’re patterns and there’s stuff that we can relate to, but they have to be tailored and customized in a way that we’ve never seen before because of the highly distributed nature, the different places for processing. Technology innovation, you think about computer vision pushing to the edge and edge compute. So, I think we’re at a point where we don’t have anything to lean on. What’s interesting is the guys who have been around this for a while do get it. I mean, I look at Ian, Paul, John, our technical guys who’ve been doing this from their days of setting Zigbee in the digital home, so they do have stuff to draw on. But a lot of people are brand new to IoT given its nascency, and they’re looking at one of the most complex environments or sets of patterns that we’ve seen.
Part of the reason I came to Eseye was I’ve done years of cloud and network. What problem was new to me that was difficult to solve, and Eseye was trying to solve that. I think a lot of these people just haven’t been through it before. They haven’t had the integration challenges, the different network challenges that guys like Paul and Ian have seen and haven’t solved before. I think that’s where they’re starting to look for help, I think. I don’t know if that’s important.
Matt Hatton:
Do you wonder whether that… More than wonder, I think that that requirement for customization and effectively some element of holding the hand of the customer as they walk through the process of deploying this thing means that this isn’t a market that goes the way of cloud compute. It doesn’t all get eaten up by Microsoft and AWS because it’s not infinitely scalable, not by a long shot.
Larry Socher:
Exactly.
Matt Hatton:
That means it needs specialist companies who understand the space to work in that space. If all you want to buy is some cloud storage, well, why would you go to one of the little guys? You’d go to a big guy because they’re the cheapest ones. Well actually, there’s a few exceptions to that rule, but broadly speaking, that’s probably true. But if what you’re trying to do is something slightly specialized, then you wouldn’t expect to go to the equivalent of-
Nick Earle:
I would add to that, Matt, we totally agree because you can go to Amazon Marketplace, type in IoT connectivity, and you get every M&O in the world, and it’s sorted by price per megabyte. If it was that easy, there’d only be the hyperscalers, AWS and the Azures, in this market, but there isn’t. So, all of these things keep on pointing back to the same point. The one point I’d like to finish with… Because I know we could talk for a long time, but the one point I’d like to finish with is that yes, of course it’s all about the device. We’ve shown that. We’ve proved it. We’ve made the case from 10 different angles. However, if that means that somebody has to spend 10, 20, 30, $40,000 on consultancy, then they won’t do it.
So in other words, if you say, “Well, yes. Okay, I’ll buy it. I’ll buy it. It’s all about the device. It’s all about the optimization of the firmware. I’ve got to think about my battery life management. I’ve got to think about switching, localization, roaming, I mean, all those things. But I have to spend $40,000 because you’re telling me it’s a consulting business, then you know what? I’m not even going to do my project.” I personally think that’s one of the reasons why a lot of large global deployments haven’t happened because people are saying, “I don’t have a budget for that.”
Now, with SMARTconnect, and I’d like your view on it, Matt, what we’ve tried to do is say, “Well, you got this catch-22. You need to do the optimization of the device, but you don’t want to have to spend… You talked about scalability. It’s not scalable to have a consultant for 10 weeks, 15 weeks working and charging you consulting rates to solve the problem. So what we’ve tried to do with SMARTconnect is codify 80% of the sort of multi-RAT connectivity rules, capabilities into a piece of firmware that can be installed on any IoT device so that you actually have got 80% of it already there, and then you do your own optimization for the last 20%.
In other words, can you take something that is the problem of doing connectivity by design and actually creates a universal application for any IoT device that solves 80% of the problem with just some tweaking on top? Kind of like Twilio did for omnichannel communications, for application developers, for smartphones, there’s an API for that. Like a Twilio for IoT. I don’t know anything about communications protocols. I don’t know how to do this. I don’t know how to solve that EV charger if Wi-Fi, then yes. If not, cellular signal strength. I don’t know how to do that. I don’t want to know how to do that, but if there’s an app I can put in my device that actually has that logic pre-coded, then I’ll give it a go. That’s kind of what we’re trying to do. It’s not easy, but it’s what we’re trying to do because that’s our heritage.
Maybe we could finish by you giving a sort of unbiased, because we clearly are, view on whether or not approaches like that are needed to solve that fundamental catch-22. Because if the problem’s at the device side, the answer isn’t buying tons of expensive consultancies.
Matt Hatton:
No, it’s not, but there always has to be an element of meeting the customer where they are rather than expecting them to come to you, right? The point you made about they don’t want to have to learn about all of the programming requirements and effectively learn telecoms, they want telecoms put into the IoT domain. It’s almost an IT/OT convergence thing, but for telecoms. They want something presented to them, which is, “You know we’re not going to require you to understand this stuff. We’re just going to deliver your data into the cloud in a manner that you want it to be delivered in an optimal way.”
So anything that’s removing that complexity and allowing the customer not to have to think about this telecom stuff… I’m a telecoms guy. I want to think about the telecom stuff. But typically, any developer internally within organization is going to understand the IoT domain, but almost certainly not the telecoms domain, so they need meeting where they are. If you can strip out some of this complexity, then it’s clearly a very valuable thing. It also plays into this idea of cross optimizing the various different elements of the proposition, making sure that A works with B works with C. Again, so that the person on the other end, the enterprise that’s deploying this, doesn’t have to worry about it. You’ve kind of made those decisions or helped them out with those decisions along the way about which carriers you’re using and all the way through to which protocols you’re using and making sure the device works with the appropriate other technology choices.
As an aside, every year, we publish our Communications Service Provider Peer Benchmarking. Little plug for that. But one of the things that we particularly noted about Eseye within that was around this understanding the device capability and putting that alongside and dealing with that alongside the connectivity when addressing the customer. That doesn’t happen with most actually. It’s something of a weakness for most connectivity providers and really thinking about the device part of the proposition. So we do think that’s a good thing.
Nick Earle:
Well, it’s very interesting…
Matt Hatton:
That’s a roundabout way of answering that question, Nick.
Nick Earle:
Yeah, no. That was great. That report that you mentioned is very useful, and I know people can obtain that from Transforma Insights and actually talking about where to obtain information. Larry, as we finish this podcast, we’ve talked about the report that we sponsored for Transforma, the Connected-by-Design: Optimising Device-to-Cloud Connectivity. If we’ve intrigued people on this podcast to, at the very least, read it, maybe you can just reemphasize where we can find that. Some of the case studies that you’ve referred to are all in the same place as well. So where do people go to get more information?
Larry Socher:
Yes, so all the information that links to the Connected-by-Design white paper, IoT Readiness framework, our launchpad services, and then all the case studies that we referenced, you can find it under the resources tab of the Eseye website, and we’ll make sure it’s in the podcast notes.
Nick Earle:
Sure. Okay. Well, listen, let’s leave it there. This has been a very good one. It’s always interesting when you have more than one guest and a little bit of crowd control, but I think it went well. I think people will be regretting that if they listened to this and they didn’t watch it on video because that is a serious golf shirt that Matt has got on, and he wears it so well. I mean, he’s rocking the golf shirt, I have to say. Larry, you’ve got a snowy backdrop behind you in your head. I don’t think you are actually in the Southern Hemisphere. It’s one of our custom …with your rescue helicopters, and I’ve got a medical background on mine.
So you have been listening to the IoT Leaders Podcast with me, your host, Nick Earle, the CEO of Eseye. We have got Larry, who by the way, is our SVP of strategy and product management here at Eseye. I don’t know whether I actually gave you a title at the beginning, Larry. But more importantly, we’ve got Matt Hatton, who’s a founding partner at Transforma Insights, one of the leading, if not the leading analyst company when it comes to-
Matt Hatton:
You don’t have to say that.
Nick Earle:
… IoT and a great book. I always say, if you want a quick read, and if you’re watching on video, Matt has reached down. There it is. It’s called The Internet of Things Myth, and I think I read it in about a couple of hours. It is a quick read, but it’s really, really good. I’m going to plug your book for you, Matt. The Internet of Things Myth is a great primer on all of these subjects. So, thanks for listening. I hope you found it useful, and we’ll be back shortly with another episode. But in the meantime, thank you, Larry, and thank you, Matt.
Matt Hatton:
Thank you.
Larry Socher:
Great. Thanks, Nick.
Outro:Thanks for tuning in to IoT Leaders, a podcast brought to you by Eseye. Our team delivers innovative global IoT cellular connectivity solutions that just work, helping our customers deploy differentiated experiences and disrupt their markets. Learn more at eseye.com.
You’ve been listening to IoT Leaders featuring digitization leadership on the front lines of IoT. Our vision for this podcast is to be your guide to IoT and digital disruption, helping you to plot the right route to success. We hope today’s lessons, stories, strategies, and insights have changed your vision of IoT. Let us know how we’re doing by subscribing, rating, reviewing, and recommending us. Thanks for listening. Until next time.
Build the IoT estate that meets your needs now – and ten years from now. It’s why global leaders trust Eseye.
