NETWORKING

Amol Ajgaonkar: When you dive into solving any solution and say, “You know what? This is a great candidate for IoT or intelligent Edge.” The one thing that needs to be answered before you do anything, or even touch any device technology, is “Why am I doing this?”

Kenton Williston: That was Amol Ajgaonkar, CTO for Intelligent Edge at Insight Enterprises. And I’m Kenton Williston, the Editor-in-Chief of insight.tech. Every episode on the IoT Chat I talk to industry experts about the issues that matter most to systems integrators, consultants, and end users. Today I’m talking to them all about the reasons IoT projects fail, and how you can avoid the biggest pitfalls. Did you know that up to 75% of IoT projects fail to meet their goals? Sounds scary, but, once you know a few of the industry secrets, you can join the successful group. In fact, I think one of the biggest secrets is just rethinking what success means.

So, Amol, let me welcome you to the show.

Amol Ajgaonkar: Thank you.

Kenton Williston: I’m really interested to hear more about what Insight does. And, of course, it’s going to be a challenge for our listeners, because I’m with the publication insight.tech, which is not at all the same thing as Insight, the company.

Amol Ajgaonkar: You’re right.

Kenton Williston: Why don’t you help clarify which thing Insight does, and what your role is there?

Amol Ajgaonkar: Absolutely. Insight Enterprises is a Fortune 500 company. In simple terms, essentially we do everything—right from procuring hardware, to imaging it, to installing it, to building the solutions that include mobile, desktop, web applications, AR, VR applications, to data and AI. Building AI models as well. And then managing those solutions—not just the hardware, but also the software for our customers. It’s a true end-to-end, service-oriented perspective.

Kenton Williston: Fantastic. What do you do as the CTO for the Intelligent Edge? What exactly does that mean?

Amol Ajgaonkar: That role, essentially, is helping the customers understanding what the requirements are, understanding what challenges they have, and then coming up with the right approach to make sure that our customers are successful, the solutions we build are successful and scalable as well. So, my job is to come up with a strategy and vision and understanding of what the market might need in the future, but also helping our customers be at the edge of innovation.

Kenton Williston: Well, I’m really interested to dig in more to that aspect of how you put a strategy together. But first, I want to talk a little bit more about this idea of the intelligent Edge.

Amol Ajgaonkar: Mm-hmm [affirmative].

Kenton Williston: This is certainly a huge focus area for IoT projects right now. When I think about the intelligent Edge, immediately what comes to mind for me are things like AI—which has become huge in just about every market segment. What does the idea of the intelligent Edge mean to you?

Amol Ajgaonkar: That’s one, right? AI is one use case for the intelligent Edge. But if you look at the data that is being generated right now, this is across industries. You’d consider manufacturing. You take into account retail, energy, healthcare—and you look at all the devices. You look at how people are interacting, you look at all the processes that are in place. All of those entities are generating data. Now, if you consider the amount of data that’s being generated right now, there is some intelligence in that data that can be taken out and made actionable. So, intelligent Edge for me is processing that data where it is generated, and then correlating that data with other data sets that are also being generated in that same area, right? Geographical area. And being able to provide actionable insights back to the users so that they can do their jobs.

Kenton Williston: Got it. Totally makes sense. And I think it’s pretty obvious why so many industries—you named just a handful of them just now—are so interested in IoT in general, and, in particular, in doing processing at the Edge to make better use of that data that’s available there. The value, I think, is really clear. But I have seen, despite that—despite how important these applications are—that a huge number of these projects fail. I’ve seen numbers as high as 75%, in some older studies. More recent studies I’ve seen—numbers upwards of 40% are considered to be unsuccessful. So, why do you think it’s the case that so many of these projects are ending up as failures?

Amol Ajgaonkar: That’s a very good question. I believe they fail because the definition of success hasn’t been defined. So, if you don’t define what success means for a certain use case, it is bound to fail. And that’s why, when you dive into solving any solution and say, “You know what? This is a great candidate for IoT or intelligent Edge.” The one thing that needs to be answered before you do anything, or even touch any device technology, is “Why am I doing this?” If the “why” is defined, then your solution is bound to be a little more successful. I’m not saying that if you’ve defined the “why” and you know what the ROI is going to be that every project will be successful, but at least you know that you’re going in the right direction.

