10年使える計算プラットフォームの選び方 ― IDEMIA の Kyle Larson 氏に聞く

Welcome, everyone, to the Emerge AI in Business podcast. Today's guest is Kyle Larson, VP of AI Enablement and Cloud Services at Ida. Kyle joins us to discuss why the separation between hardware and software teams no longer holds as vehicles, machines, and connected devices take on more software and AI. He explains how teams that optimize only for their own size end up working against each other and why the customer optimally absorbs the cost. Today's episode is sponsored by Nips. A quick note for our audience that the views and opinions expressed by Carl on today's program are his own and do not reflect those of idemia or his leadership. In this episode, we cover why hardware and software can no longer be built on safer tracks. To go deeper on this topic and learn how consultants are winning business with evidence-based AI ROI and building long-term capabilities instead of saving short-term gains,

download our free PDF report, Three Keys to Thriving in the Coming Era of Automation, at emerge.com slash cok1. That's e-n-e-r-j dot com slash c-o-k-1 to download your copy. Now the conversation with Kyle. Kyle, welcome to the show. Thank you. Thank you for having me. A very interesting conversation and something that we might not be speaking about enough today. So I'm going to really try and give our audience members the best view, the best experience of this and also try to keep it practical because this is one of those conversations that tend to get technical from time to time. So with cars, factory machines, everyday devices, all of it running on far more software than

we saw about, what, five years ago. And unfortunately and fortunately, the growing part of that software seems to be AI. But the hardware that the software runs on is still often planned and built on its own track by a different team, having a complete different timeline. So I'd love to start with what you've seen in that space. As vehicles, machines, and connected devices take on more and more software, how has the relationship between the people building the hardware and the people building the software changed? Yeah, no, this is a great topic, one, because you're right. It has changed year by year, the integration of software and hardware, and not only the amount of integration, but the speed of change as well, has really made this a pressing topic that I think doesn't get enough attention. So one, thank you for bringing it up. So yeah, I think the days of hardware and software being completely siloed and separate are probably gone at this point. It's really more of a continuous partnership that we need to start thinking about between

the two. That doesn't mean that the same team has to do both of them. That doesn't mean they have to be all on the same development schedules. But it does mean that we should be looking at hardware and software as one product shipped to a customer. Because at the end of the day, that's what really matters is what the customer receives, right? You mentioned a couple of good examples there. I think vehicles and machines certainly are where we're seeing a lot of this. You know, I was at AWS. I was helping build out their industry verticals. And two of the most important were certainly automotive and manufacturing, where this came up all the time. And as we moved beyond sort of these developer cloud services, which AWS is famous for, into more of an end-to-end use case like connected vehicles, autonomous driving, smart factories, you couldn't have that software conversation independently of a physical environment anymore. We couldn't at AWS and our customers couldn't out there in the field because they're too connected. You know, where's the processing going to happen?

This is a critical question that now a lot of people are wrestling with. What has to respond immediately and what doesn't? What happens when connectivity drops? Those are all decisions and constraints that require hardware and software teams to be aligned in order to deliver something of value to the customer. Yeah, and if those teams aren't aligned, if the two teams only really meet at the end of the combined project, where do we see surprises show up? Is it normally on software side? Is it normally on hardware side? Is it both? What's happening there? I think it's ultimately the customer that suffers when that happens because you have this dynamic between software and hardware teams, right? Software teams will often design to optimize for software, for efficiency, for performance. without necessarily taking the real-world application and hardware into account, is how we've historically seen this. And then on the flip side the hardware team wants to optimize for efficiency on their side which means that maybe they not building the right amount of memory and compute and environmental factors to support the software So you effectively have

these two opposing teams, one that's trying to optimize for software, one that's trying to optimize for hardware, and they can conflict with each other if you're not looking across both of those simultaneously. You also mentioned the different decisions that, you know, the different teams would have to make. So how do teams decide what runs inside the vehicle and what runs in the cloud? Yeah, so that boils down to a couple questions. And it's certainly in vehicles because, you know, autonomous driving, can you imagine if the connectivity drops and the car can't drive itself? But there's, you know, lots of other examples where processing on the edge in the device itself is important. And really, it boils down to a couple things. So So one is reliability. So, you know, cloud services and going out to, you know, cloud-based platforms for connections is reliable, but it's not as reliable as if you just run on the edge on your machine. And then the other one is latency. You know, there's a lot of instances where any degree of latency

