i3X Explained with John Dyck and Jonathan Wise: One API to Connect Them All?

Speaker 3 (00:00) Welcome to the IT/OT Insider Podcast. Speaker 4 (00:04) David, you brought me two Johns today. Speaker 3 (00:06) I'm gonna be confused. Speaker 4 (00:09) Okay, so John and Jonathan, okay. Gentlemen, thank you so much for joining us. um We talked at Hannover Messe. So there was a uh physical interaction between us, not just a virtual one. You guys both work at CESMII We're going to talk about something very interesting, i3X. But before we start, Why don't you guys kick off with a short introduction of yourself and CESMII. John, why don't you start? Speaker 1 (00:40) Yeah, thank you for having this conversation with us. It's an honor to be with you. I'll start with the longer description of what CESMII stands for and then I'll end with kind of how we like to be referred to. CESMII stands for the Collaborative Ecosystem for Smart Manufacturing Innovation Institute. We're federally funded by the US government, but specifically the Department of Energy to accelerate the adoption of smart manufacturing and become more competitive and more productive as manufacturers. um We refer to ourselves generally as CESMII, the Smart Manufacturing Institute, because the former is a mouthful, obviously. So I'm sure there's more to come on that. That's a little bit of who we are and again, just appreciate the chance to have this conversation with you. Cool, cool. Speaker 4 (01:31) you are, John, so you are the CEO of CESMII. Speaker 1 (01:35) Yes, I'm the CEO of CESMII. been here about seven and a half years. I come from industry, having worked for several of the larger automation and information corporations here in the US and yeah, here at CESMII as the CEO. Speaker 4 (01:53) Jonathan, also welcome to the show. Speaker 2 (01:56) Thanks for having me. So I'm our chief technology architect. I've been with CESMII about seven years. Also work for some of the big industrial companies, but spent time with Microsoft and Amazon as well. I kind of oversee the architecture for all of the projects, either that we sponsor or that we help create. Speaker 4 (02:18) And like what kind of projects, what are your, let's say your activity domains or your verticals or your, don't know. Speaker 2 (02:26) CESMII's been through a few different seasons. the kinds of projects have changed over that. There was a season where we were heavily invested uh in direct projects with US manufacturers. We ran about 50 of those uh where we oversaw the architecture, helped provide the funding, but these were really, they were response teams that gathered around a manufacturer with a problem and tried to use. smart manufacturing approaches to help them solve that. So that was a really interesting kind of informative era. We'll probably talk a lot about that because I got to see 50 different projects and what worked and what didn't. But we've also had seasons where more of our investment was working with the vendors. And then throughout, I'm always working with other consortia and standards bodies kind of globally. So all kinds of projects. Speaker 1 (03:21) Yeah, I would also add that um specific to your question, we are 100 % horizontal focused on all manufacturing um from discrete through hybrid through continuous process. And also that we are. uh intentionally focused on not just the large enterprises but also the small and medium enterprises and the mittelstand as some of our friends there in Germany refer to it and so our opportunity is to uh direct the funds that we have from the federal government here to uh accomplish what we call or refer to as the democratization of smart manufacturing. How can we create accessibility for everyone and primarily through the means of reducing cost and complexity, Speaker 2 (04:12) which sounds like we're boiling the ocean, Speaker 1 (04:13) but as I think you'll see through the conversation here, we're making significant strides in that direction and accomplishing that. Speaker 4 (04:25) Interesting and yeah I think for our US listeners you two are probably a bit more known. Does your work stop at the border? The US border or not? Speaker 1 (04:41) uh Yeah, that's a great question. So um we worked for several years kind of building our own sort of approach and our Our strategy around, with our community, our members, have roughly 220, 230 corporate members, manufacturers, vendors, systems integrators, consultants, machine builders, academia, obviously. To develop an approach, a strategy, a strategic investment plan, how are we gonna use these funds to solve these problems? We very quickly realized that uh as we honed in, at least on the technology side on interoperability, is a key capability that no one stakeholder group could attack or could address on their own. That we needed to approach other major manufacturing regions to discuss interoperability and to collaborate. And we started with Germany and then Europe more broadly, engaging with Platform Industry 4.0 and L &I a number of years ago, five or six years ago, uh realized we were very aligned around this notion of interoperability. We understood that the German approach around information model standardization was very much focused on this idea of an asset administration shell. did a significant body of work to harmonize oh approaches so that when we're here in the US talking about interoperability, when you're in Europe, when the folks in Asia are talking about interoperability, we then went to Japan and South Korea and others. that we have a common understanding and from a technical perspective, a harmonized approach to interoperability. uh manufacturing is global, our manufacturing value chain is global. uh This is not a US thing or a German thing or a Japanese thing. We really do have to collaborate to solve these uh massive challenges together. Speaker 2 (06:51) Okay. Speaker 3 (06:52) Coming back to those challenges, Jonathan, you said like the first season was diving in into the plans, implementing things. And like you said, you've done like 50 or so projects. ah What are your learnings from those 50 projects? What's holding us back from just implementing everything and digitizing everything? Speaker 2 (07:17) uh A few consistent themes. So, um unlike maybe most of European manufacturing, which is relatively young, a lot of American manufacturing is quite old. It's small to medium sized uh enterprises with light automation um and very little, if any, digitization. um an astounding number of projects where factories first sensors or um taking the automation and actually getting data out of it. As you scale up to larger manufacturers who've been at this longer and have more um finances to wield at the problem, what we see is very heterogeneous architectures. So um like a patchwork quilts of software brought in in different eras to solve different problems, but never designed to work together or interact. The very large ones you will see um factories or portions of factories that arrive through acquisition. um So not only are they internally a patchwork quilt, they have purchased equipment or systems that were also a patchwork of different hardware and software. So making sense of all of that um is a very large kind of intractable problem. interoperability was not designed into our systems. Speaker 3 (08:52) No, was, I also think it doesn't, comes from the mindset. eh If you have a problem that you want to solve, you look for the solution to fix that one problem. And then you move on that one specific problem. course, like I need something to get a barcode from one system onto my bottle. For example. Okay. Let's buy some software or somebody builds something and path. works off. go. Speaker 2 (09:17) Yes, and that's very much the American instinct is I got a problem, I'm going to fix it. And I'll learn something as I do and I'll iterate versus when we work with our friends in Europe, there's deep thought in advance. So I would solve the problem and document it and then implement that solution. We're a lot more iterative here. Speaker 3 (09:37) I've seen both sides and on one hand you have like years of discussions on definitions and words that will be used before you do something and the other is like yeah why isn't it done already like I asked it two hours ago ah like somewhere in the middle would be nice Speaker 1 (09:57) I agree, in fact, uh we talked about this sort of uh as the one use case at a time mentality versus a smart manufacturing mindset, right? Regardless of where we are on this side of the pond or that side of the pond, we're talking about highly innovative, highly intelligent people, but they have a budget now to solve this problem. There's line of sight between this problem and the funds to solve it. versus the more strategic approach that says, we're going to develop a mindset, we call it a smart manufacturing mindset that... In the same way that we've developed a uh quality mindset 30 some years ago, a continuous improvement mindset, a safety mindset, it just is right. It's part of our DNA. We need that kind of equivalent mindset for using data and the resulting architectures that come from that mindset that say we have a long-term approach, a long-term strategic vision for how we're going to use data. And it's going to solve this next use case and it's going to solve it actually more elegantly and more effectively and more cost effectively. ah But we're going to end the technical debt that comes from this innovating one use case at a time mentality. Speaker 4 (11:19) It's interesting. um I remember a project I did. I was a Greenfield plant. I was part of many years ago. um like the project team, had... So the entire engineering phase was really, really well done, right? uh In German, they have a word for that, Deutsche Gründlichkeit, which literally translates to being very precise in the things you do. Speaker 1 (11:51) Yeah. Speaker 4 (11:53) And there was a very well thought of control concept. But then they never involved, I would say the project team never involved my group, the digital group, to talk about like... This is Greenfield, This is the time uh to bring in digital stuff as well. And then at the end, know I went to, when I was, I would say, aware of the project, I went to the um VP and I said, you didn't think about connectivity, you didn't think about, for example, Wi-Fi or something else. said, do you understand how cheap it is? Mm-hmm. to install this right now, but how super expensive it's gonna be to install it in a few years. And they went like, yeah, David, but that's not part of our project budget. So let's discuss that later. So I think my question with that, I would say story in mind to you guys is um like, what do you need to do to make the digital part, not just the automation part, because automation, have that covered, but what do we need to do to make the digital parts say, de facto, you know, it's there. Like there is no discussion about the digital parts. Maybe John, don't know what you saw or Jonathan. Speaker 2 (13:18) We are almost all Brownfields here, right? So we are solving this problem through abstraction. But I think your question is how do we get ahead of that? How do we eliminate the abstraction and solve it at the source? That's gonna be a longer journey. Speaker 3 (13:37) I think it's also maybe a question about the mindset because it's a green field, they make a new plant and they're very thorough in engineering, the testing, the design specs, everything's there. But there's not really a thought about the data being an aspect of that plant and that data being a solution for future problems, current problems, et cetera. It's just not part of the engineering scope, let's say. It's just part of IT very often, know, let them do their IT stuff and we'll do our engineering things. How do you start to break that mindset? Speaker 1 (14:18) Yeah, I would add one more element and that is the people side of it, right? The change management that's so essential to make sure you've got buy-in with the frontline workers, the operators and the ecosystem, the community that's going to support this and make use of it. And so I think it's a really important conversation because I come from the world where these software products are created and sold and implemented. And we had a product to sell, a software product to sell. And we paid lip service to the culture and the change management piece, but we really just wanted to sell the technology. And then you've got the consultants who were there to sell the strategy and the change management. And they kind of undermined the technology piece because they don't sell technology. They sell hours, people hours, right? And I think this contributes to this mindset disconnect that says, you know, we're technology focused, we're people focused, and that has to change. So I think specifically one of the things that we have been focused on to drive a more cohesive, coherent approach to all of this is uh that kind of leads to a smart manufacturing mindset more broadly is what we call a smart manufacturing assessment and road mapping professional. It's an actual certification that we provide after eight weeks of training, a couple of hours a week at night. And we have a community of practice now of these certified, CESMII certified individuals who can come alongside a manufacturer and shine the spotlight on each of these segments that are so essential. We found, for example, that... 99 % of manufacturers have a business strategy, well they all have a business strategy, but 99 % of them do not have a digital or smart manufacturing strategy. And so how can that be? And that's part of the disconnect that we're talking about here. so bridging the gap between the business strategy, the actual oh innovations and the initiatives that contribute to the business strategy through digital transformation or smart manufacturing, that's an essential uh DNA or capability that we have to build and then exercise and continue to invest in. but it's been super exciting to see. are both the technology and the mindset are two sides of the same coin and whether manufacturers recognize that or not, that's the extent to which they will succeed in the long term in creating value with data. Speaker 4 (17:05) I think this is a perfect bridge towards something you call the smart manufacturing imperatives. ah Jonathan, walk me through them please. Thanks Speaker 2 (17:18) Yeah, I think it's the right bridge. Let me say just a little bit of preamble. So what's the solution to these abstraction layers? um So one is the software that the vendors want to sell layers on top of the automation systems. um And the way software works is it needs a model. It needs a model of the world that it's interacting with. The model that we present at the automation layer is focused on control. It's a control-based model. and the primitives that we use to express that model, while they're fairly sophisticated at design time, at runtime, they serialize to this really basic structures, key value pairs. The OPC foundation tried to solve this. um OPC UA is more than just a newer version of the OPC protocol. It actually has a type system that you're supposed to implement. But at least in the US, we see most of our UA implementations with an empty type system or just the base type system there. So we're forced at the next layer, the bridge between the OT operational world and the IT, I want to build software world to reestablish this model, the subtraction layer, these models over and over and over again with vendors taking a slice of that and then trying to keep that model to themselves trying to keep that as part of their value prop. So in that bridge layer, we need to do a better job and we need to push the bridge down as low as we can. need the automation vendors to do a better job of surfacing their model. We need to push the bridge up. So whatever model the software uh layer creates to work against the system needs to be available. And that's what gave way to the three imperatives. So 50 projects all with this problem somewhere, adding the first sensors and modeling them and building some kind of analytic or app to very sophisticated systems that still have primitive operational focused models and vendor locked IT models. So the three imperatives are model your data, make sure those models are shareable both up and down, use a shareable format for the component models. So the component models are usually, you know, the parts of the system. The second layer of modeling then is the interaction between the parts in the system. So we call that the context layer. First, I establish what these parts are, what these components are, how they're assembled. Then I need to establish how they interact. And that can't just be a hierarchical arrangement like an S95 hierarchy. It's got to be the full set of uh interactions that occur in manufacturing. So that forces us beyond hierarchical thinking into graph thinking. And then the third is, now whatever I've done in layers two and one and paired as two and one, I need to be able to expose to software development. And that could be other platforms that want to interoperate. It could be AI that wants to read that model and draw new inference, or it could be a software developer making a new dashboard or a new prediction that returns value to operations. But we need to do all three of these things right and we need to do them together in a share of. of the three imperative. Speaker 4 (20:47) So yeah, so you wanna do that in a uh shareable way, interoperable way, et cetera. And then at a certain point in time, in comes i3X because, let me try to guess, because every vendor tries to solve the interoperability in their own way, in their own stack. Speaker 2 (21:14) Yeah, to write an application, I need two things. I need agreement on what the model is. What is this thing that I want to interact with? And I need an API, a programmer's interface to get at it. So if problems one and two are about establishing shared models for interoperability, problem three is a common API that application developers can rely on regardless of who the platform provider is. or importantly, what combination of platform providers exist surfacing. Speaker 4 (21:51) what you will always have. uh Speaker 2 (21:54) Yeah. Speaker 4 (22:00) There are a thousand questions in my mind, but I would like to start with a brief explanation on i3x as such. Did you guys build another product? Are you now standard number 7,025? Or what is this? Yeah. Speaker 2 (22:22) So we took the learnings from those 50 projects that use a variety of software packages. And we, my team looked at what function calls the application needed to make. um What kinds of data were those apps looking for and how were they calling them? And we boiled it down to like eight to 10 functions that a platform needed to have. And then we looked at the platform vendors and the standards in our space. And we saw that most of the platform vendors had these functions, but the API signature was different. The way you called it was different. And then none of the standards actually said how to do those functions. So it wasn't the vendors being malicious at this level. was we are providing common functionality. We just have no common way to provide that functionality. I sat on the OPC UA Web API Working Group and kind of advocated for, we provide more guidance to the the platform vendors, but that wasn't the goal of that effort. The goal of that effort was to take the UA um API and make it rest. So there really was white space here. There wasn't a solution except for what was proposed by individual vendors. So we wrote an internet style RFC, a small team within CESMII, kind of drafted this up and said, hey, we think this is the problem. We think these are the eight to 10 functions. um And we think... we could make them common across vendors if they were willing to participate. We shared that RFC style document in November of 2024 with our community, which has lots of different vendors and lots of different end users and kind of held our breath. Like, what are people going to think? We only got two kinds of responses. Yes, this is important. Tell us how to do it and we'll get it done. Hmm. And yes, this is important and we have some thoughts on your RFC. Can we contribute? Speaker 1 (24:18) No one said this is a bad idea. Speaker 2 (24:19) No one said, hey, we know of a standard you missed that already does this. It truly was white space. And to their credit, the community was willing to either adopt or contribute to the evolution of. Speaker 3 (24:36) Now, going from a very abstract idea that you're explaining here, we're working with models and graphs and we're going to make an API based on eight to 10 functions to reality changing on the shop floor. ah Can you explain what your plans are? Like how do you go from one to the other? Because we've been to enough meetings and presentations of people very enthusiastic, but it's hard. to make those things live. So I don't need to convince you of that, of course. Speaker 2 (25:09) Yeah. So that we walked a really fine line. So after we, we announced this and we got feedback, we kicked off a working group that worked for about 18 months on exactly that. And we had kind of dual goals. So one, make it really simple to implement and adopt the API. uh It is not a platform. um It doesn't dictate how your platform should work under the hood. It just says, Here's the API signature and eventually the response structures you need to be able to support. So it's really easy to bind to or adapt to a platform that already has these capabilities. On that side, it's simple. um On the, do we communicate the concepts of imperative two and imperative one? We just baked them into the API. You can't respond to a data request without having a type definition. of that data structure. So i3X kind of presents this checklist of capabilities where if you have them, you're ready, right? And if you're missing them, it's really clear. Matt Parris, one of the working group members called it a brutal mirror. Whether you've done a UNS project or you are all in on a vendor or you're trying to build it your own using open standards, the eight to 10 functions are a checklist. Does the data have a type? Yes or no. ah For the live data, do I have a historical data source that can fulfill that same structure? Yes or no. Does the data have hierarchical organization? Yes or no. Does that hierarchy expand to a graph? Yes or no. It just makes it really simple. So it carries the opinions, but it doesn't force you to be academic and conceptual. It's just a checklist. oh Does my system have these minimum requirements or not? Speaker 3 (27:08) I really like that checklist analogy that you said, because even if you are working on a project, like you say, you're not a vendor. Like, why should I care? I implement stuff in my plans. I'm not the one designing software, but just taking a look at that API will already give you like an overview. Like these are the things I should keep in mind. I'm working with data. Okay. My God, do I need to have hierarchies? Why should I have hierarchies? Okay. Do I have a graph? What? Speaker 2 (27:38) What is a grad? Speaker 3 (27:40) It will let you think about the stuff you might miss or that you do miss, but it also gives you a complete view. In its essence, the scope is very complete. So you're not left thinking, probably there's two, three important aspects of my project that I've forgotten. So I urge people who just implement projects, just check the API and use it as a checklist. Just that is already going to convince you, think, of the practical nature of it. Speaker 2 (28:12) We built a test client just for our own purposes. And then as you're kind of coming up to the demo, we're like, we should release that. And so whether you're a programmer or not, if you load your i3X implementation into i3X Explorer, you can see if you have all the functionality or not. It becomes really easy to communicate what the project needs in order to be successful. Speaker 1 (28:38) And I will add this, the industry has reacted in an extraordinary way, unlike anything I've ever seen in my career. m If you're interested, we can share with you what that looks like. the initial demonstration in Dallas at an event in Dallas called Prove It with six great vendors demonstrating an early. vision for what this looks like using i3X and the ensuing two and a half, three months and sort of culminating in our announcement at Hannover two weeks ago, uh the vendor and the manufacturer response has been like nothing else we've ever seen. Speaker 4 (29:23) One of them, Aron Semle from HighByte um we had on the podcast a couple of weeks ago. And there are many, many other vendors which are already adopted. uh Something to a certain extent, I assume everything is still in beta. um Speaker 2 (29:44) Yeah, we're at beta state as of Hannover. Things are pretty stable. There's a work in progress state as well, pushing for a 1.0 release in June of this year, um the final 1.0 spec. Speaker 4 (30:01) I wanna touch upon another topic, uh which is um equally important here is it's great to have a standardized API layer available, but we still have to look to the modeling itself. um The way we govern master data, the way... Yeah, somebody decides like, how are we going to structure this thing? And also Jonathan, you pointed at it. How are we going to structure it in a way which represents our business and not just a way where we represent the control uh structure? um this may be not really immediately. uh I don't know, is this also your role to advise in that or? Speaker 2 (30:52) It is, and I've had the privilege of uh being embedded in one big project and being able to um advise on a couple others. And there certainly have been ah implications beyond the initial scope that maybe we couldn't have fully predicted. uh One of them is that people are using i3X to connect their heterogeneous systems. m So I have some data in this system, I have some data in this system, and we kind of thought of like, uh um a vertical distribution, like I might get live data from the MQTT broker and historical data from the historian. And part of the brutal mirror is if the model in the historian doesn't match the model in the broker, the request isn't going to work because it has to use the same element ID. So that was contemplated, like by design, force you to unify your namespace. But as we've been doing some of these projects where the level of context where i3X is deployed scales differently than we anticipated. People are bringing in these systems that are truly heterogeneous. Like they have live and historical data for one view of the enterprise and live and historical data for an operational view of the enterprise. And we're trying to plug them in to get into a common hierarchy, a common spine and finding that those sources don't agree on the model. um That even the hierarchical model, know, the Maximo has one hierarchy in mind and the operational system has another hierarchy in mind. So how do I even marry the data elements on a tree? And it forces it, part of the brutal mirror, it forces these teams to get together and ask the question, why do I have two different interpretations of of reality within my own plans. How are we going to resolve this? Speaker 4 (32:54) that's a really good point. And I would say also one which happens everywhere, but like, where would you resolve that? Because you mentioned Maximo, let's say whatever maintenance em CMMS and take equality system and take your ERP system. It's very hard to go to all these source systems and then change that source. So does that mean that, and you guys, so you... you provide an API layer, there is still, well, provides, you wrote the spec, um where a vendor provides the API endpoint on their system. Yeah, absolutely. So that means that, like, where do we translate? Is that where a data ops tool comes into play? Speaker 2 (33:44) Yeah, absolutely. So generically, we call it the adapter. So I want to fulfill i3x from these data sources. Something has to adapt the data. So that is data ops, right? And so I can work with a platform like Hiveight to restructure the data to match the target model. I can work in the source systems, if that's possible, to unify the model. Or I can write adapters. What we're finding is somewhere in some collection of heads within the organization, somebody has a mental model that translates between these systems. So how do we extract that mental model and graph it out or articulate the logic to adapt it out to get to this kind of unified spine, this common end? OK. Speaker 3 (34:33) ah Now, adoption seems to be really high. There's quite a lot of enthusiasm about something like a standard, which is not always the case. ah Which is good, which is good. We need more. uh Where do you see, let's say, SysBee i3x in a year or two? Speaker 4 (34:54) John, someone, a question for you. Yeah, Speaker 1 (34:56) I'll comment on sort of the community aspect of this and something that we've alluded to, but not exactly expressed explicitly. With this layer of abstraction, we are now, what we now have the opportunity to accomplish is to go and encourage and inspire a whole community of subject matter experts to build applications, to build AI models, to create value against an API, against I3X versus against a specific vendor platform or ecosystem, which is an extraordinary innovation accelerator, right? We now can take this thing that produces value and if there's an existing platform in the plant and with this extraordinary vendor adoption, odds are now significantly uh higher that existing manufacturer has a platform that's i3x compliant. This application, which is also i3x compliant, will just work against literally dozens of these manufacturing platform providers. And so this is, we believe, an extraordinarily important aspect of how we can deploy AI at scale. This is an important aspect of how we can drive innovation at scale. we talked about democratization for the small medium manufacturers as well as large. This is how we can uh inspire and engage with the small medium manufacturing community who can now afford some of these lower cost, simpler and less complex approaches to manufacturing systems. Speaker 2 (36:41) Since we're talking to folks in Europe, I have to call out that this is not a standard. I would say it's standards track. We would like it to be a standard someday. But being a standard carries a certain level of overhead, both for the creators and the adopters, right? So we made a tactical decision um to stay out of that fray initially to keep um the barrier to entry low. um It is a professional working group of both end users and vendors. We're following a process um similar to what the W3C describes. And we intend m to partner with a standards organization at some point in the future. But if we'd started m defining a standard first, we wouldn't be here yet. We wouldn't have the adoption yet. Speaker 3 (37:35) talking still about function three. Right. Speaker 2 (37:38) We wouldn't have the engagement. Because it's easy to adopt right now, it's easy to engage with us. If you have a GitHub account, you can create an issue, you're in the conversation. Speaker 4 (37:48) Having said that, uh taking a look to the list of the companies, the technology vendors you're working with right now, almost, I think almost every major name or every major name is on the list. So I think that's good enough. Speaker 2 (38:06) And if you're a major name and you're not on the list, you're welcome to join in. Speaker 4 (38:10) That's actually a perfect uh call to action to end these episodes. uh Time flies when you're having fun as always. uh We will make sure that in the article, also in the show notes, we'll link to your specs. There was a very nice animation I also saw on the website, which I'm gonna link to. I also saw your very lengthy uh demonstration at... ProveIt conference, uh which we'll also link to. I think it's really interesting to see how you start and then like every single vendor comes after you and goes like, yeah, by the way we did this and oh yeah, by the way we did that as well. ah that's pretty awesome. I didn't see too many vendor presentations where like multiple vendors share in their operating. Yeah, absolutely. So that's an interesting episode for everybody who's interested in knowing more. uh I'm sure they can reach out to you, but I wouldn't even dare to say reach out to your vendor as well about this. Speaker 2 (39:13) Yeah, for sure. Speaker 1 (39:15) Alright, good! exactly right. We want the manufacturing community to uh begin requesting these capabilities, saying no to another data silo, saying no to another stovepipe architecture. There is a new way. We're at an inflection point where there is a better path forward. And if the manufacturers, as they have been here in the US, we hope around the world, if they're asking for a better approach, um the vendor community is stepping up, which we're thrilled about and answering that call with i3X. Speaker 4 (39:52) Gentlemen, um would like to thank you both um for giving us your time to talk about this in our podcast. um So as always, there are many ways to follow our content. There is the blog, there is the podcast. That's what you'll be listening to. um We have our upcoming book, the IT/OT Handbook. pre-sale available via itotbook.com. And we have a couple of very nice bonus things if you let us know you pre-ordered it. So that's something which you can do. There is also our academy, right? Our IT/OT Academy where we don't really teach about the technological part. Yes, we teach about architectural stuff, but mostly we're focused on the organizational side, the people side, asking the why question. So for everybody who's working in that intersection where IT meets OT in an architectural role or a management role, et cetera, you're more than welcome to join us. More information on itot.academy. And that's a wrap. John, Jonathan, thank you very much. Thanks for having us on. Yeah, thanks for having us. It's been a pleasure. our pleasure and willm until the next episode. Bye bye.