So most of the time that they will fail is because they have unrealistic expectations from technology. They haven’t defined the “why.” They haven’t defined the ROI for that use case. So, once they prove it, and they have a pilot running, and they look at all of the services—all of the tasks that need to be taken care of before it goes into production—they look at the cost of that, and they’ll look at the ROI and be like, “Maybe it’s not worth it. Maybe I shouldn’t have done this.” Right?

Kenton Williston: Got it. I’m going to start keeping a little list here of some of the dark secrets—the dirty secrets that don’t get discussed enough. I’m going to make a point here—the number one is: you’ve got to know why you’re doing it. And right along with that—what success actually looks like. So I want to ask you about another thing that I suspect is going to be on your list. We’ve talked already about what intelligent Edge means, but of course the whole concept of the Internet of Things is about connectivity. It’s right there in the internet.

Amol Ajgaonkar: Uh-huh [affirmative].

Kenton Williston: Part of the name. I think this is one of the things that makes it really interesting. I, myself, come from, originally, an embedded-engineering background, right? And I think back to kind of the old days, where you would develop a system that oftentimes would be meant to just be left alone to do whatever it was going to do. It was very self-contained. And that’s really not at all what IoT is about, right?

Amol Ajgaonkar: Mm-hmm [affirmative].

Kenton Williston: It’s about that connectivity. It’s about taking that intelligence and sharing it out more broadly. So I suspect that part of what is happening here—in terms of why things go wrong—is that people might be getting stuck in kind of that older thinking of, “I need something to happen in my manufacturing facility. So I’m going to deploy a device that’s going to do its thing. Problem solved.” But really, that’s a wrong way of thinking about things. And thinking about a point solution at the Edge is really not thinking through things far enough. Would you agree with that?

Amol Ajgaonkar: Absolutely. I mean, there is a value for point solutions, right? Nothing against point solutions or collecting data, but the real value of an IoT solution or intelligent Edge solution is to be able to look at that data holistically. And now, on top of that, like you said, the Internet of Things—it’s connecting all of those together, and being able to control those actions as well.

Kenton Williston: Mm-hmm [affirmative].

Amol Ajgaonkar: It’s literally in milliseconds or nanoseconds that something happens—the system looks at the data, says, “Oh, I know what happened. I’m going to predict this could happen, and I’m going to change so-and-so parameters on this device.” So either it stops working, it changes its speed, or does so many different things. I don’t want to use self-awareness, because then it sounds AI-ish, but essentially the if-then kind of possibilities also come into place.

I think correlation of those data sets, being able to put all of those together, giving a holistic view—not just from one location then—right? So, connecting back to the cloud and being able to collect data from multiple locations, and using the inferences and actions taken by humans, actions taken by machines—and then bringing it all back to the cloud, and then analyzing that data holistically across locations—providing a much richer actionable Insight. And then pushing that expertise back into those locations, so that now the local AI models that are running are running smarter, because now they have additional data that has been provided for training and the model has improved accuracy, or is taking into account variance in their independent and dependent variables.

Kenton Williston: Makes sense. I’ll say number two on my list is just think beyond the Edge.

Amol Ajgaonkar: Mm-hmm [affirmative].

Kenton Williston: The next thing that comes to mind when you’re hearing all of the complexity you’re describing is, this sounds like a big chunk of work to bite off. And that gets me back to the question I wanted to ask about what you mean by having a strategic approach. So can you talk to me about that? What does it mean really to go beyond thinking about the solutions you need to deploy, to having an end-to-end strategy?