is unacceptable for the workload, and those you need to figure out how to run on the edge. That being said, that doesn't mean you have to ruin everything on the edge. You have to segregate what really matters in terms of the latency, the connectivity versus what you can actually do more efficiently. Lots of things impacting that decision as well. So with AI helping, obviously, you know, if we had to make changes to software, a software team can build new features within days at this moment, and that's even giving them more time than they probably need. But if we have to think about developing something like a new chip, that still takes years to design and to build and to get ready. So somewhere between those two speeds, something has to obviously give. So AI is shrinking how long it takes to build and change the software. But what has to change underneath so that the hardware and the tools that developers rely on can keep up with that? Yeah, that's a great question. Because to your point, software, you know, naturally goes faster than hardware.

often, and AI is doing nothing but accelerating that. So, you know, we have to keep in mind that the software development, when we're talking about these integrated platforms of software and hardware, right, is effectively one milestone in the entire customer delivery. And so AI can certainly accelerate that development, but the customer doesn't benefit until the whole capability reaches them. And so leaders have to be looking across that entire path from an idea through a software development to the hardware to the deployment to get something working in a customer environment. Let me give you an example. So at Ademia Civil Identity, where I am now, we work with the majority of states in the U.S. And so AI has certainly increased the pace of our software development. That's indisputable. But if you think about environments like a state DMV, for example. You know, delivering capabilities to that environment still depends on getting the right equipment into an office. You know, maybe we're talking about the cameras, the printers,

even the types of computers that they're running there can make a difference. We have to integrate the software in it and make sure that the service works not just for us, but for the customer on site. So the finished code of software development is just one milestone in that process, as I mentioned. So the rollout needs to think through software, hardware, and operational readiness, because you don't just get something to the customer, you have to be able to support it for potentially years. So is there a perfect world where developers can write and test software before a chip even exists or before the hardware is ready? I think wherever possible, you have to at this point. The difference in speed between software development and hardware development means that more than ever, the developer tools can't be second-class citizens. And so we can't wait around for a physical prototype to find out that our software doesn't work in reality. And so there's lots of ways that

you can give teams of developer tools to access that, whether that's debugging, automated testing, smaller prototypes. There's certainly API replication and different services that you can use. And then in some cases, digital twins, where you're effectively replicating the physical environment of, say, a manufacturing plant based on the real data from the equipment. That gives your team the ability to, you know, it's not going to be the ultimate test. The ultimate test happens when you deploy. But it can help teams explore, you know, how software change can affect throughput or bottlenecks or equipment behavior and give them that faster feedback that the pace of software development requires And how worth it is that Because from our research we had a few leaders saying you know what simulation is in silicon So an engineering leader would say something like you know virtual models always miss something There always a bug that we did not pick up or something that we only pick up after the actual hardware has arrived So is it worth it to do the simulation What is your opinion about that

I think it's absolutely worth it because, you know, the thing that would be worse than testing something in a virtual environment and missing a couple of bugs would be not testing at all and finding all of your bugs when you go to production. And so I think it's absolutely a worthwhile effort. It's imperfect, and I don't think it ever will be perfect because the physical world makes a whole lot of difference. But at the same time, it certainly can catch a lot of the bugs and constraints that maybe we would miss. And I'll give you another example. We develop mobile ID, mobile driver's license solutions for states. And the software is relatively straightforward. It's a standard platform. All the underlying services are there. but depending on whether you're on an iPhone 17 or a Samsung or what type of device you are, it can make a big difference. We have to test for that. And so we can use a service like, say, AWS Device Farm

to do the mobile testing virtually, and that helps us catch a whole lot of constraints that we may otherwise be not aware of. But then ultimately we have to get it on people's phones at the end of the day, and then maybe we only have 20% of the bugs left to resolve at that point. Yeah, so that sounds like we'll get to launch that a lot quicker if we have 80% of the problems already solved before the actual hardware arrives. So if we're thinking about this ideal world where hardware and software do not live in two different rooms anymore, obviously the entire development plan changes. The way that we prepare for development also has to change. So what should a developer have on day one to start building for a new device now that wasn't really necessary a few years ago? Yeah, so I think a lot of it comes down to having a visibility in both directions. So software developers should be able to see the roadmap from hardware, whether that's a supplier's hardware or an internal team's hardware.

And vice versa, the hardware team has to understand what's coming down the pike from a software to make sure that they are designing not just for what they need now, but what that software might need in the next two to three years. And so part of it from day one is giving an end-to-end roadmap and visibility between those teams. And then the other piece of it, I don't think we can underscore enough, is the developer tools they have to have access to. So ability to test, if not on a physical device, and as close as a virtual simulation as we can. And also, you know, real-time feedback from what's in production today. So the more that the developers understand how the existing environment works and what types of changes affect what types of outcomes, the more informed they're going to be as they make future changes for the software. Yeah, that makes a lot of sense. Lots to think about there as well. So imagine a leader at a carmaker or a robotics company,

