Future of Engineering: from vision to roadmap

A system of execution will go multiple steps further than that. It will activate almost real-time intelligence and it will automatically orchestrate decisions and adapt workflows. But strategically, how do you release your best resource, its efficient numbers to work on the next generation and free them from that maintenance, sustenance of those legacy products and those legacy processes. The people who are running the shows or to speak will have more of a governance role or at the very least their operational role will come down significantly. Hello, once again, I'm Brian Doherty and you are very welcome back to this special two-part episode of the Future of Engineering. And a word of advice I would suggest that if you haven't already, you should have a listen to the first part of this conversation in our previous podcast. This episode will make a lot more sense to you if you do. And to remind you, we are joined by two eminent experts in the field of engineering. Firstly, Keith Williams, who is an executive vice president and the Chief Technology Officer at Capgemonite Engineering and from the renowned industry analyst Everest Group, Akshat Vide. Now in the first part, we finished by mentioning the challenge faced by engineering leaders of assessing and understanding the revolution in technology that is underway, but you, Akshat referred to as the Nirvana Quest. Perhaps you could begin by summarising your takeaways from the first episode and where we go from here. Thanks, Brian, and happy to be here again. I need to first, the first part of this conversation was fairly digesting. It was good to understand Keith's perspective and share mine on broadly what's going on in the world of tech or what our CTO is dealing with. I think we both agreed that AI is at the heart of the conversation today and it has a variety of different angles, including AI for engineering and engineering for AI, which both have their own journeys. That said, I think where we got to very towards the end of the discussion was what we called as the Quest for Nirvana and what I had introduced was concept called systems of execution. Now, for the readers joining in a fresh, systems of execution is essentially a system which not just records, not just creates a dashboard or creates an engagement, it actually can execute on stuff. So, if you think of the world of, I don't know, manufacture, maybe. So unlike a traditional system of records such as an ERP, maybe, or if you think of that next wave of evolution of systems, which will be a system of engagement, maybe we are thinking as you're thinking of maybe mobile dashboards or any other XMR is, a system of execution will go multiple steps further than that. It will activate almost real time intelligence and it will automatically orchestrate decisions and adapt workflows and think of this as a manufacturing ecosystem. So the result of all of this will be almost predictive agile and resilient manufacturing operations. So it's at a level where some of those operations will become a lot more autonomous and the people who are running the show so to speak will have more of a governance role or at the very least their operational role will come down significantly. So, that's the evolution we are going towards, but where we concluded the last time was that that journey has a lot of hurdles obstacles and challenges along the way in a very real sense. So keep let me, let me turn this to you now. Can you, can you talk about from your vantage point of working with so many different engineering leaders who have, who have their own visions of what they want out of AI and hopefully some of them are thinking systems of execution as well? So you will see as very practical challenges that they see a lot of it. So there's, so there's, whoa, there's multiple dimensions to that, to that concept because you've got, let's talk about the engineering process itself first, okay, which is how it came across mainly when you were, when you were, you were discussing it. I think the first challenge, which I think I mentioned, I might mention in the previous talk was to do that, you have to have a, an enterprise data structure. That enables all those fancy agents to gain the access to the data that they need. And you know, it's interesting, one of the big reasons that a lot of AI projects are not progressing is because the basic data infrastructure is not there. And that's the first thing because if the data infrastructure is not there, just to a strategic level, okay, then all these great amazing ideas, just simply won't work and work. So if you do, you're going to be doing it on a very, very thin, sliced, use case approach, which it unthinks the way to address this, this challenge at all. So first of all, you've got to do it that the data infrastructure piece, right? The second thing is you talk a lot, you know, people talk about systems that are autonomous and making decisions on the road. If you look at autonomy as a concept, in terms of particularly in a product domain, or the defense domain, you always talk about levels of autonomy. And I think when we're talking about autonomous engineering process, we have to talk about what levels of autonomy we contemplating. And I think if we talk about levels of autonomy, then the Nevada becomes more realistic. You know, the fully autonomous engineering process, I just think forget it in my lifetime for a whole bunch of reasons, which is the fact of the predictability and the reliability of the software, the AI to make the right decision, the regulatory constraints around that, the liability constraints around that. So there's going to have to be in critical decision making in regulatory approvals, a significant amount of expert oversight of those type of decisions. So I think we have to talk about levels of autonomy. And then I think the whole concept becomes something that, you know, a pragmatic chief engineer could start to get their head around. I think the other two challenges that I would mention would be tool integration. What you're describing requires tool integration across multiple different departments and very, very different cultures even within an engineering company. You also need the products you're producing at the end of that to produce the data to feed back into the process if you want to close the loop, so to speak. And I think the other area is just the mix of legacy versus new. You know, for some industries where you've got very, very short product life cycles, you know, particularly if you take consumer, I can see that kind of vision emerging much more quickly than in industry where you've got much longer product life cycles, you know, the aircraft industry, you know, shipping, defense where you've got, you know, a lot of legacy type products that still have to be maintained and a lot of legacy and systems that were required to to operate and maintain them. Then I think it's going to take a lot longer than where you got a much shorter life cycle. So I'm covering the gamut of at least at every school we call it the world of engineering and manufacturing. I've had their own even areas, yeah, even areas like networks, for example, they'll have their own systems of execution, which will have a lot more autonomy built into there. Yeah, go. But you know, I agree with that. And that's what I'd come back to to I think there's two from a strategy viewpoint. I think obviously the technology in this area is moving very quickly, but I think from a strategy viewpoint, the one thing that to have any chance of implementing that Navarro at all, you've got to as I've already said, addressed the data architecture within within within your engineering business. And the second thing that you have to be able to do is instrument the products that you were producing to provide you with the data that can inform your next generation of product. And those to me are sort of fundamental prerequisites to be able to do to to to move forward on that journey. And if you get the enterprise data architecture like and you're producing products that are instrumented and providing you with useful, insightful data in terms of how they're performing and also how that can inform your next generation of products. Those are two very sensible pragmatic things that you can do is an engineering leader to set yourself on that on that journey. From my vantage point and as you can imagine, main is also a fairly wide one because in our role we work with companies like yourselves who are serving in clients and in clients who come to us for a variety of strategic and operational insights and advice that we provide to them. I think a lot of what you said sounded relatable though two things I would highlight in particular. We have at every group this very appropriate acronym that we use, which is PTSD, clearly in sync with how the enterprise leaders are feeling the pain. I mean, we've called these as PTSD process that tech, that data, that and skill that all of these will need to be paid out if an enterprise is envisioning that next state of Nirvana and trying to go off to the relic. I'll probably come back and explain more on what each of these four really have underneath. All of these aspects are not where they need to be. If you are envisioning the Nirvana so to speak, which like you also pointed so many hurdles along the way, if you are envisioning that in your state of affairs on all of these dimensions, are miles away from where they need to be, they're almost needs to be like a structural evolution to how you manage tech. And that seems like a big one. And where, I mean, I'm kind of saying the similar thing in probably a different way, but I would still call it as the second hurdle, which is I see many cTOs today still going about their, their, I mean, their vision still happens to be a little more about what can they do, say in the very near future versus something which is more transformational, which seems like to be the need of the hour. If you're, even if it is sometime in the future, if you're trying to reach there at a certain point in time, the approach that it requires, which is a little more holistic as far as the transformation is concerned, I do, I see a lot of them missing today. Many of them are hopeful to get there, but they don't recognize the, the, the distinctive nature of approach, which is required to get there. I'll just go, you just pick your upon just two words of use. I think I don't think we should use in this context a little bit is technical debt. There is technical debt for sure, but there's the technical debt and there's archaic, but in reality, for a lot of engineering companies, these are not, it's not debt or archaic or something that we can eradicate because if you're, you know, if you're an oil and gas company, you just have power plants, you know, oil rigs that have just been created decades ago, they're on the, you know, and they're not, they're not going to change. They're not, it's not like their debt or such. They're just context. And we mustn't look at the negative leaderships. They're just part of the context that you just can't, you can't remove it. It's just part of your environment. And so we have to be super pragmatic about the fact that those, those type of things do exist. They're not, they're not debt or such that just context. And you can't eradicate them. You've got to manage around them. That makes sense. Absolutely. Absolutely. And, and, you know, are, I'm kind of going back to that BTSTR coronavirus. I think those four need to be paid out fairly cleanly, right? So we have a process that which is, you have rigid, isolated, almost manually executed processes with very poor documentation. You need to evolve on that trend. You have a tech tech, which is legacy systems, siloed architecture, hard coded workflows. You need to stay clear of those two. The big one, which is data, right? The data that needs to be paid out. So you have lots of fragmented data, which is inaccessible in systems which are market. So all of, all of those issues with poor quality, I think that needs to be eradicated as well. And the last one, which is around skill, today's workforce that people have, it's killed in a variety of ways. But as far as the next, if you're totally trying to unlock the transformative potential of AI, those kinds of skills are not necessarily available in adequate quantities in the firms today. So it's good to have a vision, which also by the way, people are not truly clear on. And that's an interesting one, possibly I would love to hear from you as to our people envisioning things in the right way. But it's good to have that vision, but it's also important to recognize how far we are from it, and how holistically we need to move. What are some very practical real advice that you offer to your customers, engineering leaders who stay that as an issue and to your point, it's not necessarily about eradicating it per se. But then what's the real advice that you have on offer? That's a great question. I think the first one for me is, and it relates to your skills point that you made previously, it's about releasing your talented, highly skilled people to work on that next generation of product, on that next generation of process and not have them on spending their time working on that, those legacy products, that legacy context that you know you got to manage, it's part of your liability requirements, it's part of your, what you're custom, as customers absolutely expect of you. But strategically, how do you release your best resource in sufficient numbers to work on the next generation and free them from that maintenance, sustenance of those legacy products and those legacy processes? Because if you can't do that, you're stuck in the near term and you're stuck fighting for the right people to work on that that next generation. There's lots of ways that an engineering leader can do that, they can use companies like ourselves, for example, to offload that legacy work. Just be clear, just meaning that works not important, it's fundamental to those companies. But is there a more efficient way that releases both money and people and enables you to focus on next generation? That is the first area. I think the second bit of advice I would see is just making sure that from a resources viewpoint and the way that you allocate a capital, you don't get drawn into too much hype. Whatever the new technologies at the moment that promise is really looking to the hood and see what's really going on from a scientific viewpoint are the really scientific hurdles that have not been solved, which means that regardless of how many billions of being thrown into this at the moment, it's not going to get fixed very soon. Is the scaling problems of this technology really scale yet and how long is it going to take or is there an ecosystem? I mean, take hydrogen. There's a lot of huge amount of resource and hype put into hydrogen. But really, to get hydrogen to work for an engineering company, you've got to align an awful lot of different parts of a value chain to do that. And for most engineering companies, it's just not viable at the moment. So that's the thing, it's about seeing through the hype for the products as I should, and releasing your people from legacy and system and work. Yeah. I think on your first point, which was, in a way, I can probably use that word, "Kawawa" as we often use in engineering context. That's been tried fairly often. It's not something that we see every other day, but it has happened many times when engineering leaders and CEOs have identified areas which are context but not core anymore. They can't live without it. They need to sustain it at times. There are customers who are on a certain platform or a certain world or a certain product, which may not be as critical for their future, but they still need to continue investing in it. I think those models do exist and we've seen lots of enterprises go down that route and companies like yourselves helping those clients in those journeys. Those have been, by the way, interesting journeys. I wouldn't go there today for using our time a little more structured way, but those have been interesting journeys. Not all of them have been successful. That said, I think your other point, which was around seeing through the hype, I think that's a very important one, right? If you are a CTO and you're trying to separate the signal from the noise, it's probably one of the most important jobs that you have. You have to as a CTO or to distinguish between what is a marketing promise versus the technical feasibility. What's the future potential of something which you are getting interested in versus what is the current readiness to our point earlier on the PTSD? What is the actual business value or customer value? All of these are very real questions. I've often seen people use three sort of filters to speak, as far as seeing past the hype is concerned. I think first one is clearly maturity, right? If you're thinking of a technology, is the tech stable or really evolving by the day, which by the way seems like it's happening with some of the more recent advancements in technology every week. We see something new and foundationally. You know, sort of novel come up right are they are there prone deployments Which already exists. So that's it. That's a good one. Does the tooling or you know dev ecosystem exist and is it strong? So that's the that's those are some good majority questions to ask for then you've been equal to as probably the The second filter you can think of talent availability. I mean you may have all the aspirations in the world But if you don't have the people or if you can't fire them and train them. How do you how do you go about it? Is the community really deep today or is it a shallow one and then third there is an operational Question as well that what what kind of Bird and wood going a certain technology Technology's way put on the existing state of affairs, right? So what kind of complexity? I mean get created in the near future and that's where by the way having that vision world which is longer term Versus what needs to be done over the next six to 12 to 18 months those Especially in times like these Possibly need to be two different visions and paths that you need to go for Okay, there's caught a lot to unpack there and just to come back at one point, you know when I was talking about Fringert resource and I mean I mean all resource whether it be people Capital etc to work on no it's not just about car vets for me. I think that's that that's definitely not just what it's about It's about how can you use Connector how can you really use automation for example? It's not just about car vets about it's about automation and It's also about maybe there are some changes that you can like to Legacy equipment that actually significantly improves your ability to maintain it or if you add a particular sense As suddenly you can you know the the reliability of that particular object will become much better So it's not as simple as car vets it is much as a much more there's more more tools in the box if you like for being able to do that Then then simply the you know the car vets in terms of your your Later point about seeing through the hype. Yeah, I think this is really important. I think it's really It's really quite it's really quite difficult and I think you're right. I think what an engine leaves do is to focus on the trend So a good example of that for me would be would be electrification so To me electrification is a cool trend that we see in engineering and it's a cool trend that you see in most products within within the domain Now every every week you'll see some new battery chemistry that you know achieve some headlines about You know how much more efficient it is or perform that it is than the previous one but ultimately You know people have invested hundreds of millions of of dollars in in factories to build particular battery chemistries okay, and None of the big but a battery manufacturers are gonna suddenly write all that Off their balance sheet just because some new battery takeers come along So if you look at batteries what you can actually be sure of is there will be slow and steady Progress because at the moment there is a strong coupling between the factory and the chemistry until that link is broken and Basically factories can produce multiple different kinds of chemistry that you'll only see gradual improvement in battery tech So you need to embrace it, but you can adopt a strategy of saying right We will gradually will gradually improve is not gonna be some you know Breakthrough that suddenly gonna rush on the market because I just don't see how that can happen So I think it's that kind of discourse that you need about each of these tech each of these tenons used to work out what your fundamental response should be to it The strategic level. Yeah. Yeah, I hear you. I think that's a that's a very good point. In fact At every group we've been doing some very interesting piece of work. We call it Future casting which is helping Companies and leaders especially in the space of technology Figure out how some of these technological evolutions One way to the stand today be what's the future likely going to look like and of course It is at a certain level while we analyze it's something in the future, right? There are multiple scenarios possible and it's important for enterprises to appreciate those and then in a way Back cost as well to figure out what it means for for them today So I mean realize we are probably at the top of the hour. I'll I'll turn it back to you Brian, but Keith Fantastic Stephen to you Good lotics for me And hopefully this was an interesting discussion for you to having now Yeah, having having now Wish we had more time. No, but I think it did great. We've solved for world hunger and we've solved all the troubles of CDOs Around that node we can probably turn into act to Brian Thank you gentlemen both of you it has been amazing to you know almost two eaves drop on on you two Industry leaders having this conversation some some really powerful food for thought there So thank you to Keith Williams from capgemonite engineering and act chat by it from the Everest group for your insights and guidance Well, that's it for this episode of the future of engineering if you want to discover more about our discussion here today Search for capgemonite innovation mandate or visit www.gemmonite.com. Thank you for listening. You