Amol Ajgaonkar: Absolutely. The strategy for any deployment of an Edge solution has multiple facets to it, right? Like I said, first to find the “why”—understand why you’re doing it, what is the ROI, what do I expect to happen? Once you have that in place and documented, understand which teams need to be involved as well. Not just the teams that are going to work on the pilot, but also the teams that are going to be affected by that solution in the future. Because you need to have the right buy-in from those groups as well. Because otherwise they will not adopt it. If they see this solution as something that’s going to add more work for them, they are going to resist. Humans resist change. So if you bring them on board earlier on and understand their pain points, understand how a certain solution is going to affect their day-to-day job and if it’s going to make them successful—they are going to provide more data to you, right?

Kenton Williston: Mm-hmm [affirmative].

Amol Ajgaonkar: So, getting those people on board is a good way to start. Then, looking at the physical landscape, “How many devices do I need? What type of integrations do I need? What type of data sets do I need? Who’s going to give me the data? Where can I get the data from? Is it a machine? Is it a human input? Is it cameras? Is it existing infrastructure that’s already developed? Is it the environment?”

All of those data points have to be listed out, right? And then, “Okay, these are all the data points that I need to make these types of decisions. If I have to get this type of data, where I’m on, where am I going to get that data from?” So you start listing it out, right? Try to get into the detailed planning of exactly where do you get the data from—who is involved, who is going to be affected by this change—and put that in your planning document.

Now, once you have that in place and you start building the solution out, as part of that you need to select or carve out a certain part of the solution—which is the most challenging part of that solution. And you prove that out. And so, once you have an acceptable rate, success rate in that, and you know, “Okay, if I get this type of data, I can make these decisions, visualize these decisions this way, and these are the people who will be engaging with the system and using that data.” So you put that thing holistically in place as the pilot. Once the pilot is successful, that is where—like we mentioned—we have to think beyond the Edge, right?

So if you want to take it to production, you have to think about scale. You have to think about security. I mean, security—you have to think about right from when you’re planning, and exactly how you’re going to secure the devices to how are you going to secure the software stack, the OS stack, as well as physical security. But when you get into production, it should have even more focus on security—as exactly, “If I were to ship this out to 10 locations, who is the person that’s going to install that? Where will it get installed? What type of security concerns will I have at each location if somebody were to just take the device and run away? If somebody were to try and plug a USB device into it and try to get access to it, what then?” All of those questions need to be answered, right?

So when you’re trying to get to production, you have to then plan the security aspects of it. You have to plan, “Where will I procure those devices from? Who will image those devices?” Because you’d need each device that’s coming out and being deployed to be the same. So you get consistency, then, at that point. And this is just all pre-production, right? You haven’t even reached production then. Once you have the procurement, once you have the installation, once you have the imaging, you have your security strategy in place—then comes deployment.

The first time you’re going to deploy, you try and deploy to one or two locations. As part of deployment you have to plan for who is going to deploy those—what kind of effort is required in deploying a solution like this? Is it cameras that you have to go and install? If so, do you have the wiring in place? Do you have the electrical in place? The networking in place? Is your networking infrastructure capable of handling the additional load? Will that affect any other existing systems that are already in place, right?

All of these things have to be planned before you start deploying to production. And some of these things are missed. Going back to why projects fail—if some of these things are missed in planning, and so when they actually deploy, then they realize, “Oh, for this, I need to upgrade my network.” Or, “I don’t know who’s going to install the cameras, or who’s going to integrate into the PLCs.” And so on and so forth. So all of that needs to be planned.

Let’s say we have all of that planned, and we’ve deployed now to one or two locations. Then comes, who’s going to manage these, right? Once it goes out of your facility and the solution is in production and it’s at the location—well, it’s on its own.

So now you have to think about, “How am I going to manage these?” The devices, as well as the workloads, the software that’s running on it. And when I say software, it includes the OS. “Who’s going to patch it? How are we going to patch it? What is our strategy for patching?” And if something were to change and I need to update my software stack—let’s say I’ve got containers running and I need to update those containers, how am I going to do that at scale, right? I don’t want anybody plugging any USB drives into my machine to update anything. So what does that mean? And do I have the right teams in place to support a solution like that? Or should I rely on partners to come in and help me support the manageability of those devices—the end points, as well as the software stack, right?