someone that's about to pick the chip platform that their entire line will run on for the next 10 years because that's being less than right. Yeah, it's loaded. So comparing the spec sheets between what they need to choose, that's going to be one long meeting in one afternoon and it's done. But the toys that they make, they need to live with for a decade. So for senior leaders listening, how should they approach choosing the compute platforms that the products will run on for the next decade? So I would say first, don't, if you can all avoid it. If you have any means of reining that in, whether that's on-demand services or something that's more short-lived, that would be the approach to take because it's so difficult to predict what software is going to be like in the next seven or eight years. That being said, there are certainly instances where that's unavoidable and you do need to make a long-term commitment. So when leaders do that, they have to approach it as a product commitment long-term, right?

You're choosing not just a service that's deploying today. You're choosing the foundation that your teams are going to build on. They're going to support. They're going to improve. And so the question is, how much room do you need to give yourself to evolve? And that's an educated guess based on your business. So let me give you an example. You think about access control systems in buildings now are increasingly AI enabled. So you have a camera, you have local compute there on the edge like we talked about. You have software that establishes a person identity and whether or not they can get into the building So the hardware decisions that you making on those access control systems you don want to make frequently because you don want to be constantly replacing your hardware But at the same time, the pace of an AI service like identity recognition is constantly evolving. And so leaders have to not just look at what's today, but they have to look at where the market is likely to go, where capabilities are likely to go,

and make sure that the hardware does not become the bottleneck to the impact and evolution that they need for their products. And how do we do that? I mean, how would you test whether a platform developer ecosystem is real before you commit to it? What's the question that you need to ask? Or what do you need to see to confidently make that decision? Yeah, so I think, you know, one, you work backwards from what the product has to be able to do, how quickly, under what conditions. You evaluate them against what you're going to see in production, whether that's realistic workloads or failures. And then you support that hardware decision with the development tools and the software capabilities and the engineering skills and the supplier support that you actually need because it's not just a hardware decision. It's the ecosystem around the hardware that's going to determine what's successful. And then I think the other piece of it is the supplier really matters.

And so you need not only reliability from a supplier that you're taking a decade's worth of commitment on, but you also need access to their roadmap and confidence in what they're going to support in the future so that you can both make the right cost and the right innovation decision for that hardware. yeah so it's not just about our listener thinking about the future it's about making sure that whoever they partner with also has a vision for the future and has the same idea is that the right conclusion there spot on yep so come from my notes and i'm not even going to show you what they look like it's all over the place but it's very clear that the pain point is that customers will pay for the gap between software and hardware living in different rooms and living in silo. And AI solves that by allowing things like simulation, where we detect almost 80% of the bugs up front, and that helps us a lot. But I really like the last part where you said, pick a processor platform based on its developer ecosystem, the tooling, the safety files of what

they have envisioned for the future with thinking about where the software could go and doing proper research about that. I think it's not a decision that you just need to make in an afternoon, because it's going to stay a decision for a very long time. Thank you so much, Carl, for participating in today's conversation. Any last words that you'd like to leave the audience with? No, I think, number one, don't ignore this topic, you know, if it's relevant to your business. I know that AI is the front of everybody's minds, but this integration of software and hardware will continue to be critical. And, you know, I would say to never think that there's a world where hardware and software are going to move at the same speed. We're not going to get there. But the responsibility for leaders now is to connect the two through a single product roadmap, early feedback, shared accountability for the teams. And that's ultimately what's going to turn good ideas into. Great final thought. Thank you, Carl. Thank you for participating. Yeah, absolutely. Thank you.

Wrapping up today's episode, let's look at the three key takeaways from our conversation with Kyle. First, hardware and software should be treated as one product delivered to the customer, with a shared roadmap and shared accountability even when the teams run on different schedules. Second, developer tools and simulation can no longer be an afterthought because testing in a virtual environment before physical hardware arrives catches most issues early, even if it never fully replaced the three-a-wall testing. And finally, long-term compute decisions should be judged on the ecosystem around the hardware, including development tools, supplier support, and visibility into the supplier's roadmap, not on specifications alone. In this episode, we covered why hardware and software can no longer be built on separate tracks. To go deeper on this topic and learn how consultants are winning business with evidence-based AI ROI and building long-term capabilities instead of chasing short-term gains, download our free PDF report, Three Keys to Thriving the Coming Era of Automation

at emerge.com.co.uk1. That's emerj.com.co.uk1 to download your copy. For further executive level analysis and to join our network of leaders delivering workflow impact with AI, visit emerge.com. On behalf of the team at Emerge, we'll see you on the next episode. Thank you.