speaker-0: The only commonality between ignition and fuse at the end of the day is they are both platforms for building solutions on top of. Exactly. What those solutions are and how they're made and what they're made to solve. The tools that are in the box are very different.
speaker-1: Yeah. Well guys, it's been a crazy week at bootcamp. And so we're going to now discuss everything that we learned about Fuse, what we liked. I'll kick it off if you don't mind. I am well known for being both a finance guy and a predictive maintenance guy. What I'm most excited about is the fact that I can use Fuse to integrate local plant floor like master work center data with the financials and then know real time variances against STEM. So for me on the finance side, the thing that I'm most excited about is the ability to actually build the infrastructure for real time variances against standard. So the general manager of the manufacturing business does not have to guess and wait until 10 days after quarter closed to know what the actual gross margin was. That was something that gave me many ulcers when I was running a plant. And I'm so happy that people in the future don't have to do that. And then on the predictive maintenance side, I learned that Fuse doesn't do predictive maintenance props. So you probably wouldn't use FUSE to integrate like really sophisticated vibration readings or thermography because the data structure isn't there. FUSE is really meant for relational databases and time series data, like you would find in a SCADA system. It's not really built for doing deep vibration or thermography or motor circuit analysis type work or applying ML learning stuff on top of that. But the good news is there's people that specialize in that. So I don't need FUSE to do that. and we can integrate FUSE with really sophisticated predictive maintenance providers that can then send kind of, they make the diagnostics and they send down simplified scalar data or the presence or absence of a flaw. And I've got FUSE as a platform in the middle that I can send all of that. That's what I'm excited about. I defer to you guys though, how about you?
speaker-2: Yeah, I liked their office. Their office was pretty nice. That was ⁓ nice. ⁓ This podcast room is pretty sick and the whole team is really awesome to meet. What I like about Fuse as a platform is you can use best in class, best of breed software across the different layers of your business from PLM to CRM to ERP. And maybe you've already standardized on like one ERP, but you might have different plants that have different ERPs, or you buy a plant, or you want to upgrade ERPs. Fuse allows you to fuse all those different applications together and still manage it, right? So you don't have to worry about, this automation going to run? What hardware is it running on? So to be able to have that all abstracted, if you're doing from one communication from one plant's ERP to another's. you're going to want to go through the cloud anyways. So to be able to have that cloud enterprise orchestration layer where that's where Fuse kind of sits in my, in my eyes. What I don't like about it is it's kind of hard to explain what it's kind of hard to explain where it fits in the organization. So yeah, but we can get into the more of the challenges, but yeah, that's what I like about it so far.
speaker-1: Nice, nice. How about you Dylan?
speaker-0: Yeah, I guess the first thing that stood out was really that... Everybody here is not just IT or OT. Everybody we met was fluent in manufacturing. They'd been on the plant floor. They knew what they were talking about, but they were also fluent in cloud services and IT and everything that's involved there as well. I'm speaking both languages and having lived both lives. The people are very focused on the product and the feature set and solving problems for their customers. However that may look, whether that means building new connectors, building new features, and just adding more and more onto that product and keeping everything up to speed at the pace the customers are requesting. That drive and attitude was very exciting. The platform itself as an integration platform is really awesome. There's connectors for everything with the flows, being able to integrate as a true integration platform is kind of a big piece for me. But integration platform in an IT sense, not necessarily in an OT sense. but an integration platform for IT that respects OT. It's not an integration platform that you'll see in your SCADA layer. It's an integration platform you're gonna see in your enterprise layer. It works with your enterprise apps, layer four of the Purdue model, not layer two. There's gonna be some overlap with layer three a little bit. It does MES, but it does MES from a cloud perspective. It's standard enforceable data with clear access control and pure integrations in the cloud. It can respect or be... more down the stack as needed or desired, but not any further down than you need it to be. And that's what I like about it as a true integration platform.
speaker-1: I'm good. Yeah, nice. All right, now what could they improve? No company is perfect, no product is perfect. How could it be better? What could they improve on, guys?
speaker-2: Yeah, I think the user journeys could be improved. So whether I'm an admin. I work for the manufacturer and my job is to manage roles of users and permissions. When I log in, I might want to have a different home view versus a developer. When I'm a developer and I log in to Fuse, I want to see all of my objects on the dashboard. I want to see all my flows, maybe the status of those flows, the last time they ran or then from there be able to click into edit a flow, edit a data model or add new data models. Just in general, being able to have a more intuitive user user journey. think that would be one. of the major rooms for improvement.
speaker-1: Nice. Dylan, you want to go next and I'll go last?
speaker-0: Yeah, I guess for me, everything I said about the attitude and the culture of adding features and building everything as fast as the customer can request it is a double edged sword. They have all the features there. Everything's where it needs to be and everything can be done in the platform. There's very little that can't be done in Fuse. But with that comes a lot of the usability piece, kind of like what Zach was talking about on the user interface and how things look and feel. It's the general user journey. Is it intuitive where things are? Is it intuitive that there are even certain features you might not know until you've drilled down months later and just the lack of ability to discover what features are there. Little details in the interface like just... general comforting features like white space and color consistency and things like that that just make the user feel more, more welcomed. Just being able to make different looks and feels for different users and different journeys and different types of whether it's a developer or an end user, they're entering through the same pool, the same portal right now. And just the general feel of that. was very much made with all the best intentions by engineers solving problems. And that's a really great feature to get features out the door, but at some point it needs to be usable. by other integration teams.
speaker-1: more novice the person that's using it. Like right now it was built literally as an iPaaS platform. And so everybody that was using it as a tool was a dev. Like they knew a lot. They understood the architecture inside and out. But now we're getting a, no one would accuse me of being a dev. And now a guy like me is going to start using it. And I got to admit, I got nervous. There was one part where we were discussing change logging and like in what scenario should you or should you not turn on change logging. And like when I'm building a screen, there's a checkbox at one point that if I like did or did not check that the implications on compute time and storage time and app performance were pretty significant. And unfortunately, I don't have the technical chops to really be making that trade-off. Whereas a dev would look at that and be like, Glenn, of course your performance is going to suffer if you do change logging on this particular lot in a time series database. Yeah, that's going to be a nightmare. Don't do that. For God's sake, turn off change logging when you do that. And that wasn't intuitive to me. I didn't know that.
speaker-0: Thank
speaker-1: It's all well and good that it makes sense in retrospect, but it wouldn't have occurred to me that a thing like that might have bad repercussions. ⁓ so yeah, finding a way to both serve, I would consider both of you guys will be power users. And I intend to build on the platform as well, but I'm just not as technical in the coding space as you guys are. And you need a way for a Glenn to not make a foolish mistake, like putting change log on a time series database that's all historicals you don't need it and it slows down your performance.
speaker-0: And even going down a more technical rabbit hole to even for more of the power users, the discoverability of features like change data capture, is that even a thing? It requires you to have discovered that checkbox and know what it means. So it's the prerequisite tribal knowledge is a piece. Being the enterprise layer, it is. And a lot of the connectors either exist in the cloud. or on premise and there's some overlap or something should exist in both. So one of the limitations right now from like an MES perspective is if you have a client who has a very strong UNS already built, it's all cloud-based, multi-site, and we want to hook views on that to maybe the bridge between the UNS and the existing SCADA layers and the ERP, for example, or PLM. Right now, you can't do that without having a... another service running on premise somewhere, going from site to cloud to site back to cloud and various patterns like that. ⁓ like cloud connectivity and MQTT and things like that, ⁓ or even AMQP through the other brokers would be a nice feature to add. Generally, which ones exist where? The other roadblock is very much the only edge, talk about the Edge Gateway, currently through official channels, the only Edge Gateway you can install is on Windows, ⁓ which limits. some of the more IT centric OT deployments who might be running on Docker or Linux instead.
speaker-1: Yeah, I was going to hit that. Do you mind doing a live like tutor me for the next minute and the listeners more importantly, but they're not on-prem, but they have an on-prem broker. And so like they survived the Amazon adage this week just fine. I misunderstood that the reason they survived without any data loss was that there's an on-prem broker and that thing keeps logging. And then once it goes back online, it can send any data that it's stored to the cloud. My technical thinking is muddy and I'm hoping you can just help me understand tutorial style.
speaker-0: That one, from my understanding of AWS outage, there's two pieces. A, even though the cloud service didn't go down, but I think that was more around which data centers happened to be affected and which ones just happened to be running on. But even if this one had been affected and the service went down for an hour or two, if you have a deployment architecture where you're using the edge gateways to connect to things on site and use that to pipe up to the broker in the cloud. There is store and forward methods. There are buffering, there are general bufferings and packaging. And that store and forward is kind of what's going to make it so that even if it does go down for an hour or two, then there is more buffering. And that's not necessarily made to mitigate the impact of like an AWS outage because that really shouldn't happen. That's an extreme edge case. But if your internet goes out for an hour or two, or you lose power or something, but maybe you have some battery backups running your panels and your machinery, but you lose power and your servers and stuff go down, then you can still buffer and store your data locally. And then once connection is restored, it'll send that data up to the cloud and retain all the data that was already there with the correct timestamps and such. And then all those events that happen in the cloud can still trigger and happen as though because the timestamps and the store and forward and all that.
speaker-1: Okay, okay. But it's not on-prem. Here's the distinction I've never quite understood. The gateway is on-prem. It's installed on a server that is somewhere on the premise of the site, but you wouldn't describe this as an on-prem solution in that all of the integration happens in the cloud, right? Help me clarify my thinking on this.
speaker-0: So you've got the Edge Gateway, which has edge connectors, and you've got the actual tenant in the cloud. The tenant in the cloud has cloud connectors that are going to connect to things like your ERP systems and maybe data warehouses and other enterprise applications that are also running in the cloud. Maybe a CMMS, a PLM something, SAP, or just other things that happen to be running in the cloud. Much more IT friendly, but typical IT connectors. Very typical of the iPass suites. Nice. On the Edge gateway side of things, you've got other local, more operational focused data. PLCs, SQL databases, site historians, including some legacy options, all have connectors where you can connect the Edge gateway to the PLC, to OPC servers, to historians, other data stores, legacy SCADA, whatever Brownfield protocols you have, it likely supports. Got it. And the Edge gateway can connect to those. physical devices on premise, model the data locally, run some data flows and such as needed, and then the results of that are stored forward in a buffer before it goes to the cloud. ⁓
speaker-1: Nice, nice. So it's a high-browder brook. Sometimes a customer says, we're on-prem, we don't do any cloud, we have to be on-prem. I don't know if they would accept this as an acceptable.
speaker-0: Fuse is a cloud platform that has an edge component.
speaker-1: a cloud platform with an edge component that will still talk to your machinery if you lose internet connectivity, but it's not an on-prem installed thing.
speaker-0: The Edge component is installed on-prem, but configured and managed through the cloud.
speaker-2: The problem is that Fuse is like six or seven different commercializable products that how do you go to market with that?
speaker-1: That's the other thing they need to improve on, but it's hard. It's really easy to critique. It's hard to tell the story of the value that they add. Whenever somebody comes to your office and they're like, we have a platform that literally integrates to anything you have, cloud or onsite, and we connect everything, and we do strategic analysis of all your stuff, you're like. I'm positive that's BS. You guys don't know anything, please leave. You would never find somebody that says that credible. And if someone right this moment were to be like, pitch me on Fuse, I would say a version of that speech and I would sound like an idiot, like I know nothing. But it literally is like seven different applications that you could choose to use. They have a WMS, you don't have to use it. They have a CMMS, et cetera. The MES is kind of the core, but you don't even have to use that. You could like from scratch kind of build on top of just the core infrastructure. And the market danger is, I remember a business prof once told me, if you ever have a business plan that sounds something like, we do everything, customers can come to us for literally anything in this space, he's like, I can almost promise you you're gonna fail. And so I'm trying to convince myself that like, is the real deal, they found a way not to do everything, but to be extensible enough that like, everything is within reach, just, the Fuse team doesn't have to develop it themselves. And I'm still torn, I'm... ⁓
speaker-0: Good. The difference there in a product versus a platform. Fuse is a platform. It's a toolbox you build on top of. Fuse isn't a WMS. It's not an ERP. It's not a CMMS. Fuse is a platform that has tools that you use to build your own problem, to build your own solutions to problems you're facing. is, and when I say it isn't a WMS, they do have pre-built applications that you can choose to use or not that happen to be a WMS. Those are still examples that were built on the platform that is Fuse. you can customize it or you could build your own WMS your own way using the tools. It's a toolbox. It's a Swiss Army knife. It's a platform, not necessarily a product in another
speaker-2: All the feedbacks that the ⁓ heavy equipment manufacturer gave us was that ⁓ it seems like it could do so much that there's no way we could possibly leverage it for everything that it does. So they get the impression that it's probably pretty expensive. compared to other iPaS solutions that are enterprise scale, it's actually quite cost effective in my opinion.
speaker-0: I mean, even if we were to take the use case of a single site MES and a typical deployment of this, of Fuse as a single site MES that's in the cloud, using other leading platforms with third party modules to build that MES in the cloud is still within a margin the same price.
speaker-1: Yeah, after we ran the numbers, was clear like Fuse would be the default choice for me at the enterprise level. As soon as you're into multiple sites, it's kind of a no-brainer that Fuse fits perfectly.
speaker-2: It's not just the software cost though or services, it's also the hardware. What hardware are you running? Who's maintaining that? If you're not calculating those costs, then you might think, ⁓ this is a lot more affordable. then like, okay, it's affordable. You know, it's like 30 K let's say. then IT had a provision, a SQL server license, and then it was a $200,000 hit. Right. So it's like when you look at the total cost of all of the like to build out your whole stack, not just from software, but hardware support. Maybe you need to add someone on staff to be able to, you know, DevOps DevOps is completely abstracted with a product like this or like 4IR. Like if you take 4IR and Ignition and ⁓ maybe like a Boomi or Workado, more of an enterprise iPaaS, Ignition doesn't even do anything close to that, right? Like there's not a million built-in connectors or, you know, there's data source connectors, but not platform connectors. Like PLM, there's basically no PLM connectors in Ignition.
speaker-0: From a sailor piece's maintainability and total cost of ownership with a platform that's native to the cloud and hosted in the cloud for you versus a platform that was made for on-premise that can be hosted in the cloud. Then there's the complexity of the architecture, ⁓ horizontal scaling, load balancers, and that, well, there are a handful of integrators out there that could implement those features for your platforms. The question of maintainability and internal capabilities. and the people who have those capabilities who could be internal aren't cheap.
speaker-2: This is why integrators started doing hosted SCADA on ignition, like multi-tenant ignition SCADA hosted.
speaker-1: Yeah, it was. Where I landed was if I was doing an MES on a single site, the two pricings were within striking distance of one another. You could plausibly build your MES on top of ignition and or by like an ignition third party MES module and do the implementation. It's within striking distance of the same cost for a single site as Fuse. If it were me personally, if I had a multi-site implementation of MES style workflows, I think Fuse takes the lead pretty quickly because of all of enterprise adaptations. That's why that's so valuable to go for multi-site to use Fuse. But the inverse works too. If someone said to me, you're on a site, ⁓ you need to pick a SCADA, do you want to use Fuse or Ignition? I'd probably default to Ignition if you were doing SCADA only functionality. And it's only like the higher you go in the stack, the more I'm towards, okay, actually now the Fuse value is better. The lower you go in the stack, the more I would choose Ignition as the default. There's some gray zone in the middle that I dare not figure out.
speaker-0: That's where I think the danger is in comparing them as ignition or fuse.
speaker-1: because they're not, I really don't see them as competitive.
speaker-0: We're talking a greenfield site in my opinion today, it will almost always be ignition and fuse. If multi-site enterprise grade MES. You know the data that gets into fuse is either good or it's rejected. It's not validated. And that is from a data side of things, a necessity for any enterprise grade software. And if we start talking about multi-site rollouts, you need that level of standardization. above your 10, 20, 100 sites, but also trying to enforce that level of standard down all the way to the plant floor of all of those sites is a futile attempt. It's almost impossible. And so having the combined ability to have your local fast moving agility that allows you to solve your own problems in real time without affecting
speaker-1: must have.
speaker-0: the standards set at the corporate level and ensuring that you keep the agility and the problem solving capabilities local, but then you also have all of the enforceable standards at the enterprise level and have that integration layer between them, that is that zone where they coexist. And there are a few features that may overlap from time to time, but they are entirely different platforms for entirely different use cases.
speaker-1: Yeah, amen to that. Yeah, like I actually don't want Craig and Lance and team to develop another ignition because there's an ignition. It's there. It's got an ecosystem. It's awesome. We love ignition. We're big fans. Like we don't need that from Fuse. Fuse is to me the best thing I've ever seen for wanting to integrate Plant Floor with ERP and with PLM and with supply chain planning. Like they thought that all the way through like nobody else has. And that's where I want to throw it.
speaker-0: I think ignition and fuse are capable of and should probably be the best of friends.
speaker-1: Yeah, my utopia is stacking them on top.
speaker-2: It's funny that ignition is not like Fuse and Fuse is really not like ⁓ Plex, which is crazy that some organizations and enterprises are evaluating Plex for a solution or use case that would be much better suited for Fuse. If you're listening and you're looking at Plex, you should actually be looking at Fuse most likely because... know, Plex doesn't connect to the things on the plant floor very easily. It doesn't, it has a hard time connecting to the ERP. You know, people are using Plex and they're still using Fuse to connect to their ERPs. ⁓ If you're using NetSuite, it's almost a no-brainer to be using Fuse. So ⁓ yeah, that's what I can't get over is like, you're an, especially at an enterprise, maybe if you're a small to medium, single location steel plant, okay, maybe Plex is the right solution for you.
speaker-0: mess.
speaker-2: Or ignition, right. But the second you start having any scale or complexity or you need to integrate to anything, then yeah. Or you need to run 24-7.
speaker-0: Yeah, and that gets into the sales point again, like what is the product? It's the only commonality between ignition and fuse at the end of the day is they are both platforms for building solutions on top of exactly what those solutions are and how they're made and what they're made to solve. The tools that are in the box are very different. Yeah. And when we start talking about Plex specifically Plex and and flex have a little bit more of a contentious relationship because Plex is an MES and MES that you could build on top of fuse using the tools that the platform provides.
speaker-1: But it's not an alternative, like they said, they actually built a huge business on being an integration layer and I pass on top of It's not like if you have flex, okay, fuses out, then it's quite the opposite actually, they solve the problem.
speaker-0: And that doesn't have to be. I mean, it can connect to an MES or it can be an MES. You can build, and not that it is an MES, but you can build an MES on it. Exactly. It can connect to a CMS or you can build a CMS on top of it. It can connect to a PLM or you can build a PLM. Yeah, totally. It's a toolbox.
speaker-1: So rather than confuse the heck out of the world, plan is for the foreseeable future, when a client asks me what is Ignition, I'm going to say it's a SCADA. It does other stuff, but it's a SCADA platform. That's its origins. That's where it came from. And here's some other cool stuff that you can extend outwards. And for Fuse, don't tell Craig, even though we're recording this, I'm going to say it's an MES. It's fundamentally an MES platform. However, They built it with iPaaS in mind. In fact, it started as an iPaaS platform. And so what you're going to find is everything that you want from the CIO's perspective in an enterprise software platform. And guess what? It was made by manufacturing people. So like they get the MES. The MES module is awesome, but it's just one module. But if pushed into a corner, I'll probably call it an MES before I'll call it an iPaaS platform. But don't tell Craig.
speaker-2: What module would you want to see infused?
speaker-0: Good call. The MQTT Cloud Connector.
speaker-2: Like in terms of like off the shelf application, what would you like?
speaker-1: I mean, what do we you know, be interesting SCP supply chain planning ⁓ really because my big thing is supply chain and factory floor disconnect like that caused me endless hours of pain and my entire team endless hours
speaker-2: I fuse be a good SCP integration tool.
speaker-1: Because they've already got... Or why would they make a SCP? A good SCP. In fact, what they would do is they would design the SCP into the same module as the MES. Because SCP speaks purchase order, order entry, and then interacting with your suppliers. MES speaks factory floor and maybe traceability amongst the stuff that's coming in. But that's not where you order the parts from the suppliers. If you fuse those two together, no pun intended, you can solve a big problem. so item pegging becomes much less complex if they're literally built on the same backend. So if I had to pick one, I would tackle SCP. I would tackle SCP next.
speaker-2: Yeah.
speaker-0: whatever solution we need for the problem the client has at hand. It's a platform. It's a platform for building solutions.
speaker-2: What's the most common problem you're seeing? ⁓
speaker-0: I-PASS, it is integrating your ERP with your plant floor. That may also add MES features and functionality, but at its core, the I-PASS is probably the most valuable piece. Everybody has a SCADA system out there, and almost all of them have struggled to connect it with their ERP. The ones that have successfully connected their SCADA to their ERP have done so at the behest of whatever integration layer that the ERP provider has forced. and they're not always flexible. Sometimes they don't do what you need them to do. Sometimes there are other iPad softwares that can get it done at the end of the day, but cost significantly more than Fuse. And sometimes they just say, no, we don't do that. And the ability to integrate the ERP to the plant floor in a safe, controlled, and standardized way while still providing full functionality and flexibility to conform the product and the solution to your business is what Fuse offers.
speaker-1: It's a no-brainer. It's fused. It immediately comes out of my mouth when I hear that.
speaker-2: To the name to the naysayers or not not the naysayers, but like we have a large ignition audience to the OT kind of focus or they grew up programming PLCs, building SCADA systems and primarily in ignition, what would you say to them if their instinct, admittedly like mine initially, is like, ⁓ I could just connect an ERP in ignition or I could just do this in ignition, what would you say to that person to kind of get them to open their mind about?
speaker-0: do it, the next plant can do it, the next 10 plants can all do it, but you're not all going to do it in the same way. And when the CIO or the VP of IT sees these 10, 20 different ways of doing the same thing, he's oftentimes using different platforms. Some people are going to conglot can congregate on the similar platforms and others are going to use their platforms of choice. Some are going to build custom code applications that aren't maintained and others are going to use legacy platforms that and some yet are going to go and say that you can't do it. And now at an enterprise level, and especially from a security and integration standpoint, there might be five different vendors for the 20 different sites and a couple of custom solutions that all need to be maintained, secured, and nurtured as vendors and partners that the enterprise team just doesn't have the bandwidth or the resources for. At which point, very often, the enterprise team will just retract altogether and say, too bad, this is what we're doing now. And after they've been burned, now you don't get a choice, you're gonna get something that probably works less than what you have and nobody's gonna be happy with the results.
speaker-2: because think this is happening with the customer. Yeah, no, like this is literally happening right now where a customer has like ignition and they're doing UNS and it's organically growing at the plant layer and the enterprise IT team is like, ⁓ there's too much, ⁓ too many vendors. We're gonna standardize on Rockwell. So then they're like, ⁓ we're gonna use PlexMES. And we're like, no, this would be perfect for Fuse.
speaker-1: What? ⁓ Does Plex have your daughter held hostage?
speaker-2: Just flex. They, who knows? I mean, honestly, have I said anything that's incorrect about them? I wish them, I don't wish, I don't wish poorly on them in their-
speaker-1: No, of course, I'm just teasing you.
speaker-2: probably great people, I don't know them. I mean, I know they're great people because a lot of the people here use the word complex. So I know that the people that work at Flex are nice people. So yeah, but it's just a different, and I think that's the challenge that they're overcoming is like, the, people aren't even aware that this is a problem that exists probably. Like I wasn't aware of it. I would have been the guy who said, ⁓ I'll just do this in ignition. I, well, you just said, think it's a perfect. ⁓ is what we found that there's a need for.
speaker-0: And that's the big thing I say to a lot of people who say this, not just about ignition and fuse, but about a lot of things is, yes, you can do it. I mean, you can build an MES in ignition. I've built an MES in ignition. You built an MES in ignition. A lot of us have. But the question is, who maintains it at the end of the day? So an integrator will almost always have the capability to do that. Some end users will be able to build it in-house. But at the end of the day, especially when it's an integrator that comes in to do it and adds this complexity and these custom applications, whether it's built in Ignition, which is arguably way better than the alternative of building some custom code in .NET or Java or something. And most end users don't have the capabilities on their operations teams to be able to manage or maintain these softwares. Even companies that have very mature development teams, they're focused on different, they're resources that are intended for different purposes.
speaker-1: Yeah. Yeah.
speaker-2: But from that end you said, all right, this is a valuable experience because you're like, now I know, you know, I know what I'm talking about. You know, that's really the curse of knowledge. know, people, I bet Steve, you know, you came here and you're like, damn, Steve is just doing this without, like he's a masterful sales professional in the way that he talks and qualifies the client. He's like just executing his process in a way that's just subconscious and totally natural. I bet Steve sometimes doesn't realize how gift he is. You're like, wow, Steve, you're really good, Steve. If you're watching this, Steve, ⁓ we look up to that. And Steve also manages the partner network.
speaker-1: So we are incentivized to say good things about Steve on camera. I'm glad you did that. But yes, you're like to.
speaker-0: So as I said, quick too, based on that back to that MES story before the boot camp, now in hindsight, there was one downside of that is it was very localized. Copying that MES from one site to the other would have been a full migration of a different platform. It was not multi-tenant. We didn't have any way of having these same things in different sites. So it very much architected for that location and those problems. And even an identical system. on a sister plant that was a direct copy would have required a full copy and duplication of that MES.
speaker-2: This is sort of where the problem is, is because you have this spectrum of build versus buy. whereas this is like you're kind of building it almost to a fault custom in each instance. And then on the other end of the spectrum you have like a red zone where it's just off the shelf. There's very little configuration possible. Like if you want to add a field or something. know, Fuse is like that nice balance of being able to have full customization.
speaker-0: But even beyond that, if I now have that application on two sites, three sites, four sites, and all four sites are very happy, I make a change on site three. I also have to make that same change on one, two, and four. And eventually they divert. And even if they were intended to be the same application, they're eventually going to deviate as custom features are added and changed. Versus if we were doing this today, I probably would have built a platform like that on Fuse. Because then we could have deployed an application to multiple sites with the ability to update at an enterprise level the whole application. But have the ability to customize things as needed for each site.
speaker-1: If you had this knowledge now, would you have just gone right to Fuse then to build what you described? Yeah, it probably would have been the right call.
speaker-2: I like that steel manufacturer they showed us, that architecture.
speaker-1: Did you get through that? Yeah, I love that diagram that Ed drew. Shout out to Ed. That was really impressive. So we're running a little bit long. I hope people are still listening to us. of my takeaway is much of this might feel like inside baseball. Like you guys are longer and deeper in the industry 4.0 community than me. But when I come in from the outside and I look at Fuse and Ignition and even Plex, like I see very different products and I see no reason that they would be considered competitors to one another. And I wouldn't even know that those three companies compete with one another unless there was like scuttlebutt inside baseball in the industry. It would never have occurred to me with my outside eyes that those three consider themselves competitors in any way. very different. What was that? ⁓ that's right. That's right. We went through a little bit that this morning. How did I not say that? We almost didn't touch AI.
speaker-0: We almost forgot the best features though. ⁓ MCP tooling. Almost missed AI. So the three pillars of Fuse, quick, just to reiterate, are the schema designer, the flow designer, and the screen designer. Specifically, the flow designer is most of where their logic happens. And the flow designer gives you the ability to create MCP tools that call flows. And with those connectors on the other side of those flows, you can basically build MCP tooling for anything in your enterprise stack. And that opens up a lot of doors.
speaker-1: That's a big deal. That's a big deal.
speaker-0: other leading platforms have announced the ability to do this in the future. Fuse is doing it now.
speaker-1: Go Craig, go Lance. Kickin' butt, man. I love it. Cool. Well, I think we can wrap there. Any final thoughts, gentlemen? This is good. I am now a card-carrying, tattoo-wearing, fuse fan, and ⁓ in its space, it's the best thing I've ever seen. But it's not the only thing you need to run an entire manufacturing org.
speaker-0: Yeah, when you look at in the air you see Zoff and deal from there.
speaker-1: Awesome.
speaker-1: Yeah. Well guys, it's been a crazy week at bootcamp. And so we're going to now discuss everything that we learned about Fuse, what we liked. I'll kick it off if you don't mind. I am well known for being both a finance guy and a predictive maintenance guy. What I'm most excited about is the fact that I can use Fuse to integrate local plant floor like master work center data with the financials and then know real time variances against STEM. So for me on the finance side, the thing that I'm most excited about is the ability to actually build the infrastructure for real time variances against standard. So the general manager of the manufacturing business does not have to guess and wait until 10 days after quarter closed to know what the actual gross margin was. That was something that gave me many ulcers when I was running a plant. And I'm so happy that people in the future don't have to do that. And then on the predictive maintenance side, I learned that Fuse doesn't do predictive maintenance props. So you probably wouldn't use FUSE to integrate like really sophisticated vibration readings or thermography because the data structure isn't there. FUSE is really meant for relational databases and time series data, like you would find in a SCADA system. It's not really built for doing deep vibration or thermography or motor circuit analysis type work or applying ML learning stuff on top of that. But the good news is there's people that specialize in that. So I don't need FUSE to do that. and we can integrate FUSE with really sophisticated predictive maintenance providers that can then send kind of, they make the diagnostics and they send down simplified scalar data or the presence or absence of a flaw. And I've got FUSE as a platform in the middle that I can send all of that. That's what I'm excited about. I defer to you guys though, how about you?
speaker-2: Yeah, I liked their office. Their office was pretty nice. That was ⁓ nice. ⁓ This podcast room is pretty sick and the whole team is really awesome to meet. What I like about Fuse as a platform is you can use best in class, best of breed software across the different layers of your business from PLM to CRM to ERP. And maybe you've already standardized on like one ERP, but you might have different plants that have different ERPs, or you buy a plant, or you want to upgrade ERPs. Fuse allows you to fuse all those different applications together and still manage it, right? So you don't have to worry about, this automation going to run? What hardware is it running on? So to be able to have that all abstracted, if you're doing from one communication from one plant's ERP to another's. you're going to want to go through the cloud anyways. So to be able to have that cloud enterprise orchestration layer where that's where Fuse kind of sits in my, in my eyes. What I don't like about it is it's kind of hard to explain what it's kind of hard to explain where it fits in the organization. So yeah, but we can get into the more of the challenges, but yeah, that's what I like about it so far.
speaker-1: Nice, nice. How about you Dylan?
speaker-0: Yeah, I guess the first thing that stood out was really that... Everybody here is not just IT or OT. Everybody we met was fluent in manufacturing. They'd been on the plant floor. They knew what they were talking about, but they were also fluent in cloud services and IT and everything that's involved there as well. I'm speaking both languages and having lived both lives. The people are very focused on the product and the feature set and solving problems for their customers. However that may look, whether that means building new connectors, building new features, and just adding more and more onto that product and keeping everything up to speed at the pace the customers are requesting. That drive and attitude was very exciting. The platform itself as an integration platform is really awesome. There's connectors for everything with the flows, being able to integrate as a true integration platform is kind of a big piece for me. But integration platform in an IT sense, not necessarily in an OT sense. but an integration platform for IT that respects OT. It's not an integration platform that you'll see in your SCADA layer. It's an integration platform you're gonna see in your enterprise layer. It works with your enterprise apps, layer four of the Purdue model, not layer two. There's gonna be some overlap with layer three a little bit. It does MES, but it does MES from a cloud perspective. It's standard enforceable data with clear access control and pure integrations in the cloud. It can respect or be... more down the stack as needed or desired, but not any further down than you need it to be. And that's what I like about it as a true integration platform.
speaker-1: I'm good. Yeah, nice. All right, now what could they improve? No company is perfect, no product is perfect. How could it be better? What could they improve on, guys?
speaker-2: Yeah, I think the user journeys could be improved. So whether I'm an admin. I work for the manufacturer and my job is to manage roles of users and permissions. When I log in, I might want to have a different home view versus a developer. When I'm a developer and I log in to Fuse, I want to see all of my objects on the dashboard. I want to see all my flows, maybe the status of those flows, the last time they ran or then from there be able to click into edit a flow, edit a data model or add new data models. Just in general, being able to have a more intuitive user user journey. think that would be one. of the major rooms for improvement.
speaker-1: Nice. Dylan, you want to go next and I'll go last?
speaker-0: Yeah, I guess for me, everything I said about the attitude and the culture of adding features and building everything as fast as the customer can request it is a double edged sword. They have all the features there. Everything's where it needs to be and everything can be done in the platform. There's very little that can't be done in Fuse. But with that comes a lot of the usability piece, kind of like what Zach was talking about on the user interface and how things look and feel. It's the general user journey. Is it intuitive where things are? Is it intuitive that there are even certain features you might not know until you've drilled down months later and just the lack of ability to discover what features are there. Little details in the interface like just... general comforting features like white space and color consistency and things like that that just make the user feel more, more welcomed. Just being able to make different looks and feels for different users and different journeys and different types of whether it's a developer or an end user, they're entering through the same pool, the same portal right now. And just the general feel of that. was very much made with all the best intentions by engineers solving problems. And that's a really great feature to get features out the door, but at some point it needs to be usable. by other integration teams.
speaker-1: more novice the person that's using it. Like right now it was built literally as an iPaaS platform. And so everybody that was using it as a tool was a dev. Like they knew a lot. They understood the architecture inside and out. But now we're getting a, no one would accuse me of being a dev. And now a guy like me is going to start using it. And I got to admit, I got nervous. There was one part where we were discussing change logging and like in what scenario should you or should you not turn on change logging. And like when I'm building a screen, there's a checkbox at one point that if I like did or did not check that the implications on compute time and storage time and app performance were pretty significant. And unfortunately, I don't have the technical chops to really be making that trade-off. Whereas a dev would look at that and be like, Glenn, of course your performance is going to suffer if you do change logging on this particular lot in a time series database. Yeah, that's going to be a nightmare. Don't do that. For God's sake, turn off change logging when you do that. And that wasn't intuitive to me. I didn't know that.
speaker-0: Thank
speaker-1: It's all well and good that it makes sense in retrospect, but it wouldn't have occurred to me that a thing like that might have bad repercussions. ⁓ so yeah, finding a way to both serve, I would consider both of you guys will be power users. And I intend to build on the platform as well, but I'm just not as technical in the coding space as you guys are. And you need a way for a Glenn to not make a foolish mistake, like putting change log on a time series database that's all historicals you don't need it and it slows down your performance.
speaker-0: And even going down a more technical rabbit hole to even for more of the power users, the discoverability of features like change data capture, is that even a thing? It requires you to have discovered that checkbox and know what it means. So it's the prerequisite tribal knowledge is a piece. Being the enterprise layer, it is. And a lot of the connectors either exist in the cloud. or on premise and there's some overlap or something should exist in both. So one of the limitations right now from like an MES perspective is if you have a client who has a very strong UNS already built, it's all cloud-based, multi-site, and we want to hook views on that to maybe the bridge between the UNS and the existing SCADA layers and the ERP, for example, or PLM. Right now, you can't do that without having a... another service running on premise somewhere, going from site to cloud to site back to cloud and various patterns like that. ⁓ like cloud connectivity and MQTT and things like that, ⁓ or even AMQP through the other brokers would be a nice feature to add. Generally, which ones exist where? The other roadblock is very much the only edge, talk about the Edge Gateway, currently through official channels, the only Edge Gateway you can install is on Windows, ⁓ which limits. some of the more IT centric OT deployments who might be running on Docker or Linux instead.
speaker-1: Yeah, I was going to hit that. Do you mind doing a live like tutor me for the next minute and the listeners more importantly, but they're not on-prem, but they have an on-prem broker. And so like they survived the Amazon adage this week just fine. I misunderstood that the reason they survived without any data loss was that there's an on-prem broker and that thing keeps logging. And then once it goes back online, it can send any data that it's stored to the cloud. My technical thinking is muddy and I'm hoping you can just help me understand tutorial style.
speaker-0: That one, from my understanding of AWS outage, there's two pieces. A, even though the cloud service didn't go down, but I think that was more around which data centers happened to be affected and which ones just happened to be running on. But even if this one had been affected and the service went down for an hour or two, if you have a deployment architecture where you're using the edge gateways to connect to things on site and use that to pipe up to the broker in the cloud. There is store and forward methods. There are buffering, there are general bufferings and packaging. And that store and forward is kind of what's going to make it so that even if it does go down for an hour or two, then there is more buffering. And that's not necessarily made to mitigate the impact of like an AWS outage because that really shouldn't happen. That's an extreme edge case. But if your internet goes out for an hour or two, or you lose power or something, but maybe you have some battery backups running your panels and your machinery, but you lose power and your servers and stuff go down, then you can still buffer and store your data locally. And then once connection is restored, it'll send that data up to the cloud and retain all the data that was already there with the correct timestamps and such. And then all those events that happen in the cloud can still trigger and happen as though because the timestamps and the store and forward and all that.
speaker-1: Okay, okay. But it's not on-prem. Here's the distinction I've never quite understood. The gateway is on-prem. It's installed on a server that is somewhere on the premise of the site, but you wouldn't describe this as an on-prem solution in that all of the integration happens in the cloud, right? Help me clarify my thinking on this.
speaker-0: So you've got the Edge Gateway, which has edge connectors, and you've got the actual tenant in the cloud. The tenant in the cloud has cloud connectors that are going to connect to things like your ERP systems and maybe data warehouses and other enterprise applications that are also running in the cloud. Maybe a CMMS, a PLM something, SAP, or just other things that happen to be running in the cloud. Much more IT friendly, but typical IT connectors. Very typical of the iPass suites. Nice. On the Edge gateway side of things, you've got other local, more operational focused data. PLCs, SQL databases, site historians, including some legacy options, all have connectors where you can connect the Edge gateway to the PLC, to OPC servers, to historians, other data stores, legacy SCADA, whatever Brownfield protocols you have, it likely supports. Got it. And the Edge gateway can connect to those. physical devices on premise, model the data locally, run some data flows and such as needed, and then the results of that are stored forward in a buffer before it goes to the cloud. ⁓
speaker-1: Nice, nice. So it's a high-browder brook. Sometimes a customer says, we're on-prem, we don't do any cloud, we have to be on-prem. I don't know if they would accept this as an acceptable.
speaker-0: Fuse is a cloud platform that has an edge component.
speaker-1: a cloud platform with an edge component that will still talk to your machinery if you lose internet connectivity, but it's not an on-prem installed thing.
speaker-0: The Edge component is installed on-prem, but configured and managed through the cloud.
speaker-2: The problem is that Fuse is like six or seven different commercializable products that how do you go to market with that?
speaker-1: That's the other thing they need to improve on, but it's hard. It's really easy to critique. It's hard to tell the story of the value that they add. Whenever somebody comes to your office and they're like, we have a platform that literally integrates to anything you have, cloud or onsite, and we connect everything, and we do strategic analysis of all your stuff, you're like. I'm positive that's BS. You guys don't know anything, please leave. You would never find somebody that says that credible. And if someone right this moment were to be like, pitch me on Fuse, I would say a version of that speech and I would sound like an idiot, like I know nothing. But it literally is like seven different applications that you could choose to use. They have a WMS, you don't have to use it. They have a CMMS, et cetera. The MES is kind of the core, but you don't even have to use that. You could like from scratch kind of build on top of just the core infrastructure. And the market danger is, I remember a business prof once told me, if you ever have a business plan that sounds something like, we do everything, customers can come to us for literally anything in this space, he's like, I can almost promise you you're gonna fail. And so I'm trying to convince myself that like, is the real deal, they found a way not to do everything, but to be extensible enough that like, everything is within reach, just, the Fuse team doesn't have to develop it themselves. And I'm still torn, I'm... ⁓
speaker-0: Good. The difference there in a product versus a platform. Fuse is a platform. It's a toolbox you build on top of. Fuse isn't a WMS. It's not an ERP. It's not a CMMS. Fuse is a platform that has tools that you use to build your own problem, to build your own solutions to problems you're facing. is, and when I say it isn't a WMS, they do have pre-built applications that you can choose to use or not that happen to be a WMS. Those are still examples that were built on the platform that is Fuse. you can customize it or you could build your own WMS your own way using the tools. It's a toolbox. It's a Swiss Army knife. It's a platform, not necessarily a product in another
speaker-2: All the feedbacks that the ⁓ heavy equipment manufacturer gave us was that ⁓ it seems like it could do so much that there's no way we could possibly leverage it for everything that it does. So they get the impression that it's probably pretty expensive. compared to other iPaS solutions that are enterprise scale, it's actually quite cost effective in my opinion.
speaker-0: I mean, even if we were to take the use case of a single site MES and a typical deployment of this, of Fuse as a single site MES that's in the cloud, using other leading platforms with third party modules to build that MES in the cloud is still within a margin the same price.
speaker-1: Yeah, after we ran the numbers, was clear like Fuse would be the default choice for me at the enterprise level. As soon as you're into multiple sites, it's kind of a no-brainer that Fuse fits perfectly.
speaker-2: It's not just the software cost though or services, it's also the hardware. What hardware are you running? Who's maintaining that? If you're not calculating those costs, then you might think, ⁓ this is a lot more affordable. then like, okay, it's affordable. You know, it's like 30 K let's say. then IT had a provision, a SQL server license, and then it was a $200,000 hit. Right. So it's like when you look at the total cost of all of the like to build out your whole stack, not just from software, but hardware support. Maybe you need to add someone on staff to be able to, you know, DevOps DevOps is completely abstracted with a product like this or like 4IR. Like if you take 4IR and Ignition and ⁓ maybe like a Boomi or Workado, more of an enterprise iPaaS, Ignition doesn't even do anything close to that, right? Like there's not a million built-in connectors or, you know, there's data source connectors, but not platform connectors. Like PLM, there's basically no PLM connectors in Ignition.
speaker-0: From a sailor piece's maintainability and total cost of ownership with a platform that's native to the cloud and hosted in the cloud for you versus a platform that was made for on-premise that can be hosted in the cloud. Then there's the complexity of the architecture, ⁓ horizontal scaling, load balancers, and that, well, there are a handful of integrators out there that could implement those features for your platforms. The question of maintainability and internal capabilities. and the people who have those capabilities who could be internal aren't cheap.
speaker-2: This is why integrators started doing hosted SCADA on ignition, like multi-tenant ignition SCADA hosted.
speaker-1: Yeah, it was. Where I landed was if I was doing an MES on a single site, the two pricings were within striking distance of one another. You could plausibly build your MES on top of ignition and or by like an ignition third party MES module and do the implementation. It's within striking distance of the same cost for a single site as Fuse. If it were me personally, if I had a multi-site implementation of MES style workflows, I think Fuse takes the lead pretty quickly because of all of enterprise adaptations. That's why that's so valuable to go for multi-site to use Fuse. But the inverse works too. If someone said to me, you're on a site, ⁓ you need to pick a SCADA, do you want to use Fuse or Ignition? I'd probably default to Ignition if you were doing SCADA only functionality. And it's only like the higher you go in the stack, the more I'm towards, okay, actually now the Fuse value is better. The lower you go in the stack, the more I would choose Ignition as the default. There's some gray zone in the middle that I dare not figure out.
speaker-0: That's where I think the danger is in comparing them as ignition or fuse.
speaker-1: because they're not, I really don't see them as competitive.
speaker-0: We're talking a greenfield site in my opinion today, it will almost always be ignition and fuse. If multi-site enterprise grade MES. You know the data that gets into fuse is either good or it's rejected. It's not validated. And that is from a data side of things, a necessity for any enterprise grade software. And if we start talking about multi-site rollouts, you need that level of standardization. above your 10, 20, 100 sites, but also trying to enforce that level of standard down all the way to the plant floor of all of those sites is a futile attempt. It's almost impossible. And so having the combined ability to have your local fast moving agility that allows you to solve your own problems in real time without affecting
speaker-1: must have.
speaker-0: the standards set at the corporate level and ensuring that you keep the agility and the problem solving capabilities local, but then you also have all of the enforceable standards at the enterprise level and have that integration layer between them, that is that zone where they coexist. And there are a few features that may overlap from time to time, but they are entirely different platforms for entirely different use cases.
speaker-1: Yeah, amen to that. Yeah, like I actually don't want Craig and Lance and team to develop another ignition because there's an ignition. It's there. It's got an ecosystem. It's awesome. We love ignition. We're big fans. Like we don't need that from Fuse. Fuse is to me the best thing I've ever seen for wanting to integrate Plant Floor with ERP and with PLM and with supply chain planning. Like they thought that all the way through like nobody else has. And that's where I want to throw it.
speaker-0: I think ignition and fuse are capable of and should probably be the best of friends.
speaker-1: Yeah, my utopia is stacking them on top.
speaker-2: It's funny that ignition is not like Fuse and Fuse is really not like ⁓ Plex, which is crazy that some organizations and enterprises are evaluating Plex for a solution or use case that would be much better suited for Fuse. If you're listening and you're looking at Plex, you should actually be looking at Fuse most likely because... know, Plex doesn't connect to the things on the plant floor very easily. It doesn't, it has a hard time connecting to the ERP. You know, people are using Plex and they're still using Fuse to connect to their ERPs. ⁓ If you're using NetSuite, it's almost a no-brainer to be using Fuse. So ⁓ yeah, that's what I can't get over is like, you're an, especially at an enterprise, maybe if you're a small to medium, single location steel plant, okay, maybe Plex is the right solution for you.
speaker-0: mess.
speaker-2: Or ignition, right. But the second you start having any scale or complexity or you need to integrate to anything, then yeah. Or you need to run 24-7.
speaker-0: Yeah, and that gets into the sales point again, like what is the product? It's the only commonality between ignition and fuse at the end of the day is they are both platforms for building solutions on top of exactly what those solutions are and how they're made and what they're made to solve. The tools that are in the box are very different. Yeah. And when we start talking about Plex specifically Plex and and flex have a little bit more of a contentious relationship because Plex is an MES and MES that you could build on top of fuse using the tools that the platform provides.
speaker-1: But it's not an alternative, like they said, they actually built a huge business on being an integration layer and I pass on top of It's not like if you have flex, okay, fuses out, then it's quite the opposite actually, they solve the problem.
speaker-0: And that doesn't have to be. I mean, it can connect to an MES or it can be an MES. You can build, and not that it is an MES, but you can build an MES on it. Exactly. It can connect to a CMS or you can build a CMS on top of it. It can connect to a PLM or you can build a PLM. Yeah, totally. It's a toolbox.
speaker-1: So rather than confuse the heck out of the world, plan is for the foreseeable future, when a client asks me what is Ignition, I'm going to say it's a SCADA. It does other stuff, but it's a SCADA platform. That's its origins. That's where it came from. And here's some other cool stuff that you can extend outwards. And for Fuse, don't tell Craig, even though we're recording this, I'm going to say it's an MES. It's fundamentally an MES platform. However, They built it with iPaaS in mind. In fact, it started as an iPaaS platform. And so what you're going to find is everything that you want from the CIO's perspective in an enterprise software platform. And guess what? It was made by manufacturing people. So like they get the MES. The MES module is awesome, but it's just one module. But if pushed into a corner, I'll probably call it an MES before I'll call it an iPaaS platform. But don't tell Craig.
speaker-2: What module would you want to see infused?
speaker-0: Good call. The MQTT Cloud Connector.
speaker-2: Like in terms of like off the shelf application, what would you like?
speaker-1: I mean, what do we you know, be interesting SCP supply chain planning ⁓ really because my big thing is supply chain and factory floor disconnect like that caused me endless hours of pain and my entire team endless hours
speaker-2: I fuse be a good SCP integration tool.
speaker-1: Because they've already got... Or why would they make a SCP? A good SCP. In fact, what they would do is they would design the SCP into the same module as the MES. Because SCP speaks purchase order, order entry, and then interacting with your suppliers. MES speaks factory floor and maybe traceability amongst the stuff that's coming in. But that's not where you order the parts from the suppliers. If you fuse those two together, no pun intended, you can solve a big problem. so item pegging becomes much less complex if they're literally built on the same backend. So if I had to pick one, I would tackle SCP. I would tackle SCP next.
speaker-2: Yeah.
speaker-0: whatever solution we need for the problem the client has at hand. It's a platform. It's a platform for building solutions.
speaker-2: What's the most common problem you're seeing? ⁓
speaker-0: I-PASS, it is integrating your ERP with your plant floor. That may also add MES features and functionality, but at its core, the I-PASS is probably the most valuable piece. Everybody has a SCADA system out there, and almost all of them have struggled to connect it with their ERP. The ones that have successfully connected their SCADA to their ERP have done so at the behest of whatever integration layer that the ERP provider has forced. and they're not always flexible. Sometimes they don't do what you need them to do. Sometimes there are other iPad softwares that can get it done at the end of the day, but cost significantly more than Fuse. And sometimes they just say, no, we don't do that. And the ability to integrate the ERP to the plant floor in a safe, controlled, and standardized way while still providing full functionality and flexibility to conform the product and the solution to your business is what Fuse offers.
speaker-1: It's a no-brainer. It's fused. It immediately comes out of my mouth when I hear that.
speaker-2: To the name to the naysayers or not not the naysayers, but like we have a large ignition audience to the OT kind of focus or they grew up programming PLCs, building SCADA systems and primarily in ignition, what would you say to them if their instinct, admittedly like mine initially, is like, ⁓ I could just connect an ERP in ignition or I could just do this in ignition, what would you say to that person to kind of get them to open their mind about?
speaker-0: do it, the next plant can do it, the next 10 plants can all do it, but you're not all going to do it in the same way. And when the CIO or the VP of IT sees these 10, 20 different ways of doing the same thing, he's oftentimes using different platforms. Some people are going to conglot can congregate on the similar platforms and others are going to use their platforms of choice. Some are going to build custom code applications that aren't maintained and others are going to use legacy platforms that and some yet are going to go and say that you can't do it. And now at an enterprise level, and especially from a security and integration standpoint, there might be five different vendors for the 20 different sites and a couple of custom solutions that all need to be maintained, secured, and nurtured as vendors and partners that the enterprise team just doesn't have the bandwidth or the resources for. At which point, very often, the enterprise team will just retract altogether and say, too bad, this is what we're doing now. And after they've been burned, now you don't get a choice, you're gonna get something that probably works less than what you have and nobody's gonna be happy with the results.
speaker-2: because think this is happening with the customer. Yeah, no, like this is literally happening right now where a customer has like ignition and they're doing UNS and it's organically growing at the plant layer and the enterprise IT team is like, ⁓ there's too much, ⁓ too many vendors. We're gonna standardize on Rockwell. So then they're like, ⁓ we're gonna use PlexMES. And we're like, no, this would be perfect for Fuse.
speaker-1: What? ⁓ Does Plex have your daughter held hostage?
speaker-2: Just flex. They, who knows? I mean, honestly, have I said anything that's incorrect about them? I wish them, I don't wish, I don't wish poorly on them in their-
speaker-1: No, of course, I'm just teasing you.
speaker-2: probably great people, I don't know them. I mean, I know they're great people because a lot of the people here use the word complex. So I know that the people that work at Flex are nice people. So yeah, but it's just a different, and I think that's the challenge that they're overcoming is like, the, people aren't even aware that this is a problem that exists probably. Like I wasn't aware of it. I would have been the guy who said, ⁓ I'll just do this in ignition. I, well, you just said, think it's a perfect. ⁓ is what we found that there's a need for.
speaker-0: And that's the big thing I say to a lot of people who say this, not just about ignition and fuse, but about a lot of things is, yes, you can do it. I mean, you can build an MES in ignition. I've built an MES in ignition. You built an MES in ignition. A lot of us have. But the question is, who maintains it at the end of the day? So an integrator will almost always have the capability to do that. Some end users will be able to build it in-house. But at the end of the day, especially when it's an integrator that comes in to do it and adds this complexity and these custom applications, whether it's built in Ignition, which is arguably way better than the alternative of building some custom code in .NET or Java or something. And most end users don't have the capabilities on their operations teams to be able to manage or maintain these softwares. Even companies that have very mature development teams, they're focused on different, they're resources that are intended for different purposes.
speaker-1: Yeah. Yeah.
speaker-2: But from that end you said, all right, this is a valuable experience because you're like, now I know, you know, I know what I'm talking about. You know, that's really the curse of knowledge. know, people, I bet Steve, you know, you came here and you're like, damn, Steve is just doing this without, like he's a masterful sales professional in the way that he talks and qualifies the client. He's like just executing his process in a way that's just subconscious and totally natural. I bet Steve sometimes doesn't realize how gift he is. You're like, wow, Steve, you're really good, Steve. If you're watching this, Steve, ⁓ we look up to that. And Steve also manages the partner network.
speaker-1: So we are incentivized to say good things about Steve on camera. I'm glad you did that. But yes, you're like to.
speaker-0: So as I said, quick too, based on that back to that MES story before the boot camp, now in hindsight, there was one downside of that is it was very localized. Copying that MES from one site to the other would have been a full migration of a different platform. It was not multi-tenant. We didn't have any way of having these same things in different sites. So it very much architected for that location and those problems. And even an identical system. on a sister plant that was a direct copy would have required a full copy and duplication of that MES.
speaker-2: This is sort of where the problem is, is because you have this spectrum of build versus buy. whereas this is like you're kind of building it almost to a fault custom in each instance. And then on the other end of the spectrum you have like a red zone where it's just off the shelf. There's very little configuration possible. Like if you want to add a field or something. know, Fuse is like that nice balance of being able to have full customization.
speaker-0: But even beyond that, if I now have that application on two sites, three sites, four sites, and all four sites are very happy, I make a change on site three. I also have to make that same change on one, two, and four. And eventually they divert. And even if they were intended to be the same application, they're eventually going to deviate as custom features are added and changed. Versus if we were doing this today, I probably would have built a platform like that on Fuse. Because then we could have deployed an application to multiple sites with the ability to update at an enterprise level the whole application. But have the ability to customize things as needed for each site.
speaker-1: If you had this knowledge now, would you have just gone right to Fuse then to build what you described? Yeah, it probably would have been the right call.
speaker-2: I like that steel manufacturer they showed us, that architecture.
speaker-1: Did you get through that? Yeah, I love that diagram that Ed drew. Shout out to Ed. That was really impressive. So we're running a little bit long. I hope people are still listening to us. of my takeaway is much of this might feel like inside baseball. Like you guys are longer and deeper in the industry 4.0 community than me. But when I come in from the outside and I look at Fuse and Ignition and even Plex, like I see very different products and I see no reason that they would be considered competitors to one another. And I wouldn't even know that those three companies compete with one another unless there was like scuttlebutt inside baseball in the industry. It would never have occurred to me with my outside eyes that those three consider themselves competitors in any way. very different. What was that? ⁓ that's right. That's right. We went through a little bit that this morning. How did I not say that? We almost didn't touch AI.
speaker-0: We almost forgot the best features though. ⁓ MCP tooling. Almost missed AI. So the three pillars of Fuse, quick, just to reiterate, are the schema designer, the flow designer, and the screen designer. Specifically, the flow designer is most of where their logic happens. And the flow designer gives you the ability to create MCP tools that call flows. And with those connectors on the other side of those flows, you can basically build MCP tooling for anything in your enterprise stack. And that opens up a lot of doors.
speaker-1: That's a big deal. That's a big deal.
speaker-0: other leading platforms have announced the ability to do this in the future. Fuse is doing it now.
speaker-1: Go Craig, go Lance. Kickin' butt, man. I love it. Cool. Well, I think we can wrap there. Any final thoughts, gentlemen? This is good. I am now a card-carrying, tattoo-wearing, fuse fan, and ⁓ in its space, it's the best thing I've ever seen. But it's not the only thing you need to run an entire manufacturing org.
speaker-0: Yeah, when you look at in the air you see Zoff and deal from there.
speaker-1: Awesome.