So, management and support—or monitoring after the fact—is also super important for a successful solution. All in all, it does seem complicated. It does seem like, “Oh my God, there’s so much to do to make this successful.” But if you rely on partners, and if you have a good plan in place, it’s actually not that hard. It is just like any other project, where if you plan and do it right and take into consideration all of these aspects, the solution will definitely succeed.

Kenton Williston: Yeah. So let me recap here. We’ve covered a lot of ground. I’ve got literally a bunch of sticky notes here. I’m running fast and furiously with all these great ideas. It sounds like some of the key points where people get tripped up are—first of all, not really having a clear vision for why they’re doing what they’re doing. Number two, thinking too much about a solution, and not thinking holistically, end-to-end about how this is going to work as a system. Number three, not having a well-thought-out strategy. And the point I really liked that you raised there was about having the people, right? Like, this is not just a pure technical question, but it’s an organizational and personal kind of effort, where you need to have everybody on board and aligned with your objectives.

Number four, you need to—once you’ve proven out that the basic idea is viable—think very carefully about how you’re going to scale it, secure it, and deploy it. And again, a lot of that has to do with the “Who’s doing things?” as much as it does with the “What you’re going to do?” And then number five—there are all the questions around, “Okay, you’ve got it. It’s working. It’s successful. Now, have you thought through how you’re going to maintain and manage these devices?” And even things like the life cycle management, right? Like, eventually, these devices will need to be retired, and who and how is that going to happen? It sounds like we’ve got at least six key areas already where people can easily overlook some of the big challenges.

Amol Ajgaonkar: Absolutely. And I think I really focus on the people aspect of the solution. Because if the people who are affected by the solution don’t really think that it’s going to add value to them, they’re not going to use it. So you might actually even go to production and make sure that all of these other things are taken care of. But the reason you’ve built the solution—and for the people, right? And if they don’t use it, it’s of no use, right? It’s waste of money at that point. So making sure those people are on board, and that they understand how this is going to make their life easier or provide a more actionable data or information so that they can do their job in a much better way. Once you have them on board and help them understand that part, they will adopt. And they will ask for it, and they will give you feedback on what needs to change and what more features they would like to see in that system. And that is how that system will transform, right?

So it’s not a static solution that you build once and you’ll deploy and you’ll forget about. It’s actually a transformational solution. If you look at it that way, it has a lasting impact on the organization as well, because people get excited about the value that it’s adding, and they want to make it better. And so, that is how the digital transformation of any organization would come through—is because the people are now passionate about changing and adding new features to a solution, or adding new revenue streams. And how do I do that? “Oh, maybe we could change this solution, or we can change that solution.” Because they feel a part of that solution itself.

Kenton Williston: Yeah, absolutely. And I would go beyond that, and even say it really requires a different way of thinking about what an IoT project even looks like, right? It’s not the sort of thing where you ever really get to a finished date. Because what you’re really doing is you’re creating a platform for ongoing improvements, ongoing innovations—both from the angle you were just describing, of people contributing new ideas, and even just the devices themselves becoming more intelligent. Using, for example, as you talked about earlier in our conversation, the machine learning models to just improve the basic algorithmic performance of what you’re able to accomplish over time and have that continuous feedback loop.

Amol Ajgaonkar: Absolutely. I agree.

Kenton Williston: So, two big questions that come immediately to mind for me out of this. First of all, this doesn’t necessarily have to be a big, scary list of things to contend with. But it is a very different way of thinking about IoT projects—certainly, like I said, compared to earlier in my career about how people thought about embedded designs that were kind of very isolated. There’s a very clear “You’re done with it” at a time in the calendar. This is a very different way of approaching projects. I’m easily imagining our listener saying, “Oh, I’m really excited about everything I’m hearing. I’m going to go take this to my boss and explain how we should do things different.” And the boss just kind of like passing out in their chair because they’re so overwhelmed with everything they’ve got to do now.

So, number one, how can our listeners communicate to their colleagues “Hey, this is why we want to do things a different way”? And, number two, how can Insight Enterprises help folks execute along these lines?

Amol Ajgaonkar: So, to think about a solution, right? How do you communicate the approach? The approach has to be—first, be okay with ambiguity, because nobody has all the answers. But as long as you define why you’re doing this, everything else will fall into place in due time. So, be okay with ambiguity. It’s fine, because the problems that businesses face never come with a manual on how to solve them, right? It’s always a new or newer problem. There’s a disruption from a new startup or a newer idea, and now you have to compete with that, right? That is why a business is exciting, is all of these challenges that come up.

And so, defining what we need to do, and then going step by step—take smaller approaches, carve out a smaller piece. But even for that smaller piece of the puzzle, think holistically.

Kenton Williston: Wow.

Amol Ajgaonkar: Keep your eye on the goal. It’s a journey, right? There’s not an end state.

Kenton Williston: Mm-hmm [affirmative].

Amol Ajgaonkar: But define your milestones in that journey. I want to get to this milestone and move on from that. I just—I do that even before, when I’m working out. I was like, “Ugh, I’m getting bored.” Like, “Nope, let’s just try four more days and then we’ll set a new milestone, and then the next milestone, and so on and so forth.” So have a plan to find your milestones, and then go tackle that milestone by milestone. That is what we do as well. With Insight, we have our approach on how we go and talk to our customers, which is we try and ask them, “Why are you doing this?”

Literally, there have been cases where, when we haven’t had a clearer understanding of, “Why is that customer really doing that?” We’ve actually told them, like, “Maybe we can help you discover why you’re doing this. What is the ROI?” And sometimes by the end of it we figured out, “Well, the ROI is not really that great.” And the customer’s like, “Oh, this is great. Otherwise, I would have spent so much money trying to figure out and gone through with this, and I wouldn’t have any value.” Right? So our approach of going through envisioning sessions and understanding exactly why are you doing this—defining that, documenting it—and then communicating that message across all stakeholders so that everybody understands why we are doing this. This is part of the buy-in process.

So we get the buy-in as well. We can help in different aspects of that journey. It doesn’t have to be that Insight will do everything or nothing. Nope. We will come in and help with whatever challenges you have. If you want to define a strategy or a design for the solution, we can help you with that. And you say, “Hey, we just need that. We’ve got everything else covered.”

Great. We are happy to help in any which way possible to make our customer successful. We’ve done end-to-end as well, where we’ve gone and we’ve defined the vision for them. We’ve executed the vision for them. And when we say execute—right from integration into their existing systems, to procurement of hardware, to imaging, to installation, to monitoring of those end points, to building data and AI models that deploy at the Edge, to building mobile applications, web applications, desktop applications, applications that run on AR, VR headsets as well.

So, depending on what the customer needs, Insight can come in and help and deliver the outcome that they’re looking for. In our approach, envisioning is step one. We need to be convinced that you really are going to benefit from this solution as well. And then the customer has to be convinced that, “Yes, this is the right solution for us.” And after that, you plan for all of the things that we talked about, right? Plan for security, plan for people being affected positively by that, getting them onboard, interviewing those teammates as well, and then the technical architecture, and then planning the technical implementation or development as well. And then once it’s done, we can actually go ahead and look at support and how we can help with the level-one, level-two, level-three support.

If you need device recycling, you come in and swap the devices out. If something goes wrong—or even monitor these Edge end points and be like, “Okay, we can see that something went down. This device went down. Hey, Mr. Customer, your device went down. We already know that. We are working on fixing it.” Right? All of those kinds of support services, we can help our customers with as well.

Kenton Williston: That’s really cool. I will say though, I love this big picture of coming in with the envisioning at the start, carrying all the way through the device maintenance at the end. Awesome. Totally love it. But there’s kind of a hard reality here, which is, at the end of the day, folks are going to have to pick some point solutions, even though that’s very much, as we’ve discussed, not really the entirety of what makes for a successful IoT deployment. That is a critical step. I’m betting that you’ve seen plenty of cases where people really got hung up by choosing the wrong solutions—whether it was like the wrong hardware, the wrong cloud platform, the wrong OS—whatever it was. So, just from that pragmatic point of view, how does Insight approach that question of figuring out what are those actual solutions that go into this mix?

Amol Ajgaonkar: Right. It all comes down to two things in my mind. One is cost, right? Nobody wants to spend money building a solution from scratch. That’s why the point solutions or off-the-shelf solutions make sense, because I can just go and buy and test, and I don’t have to spend so much time and money in building a solution. Makes complete sense. When it’s a brownfield situation like that, where they might already have certain solutions deployed, we also work with those solutions to integrate, right? At the end of the day, what do we need? We need the data that’s coming out of that system. And hopefully, ideally, if we can programmatically manage the hardware or that solution that is deployed, then that’s the golden state. But at least the minimum—if we can integrate and get the data out, we can provide some more value back to the customer. So we look at integrating with the solutions that they might have already deployed.

Sometimes it actually helps as well, because if it’s a point solution and it’s a really stable, robust solution that has open APIs and you can integrate and you can manage those devices, that’s actually a fantastic place to be as well. Because what that does is allows you to separate the responsibilities of the solution. One is data collection, right? And if there are sensors with their own gateways and they have taken care of security, they have taken care of ingestion and reliability, and they are doing that with higher accuracy. We can rely on that device and that solution and pull the data in, right?

So, we do test out devices and sensors from our partners to see how they perform. Even from a battery-life point of view, what would it take to really—we push it, essentially. We say, “Okay, if I were to ask the device to give me data points every half a second, how long will it last?” And we work with the partner as well, like, “Hey, I’m going to do this. You tell me how long will it last. Would I start to see gaps in data?” And stuff like that. We in fact do work with our partners as well to bring in the right sensors, to bring in the right gateways, and then deploy those as part of our solution. We don’t always have to build everything from scratch. We rely on our partners a lot, and bring their solutions in to provide that big-picture, holistic solution back to our customer.

Kenton Williston: Yeah. I think one critical thing that I want to just dive a little bit deeper on there was a point you made about using open, scalable kinds of solutions.

Amol Ajgaonkar: Mm-hmm [affirmative].

Kenton Williston: In the interest of full disclosure, the insight.tech program is Intel owned and operated, so this is a little bit of a self-serving question. But I would imagine that the fact that you’ve got all these partners who have a bunch of different Intel-based hardware—which is very really understandable by IT departments—you’re not doing something particularly novel with the hardware. And it’s very scalable, in the sense that you’ve got things that are made for those extended-battery-life sort of scenarios you were talking about, all the way up through things that are huge horsepower, giant iron machine–sort of applications. The fact that you’ve got that scale is pretty helpful.

Amol Ajgaonkar: Right. And so, from an Intel point of view—we work with Intel a lot. And not just on the hardware side, but also on the software side, right?

Kenton Williston: Mm-hmm [affirmative].

Amol Ajgaonkar: Using the frameworks that Intel already has, like OpenVINO or OpenAMP, and looking at how they’re designed—it really helps leverage whatever infrastructure that the customer already has. Which is great, because cost is a big factor in building the solutions, right? If I can go back to the customer and the customer says, “You know what? I’ve got these Intel-based servers, or these smaller devices that I already have in my facility. Can you reuse those?” And if the answer is “yes,” it’s amazing, because I’ve just saved my customer a ton of money. They don’t have to spend money in buying new hardware at that point.

So, using OpenVINO, I can run AI models and leverage CPU and integrated GPUs, or then even add just a card to their server and say, “Okay, let’s use this FPGA.” Right? But you can start with the CPU. You don’t have to spend money at the beginning to prove out your concept. And that’s why I like the open systems, where I can integrate and I can leverage these frameworks which will add value back to my customer. Same goes with OpenAMP in being able to manage these devices. Doing out-of-band management for the devices is so critical. And part of that is—monitoring comes into play as well, right? If I want to monitor these devices that are deployed out in the field, I need to be able to do that.

I’ll give you an interesting example here. Five years or so ago, we deployed a solution out in the field. When I say a field, it’s an orchard. This was the very beginnings of Edge processing and stuff like that. So, we deployed that solution. I flew back. And after, I think seven days, somebody turned that device off. The stakeholder called me. He was like, “Hey, this is not working.” And I looked online, and I was like, “The device is not online. Can someone go in? I think it’s turned off. Can someone go in and turn it on?” And they’re like, “Well, it’s in the middle of nowhere. There’s nobody there. Can you go and turn it on?” So I had to fly back just so that I can press a button, and then fly back home, right?

If I had out-of-band capabilities on a smaller device like that with Wipro on it, I could have OpenAMP, I could have just been like, “Oh yeah, somebody turned it off. Hold on.” Click a button. And now I’ve turned it on remotely sitting a thousand miles away from that location. So it’s having those integration points, having the frameworks in place, I think really benefits not just integrators like us, but it really benefits the customers.

Kenton Williston: Perfect. Let me see if I can sum up. I think I’ve got seven good, dirty little secrets here. Let’s see if I’ve caught them. First of all, have a clear vision for the what and why. Second of all, make sure you’re thinking beyond the point solution, beyond the Edge, and think holistically about what the whole system needs to do. Third, have a clear strategy with milestones, and most importantly, get all the stakeholders to buy in before you start. Fourth, once you’ve proven out the basics of your concept, really be sure to think through how you’re going to scale it up and secure it and deploy it. And again, a lot of that comes down to who is doing this. Fifth, make sure you’ve got a plan in place for managing and maintaining all these systems over time—which, once again, like we were just talking about with your example in the airplane, a lot of this comes down to who is actually going to do this.

Sixth, keep in mind that this whole thing is a journey. You don’t really have an end goal and that’s fine, because really this is more of an exercise of opening up opportunities for ongoing improvement rather than just solving a small problem. It’s really about opening up the possibilities. And then, finally, seventh, be sure to incorporate in your thinking across all of these stages what kinds of existing infrastructure you’ve got, how to best make use of that, and how you’re going to integrate into that infrastructure to be as efficient as possible and satisfy all the various stakeholders that we’ve been talking about. Sound like I’ve got it?

Amol Ajgaonkar: Absolutely. Just to reiterate—I mean, security is a big component. And so, always think about security across all the efforts, whether it’s the hardware, it’s the software stack. And look for frameworks that have already established and been tested rather than trying to build security frameworks from scratch. It is not an easy undertaking. You’ll spend millions of dollars and still not be able to get to the level of stability that some of these frameworks already have, because they have spent the millions of dollars in years thinking about security and making it secure.

Kenton Williston: Fabulous. Any other key takeaways that you would like to leave for our listeners?

Amol Ajgaonkar: Just one key takeaway would be that it seems complicated, and it might feel like it’s a lot of effort, but truly, with the right partners in place, it makes that solution easy to build, deploy, and see the value. Maybe it’s just that I’m passionate about the Edge and solutions at the Edge, but I feel there is a huge value for our customers in building solutions at the Edge, and then managing these solutions or these workloads through the cloud for scale. So, definitely, take a look at that. It’s not all hype. There is some real value in the solutions. It’s just a matter of realizing where that value is.

Kenton Williston: Well with that I would just like to say, thank you so much for joining us. Really appreciate your insights.

Amol Ajgaonkar: No, thank you so much for having me. This was a wonderful conversation. Really appreciate it.

Kenton Williston: And thanks to our listeners for joining us. To keep up with the latest from Insight, follow them on LinkedIn at linkedin.com/company/insight, and on Facebook at Insight Enterprises, Inc. If you enjoyed listening, please support us by subscribing and rating us on your favorite podcast app. This has been the IoT Chat. We’ll be back next time with more ideas from industry leaders at the forefront of IoT design.

The preceding transcript is provided to ensure accessibility and is intended to accurately capture an informal conversation. The transcript may contain improper uses of trademarked terms and as such should not be used for any other purposes. For more information, please see the Intel^® trademark information.