Inductive Automation Blog
Connecting you to ideas, tips, updates and thought-leadership
from Inductive Automation
Discussing Architectures
Joanna Cortez
Fri, 05/22/2020 - 11:23
Lauren and Shay invite Co-Director of Sales Engineering Travis Cox to walk us through architecting an Ignition system, and to show how Ignition can be used anywhere from a local HMI client to a full enterprise solution and everything in between. Travis shares best practices for getting started, building a foundation, asking the right questions, and building out an architecture. Travis begins with the structure of a basic Ignition architecture and explains the process of when and how to build out from there. We cover adding new functionality, adding redundancy, store and forward, Ignition Edge, MQTT, scale-out, adding a load balancer, streaming data to the cloud, and having visibility across an enterprise.
Hero
Integrator Program Level
Thumbnail
Wistia ID
ybb0qgh21q
Learning Series
Transcription
00:08
Lauren: Welcome back to our sales training videos. I'm Lauren.
00:11
Shay: And I'm Shay. Today we'll be going through how to architect an Ignition system, showing how Ignition can be used anywhere from a local HMI client to a full enterprise solution and everywhere in between.
00:20
Lauren: We're sitting down with Travis Cox, Co-Director of Sales Engineering, to talk best practices and more. Travis, thanks for joining us.
00:27
Travis: Excited to be here.
00:28
Lauren: We are excited to talk to you a lot about the different Ignition architectures, but I thought we would start with kind of a softball question?
00:39
Travis: Okay, sure.
00:39
Lauren: Or maybe more of a bowling ball question: We heard a rumor that you are a champion bowler?
00:46
Travis: Well, I have been bowling since I was nine years old and I have been a regional pro for quite some years. And I'm very much active in bowling leagues and tournaments and I have 45 300 so I'm... been … bowling’s been a pretty big part of my life.
01:01
Lauren: That's awesome.
01:02
Shay: Yeah, so with this, we're gonna be talking about architecting Ignition systems. But it's not just about picking out a diagram; largely, we'll also be looking at how Ignition can scale, right?
01:14
Travis: Absolutely, yeah, we're gonna show how Ignition can be used from anywhere from a local HMI, something really small, maybe just an historian or alarming solution, all the way to a full enterprise solution and everywhere in between. So, Ignition has a large, wide range of applicability here.
01:28
Lauren: Well, we're really excited to dive in, but we wanted to kind of start with the basis which is that knowledge of Ignition, that's really central to building out any architecture.
01:38
Travis: Yeah, absolutely. In order to really build architectures correctly, we have to have a good foundation of understanding of what Ignition can do and that really requires understanding what every single module of Ignition, what it provides to the platform and all the features that those modules provide; understanding the technical considerations there are; understanding user requirements; and of course, the environment that Ignition's is going into, as well. You have to have the full picture, so once you have that, then you can start putting the pieces together correctly.
02:05
Shay: So, with looking at building this foundation, where do we recommend people get started with Ignition?
02:10
Travis: So, we recommend getting started with a really basic architecture. And that would be to simply have an Ignition server that could be installed on a desktop, a laptop, a high-grade server, could be a virtual machine, something small, that has, a couple of modules for Ignition so it could be our OPC UA module and drivers to some PLCs to basically connect to PLCs, bring some data in, and maybe the historian just to log historical data to get some data into the database so we can see over time. So, start really, really small with just using a couple of modules for Ignition.
02:41
Lauren: And where would I put that server?
02:43
Travis: So that server could be anywhere from the plant floor, right next to the PLC, if you will; there's embedded PCs and people who have desktops on the plant floor at their desk there; could be all the way in the IT room in a server room, centrally; could be in a virtual environment; could be on-premise, could be in the cloud. Of course, typically it is on-premise for these systems, but it can be anywhere, it just depends on what makes the most sense for where they wanna put it.
03:07
Shay: So, once we get started with maybe a smaller project, like you said, maybe using it just for a historian or for alarming, what do we need to do to start building that out and adding more functionality?
03:19
Travis: Yeah, so once we have that server in place, essentially, if we have a couple modules and we're got a project configured, we're getting some success, we can easily then add additional modules to add more functionality to that server. So an example I used before where I just had the OPC UA server and the drivers to some PLCs and the tag historian, which is just a local historian, then we can add the visualization, so maybe Vision or Perspective and then we can start building out applications and providing that to people as a client anywhere within the facility, whether it's right there on the plant floor, or whether it's back at their desk, or even on their mobile devices.
03:51
Lauren: And let's say I have my system, but I wanna add some new functionality through a module, but I don't want it to affect my current system. How does that work?
04:00
Travis: Yeah. So, there's some people that have a system already in place and you could easily add a module to it, but they're worried about affecting that particular server, that instance, then they could simply just add an additional server. We can break up our modules onto different servers very easily; so here, I've got two servers: I've got the existing system and then I've got a brand new one with just that new module or that new version or functionality, and we will connect those together. It'll be one big system at the end of the day, but it'll be separated on two different machines so they don't affect each other.
04:28
Lauren: So, with the architecture that we're looking at now we're seeing a single point of failure. So, what happens if the server fails? Can I add redundancy to that?
04:35
Travis: Yes, that's a great question and one that we get quite often. Certainly, if I have one central server, and that's the one that's connected to all the PLCs and that's the ones launching out clients to everybody; if that server crashes, we're gonna be down. We're gonna lose data, we're gonna lose visibility, and that's not good, right? So, we got to have protection against server crashing or potentially network outages, things like that. So, there are two ways we can do redundancy. One would be software density, which is what we provide. So, we can have two Ignition servers, one would be the master, one would be the backup. Very simple to configure, we simply, after we get the master configured, we go to the backup, point it to the master and they'll be synchronized. So, at that point, if the master was to crash, the backup would take over automatically for us and we wouldn't lose anything in terms of data or visibility of the application.
05:19
Travis: Software density also protects us from being able to patch the operating system because if I patch the operating system, I have to restart the machine, and that way, if I had a redundant pair, I can move the primary to the backup, patch my master. Then once that's done, the primary will come back to master, we can then patch the back-up, and we're good to go. Another form of redundancy is harbor redundancy, which doesn't protect you against the OS patching, but it is the stuff that a lot of customers are doing, especially in virtual environments where they can have clusters setup and easily have a VM that would run across an array of servers in that case; so it's less licensing, but it doesn't protect you in all the cases.
05:58
Lauren: Now, what happens if I lose communication to a PLC from a central server?
06:04
Travis: Yeah, that's also a great question, right? Again, I have one central server, I have to rely on my network and I have to have communication to those PLCs. As I said, there's got to be protection against server crashing, as well as network outages. So, if I have a lot of hops to get to that device, that could be a lot of points of failure. We have stories of forklifts cutting the fiber from the main room to some other building, and if that happens, of course, we lose that data because we have no longer to be able to talk to the PLC. So, it can be really important for critical machines to move the connection or the polling closer to that device. And so, in this particular case, I've got using Ignition Edge here, right there next to the PLC so I can talk to the PLCs locally. Again, there's really a lot less risk for losing communication to that PLC right next to it, and I can do store-and-forward, and I can bring that data back to our central system so that way we never have any loss of the data.
07:03
Shay: Now with the edge-of-network functionality, we know there are lots of benefits to using MQTT. And we're seeing a lot of sensors that are starting to support that natively. So where does that fit into this picture?
07:13
Travis: Yeah, so in this particular case, there's a couple different ways we can bring that data from the Ignition Edge, up to the central Ignition server. So one of the ways is through our Gateway Network, which has services and we'll go through that in some more detail. But the other method is MQTT, where we can have all the PLC data being brought up, published up through MQTT, or we can utilize that for other applications besides Ignition. So if we take a look at this diagram here, that shows the same Ignition Edge that we have locally, so again, polling the PLCs locally, bringing the data back up through MQTT, but once we have the infrastructure in place, then that allows us to add additional new sensors, new equipment that does speak MQTT directly, and we can just plug it into our infrastructure. Especially if they have store-and-forward capabilities, as well, then we have it from our legacy devices, as well as our new devices, being able to leverage all of that in our application.
08:04
Lauren: Awesome. Now, what happens if I lose communication between my client and the central server?
08:09
Travis: Another great question, right? So if I'm out there on the plant floor and I have my client that is talking to my central server, we fix the issue whereof our data, we'll have store-and-forward there, locally, but then now our client would be rendered useless; it has to connect to that central server. So in that scenario, we gotta have something local, as well, if we're worried about our network. So instead of having those clients talk directly to the central server, we can have... You can use Ignition Edge, in particular our Panel product, which can provide a local HMI. It's a low-cost, one client HMI that we can have right on that machine, on that critical asset, to guarantee that visibility if we lose communication to our network. We still, of course, can open up clients anywhere from the central server. When that network is good, I can have a client open right there on the plant floor or anybody's office, but this guarantees that on that machine, the operator can walk up to it at any given time, and he can see what the process is and control that process right there.
09:02
Shay: What about talking about lots of PLCs or lots of tags. So essentially, how do we get into scalability with Ignition?
09:09
Travis: Yeah, so that's a good question. Ignition's licensing is unlimited, so that gives you not only the tags, screens, clients, device connections, projects, and more, so once we have that server in place, we can continue adding on to it. We can add more PLCs, we can add more people to look at that data. And that all is great, but we do run into hardware considerations when that happens. There's only so much we can run on a given piece of hardware. Now, if you're on a Raspberry Pi, obviously, it's gonna be a lot smaller than if we're on a high-grade server that's in our facility, so we do, at some point, have to consider the amount of data that's out there. And a kind of good rule of thumb is if you're over 100,000 tags, you might wanna consider looking at a more scaled-out architecture or utilizing more resources or at least pay a lot more attention to these numbers.
09:54
Travis: So in that case, though, we could easily, if rather than having one central server that does everything, both the IO and the front end, we could easily split that apart into two servers. We can move the modules that are responsible for the IO on one side, and then move the modules that are responsible for the front end on the other side, as we're seeing here. So I've got these two servers, I/O here and front end, and now we have dedicated resources to those two pieces so we can scale them up easily and have more that's available on each of those sides... So more clients on the front end, more tags on the back end. But again, still at some point, we're gonna get to a place where those servers might be overrun.
10:30
Lauren: Now, when you separate those two out, what happens to my cost?
10:34
Travis: Yeah, that's a great question. So if I have one server, it's gonna have all the modules on that server that I wanted to purchase and that'd be one license that they got from Inductive Automation. If I wanna split that into two, where I move half the modules on one, half module on the other, there's no change in price. All we gotta do is provide two licenses in that case, so it's a free way of being able to utilize more resources in that case.
10:54
Shay: Awesome. So can I add more I/O servers as my number of devices and tags is growing then?
11:00
Lauren: Absolutely, that's the great thing about it: Once we have started out this scaled-out architecture, we can easily horizontally scale each side of the fence, whether it's the tags on the IO side, or it's the front-end side. So here I'm showing one I/O server that's connected to a certain set of PLCs. If I then want to add an additional I/O server, no problem. We can bring that in the mix and we can bring all that into the same application server that we have so we can easily scale those out. If I have millions of tags, I'm gonna wanna have multiple I/O servers out there to handle all those tags.
11:29
Shay: And then what if I have hundreds of people who want to see my client?
11:33
Travis: So as we scale-out, we're not only scaling out tags, we're scaling out the front end, we're scaling out people that wanna look at that data on those clients. And so in this particular case, I have one application server, and you could probably get around a couple hundred people looking at that data the same time, but if I have thousands, we're gonna need to look at a different approach which would be to simply have multiple front-end servers. And in this particular case, we can put them in front or put them behind a load balancer, so everybody has one access point, which is the load balancer, could be an IP address or hostname to that, and then they can get access to clients, but we have the ability to have really thousands and as many as we want behind the scenes.
12:08
Lauren: So, Travis, you talked about redundancy earlier, but I'm not seeing any redundancy on this particular architecture. How would we go about adding redundancy?
12:17
Travis: Yes, that's a great question. So really, anywhere we put Ignition, we could have a redundant backup for that. And so we do have to consider where we should have redundancy and where we shouldn't have redundancy. It does, of course, increase the amount of servers we have and increases the cost when we look at redundancy. And so I left it out of these diagrams because it just makes the diagrams a little more complicated, but I could have redundancy here on the Ignition Edge side... I can have two servers out there locally, one that's a master, one's a backup, no problem. I can also have it, of course, on the I/O side here where I can have redundancy on the I/O and typically that's where people are doing it, on the I/O, whether it's local on the critical machines, or it's on the central, they usually put redundancy on that side 'cause you don't wanna lose data and you wanna make sure you're logging all of that.
13:00
Travis: On the front-end side, however, you may or may not want redundancy. It may be okay that if the server crashes, the applications down for a few minutes, no big deal. But it may not, so with some of our very critical applications. But if you look at this diagram, I would place redundancy on the Ignition Edge side on the I/O servers, but in this, here we have these three front-end servers that are behind the load balancer... That actually already is redundant. It has high availability in this case, so if I were to lose a front-end server, no big deal. All the clients would switch over to the remaining two that are there and I could have a lot more of these. So actually in this scale-out, we do get redundancy automatically with the front-ends having multiple of them, but we do have to consider redundancy on everything else.
13:41
Shay: Why are front-end servers behind a load balancer treated differently than I/O servers in regards to redundancy?
13:47
Travis: The answer is actually pretty simple: It's because they have different use cases. So the I/O servers are talking to a set of devices and they have tags, and that requires state so we have alarms that are happening there, long-running processes that are going on and we only want one set of those, so it has to be redundant for the I/O side. On the front-end side, though, we can have as many of these as we want because it's stateless. It's just an application and the application is getting the data from the I/O over at Gateway network or from the database directly, so we have high availability here and I can have hundreds of those servers that are starting up the same application at the end of the day.
14:21
Shay: So we have customers that have different OT networks from their IT networks and so when those cases were often implementing a DMZ layer, what does that look like with Ignition?
14:31
Travis: Yeah, so in these diagrams that I've been showing, the clients that we have are typically opened on the OT side of the fence which is usually there's an OT Network and then there's a business network or an IT network that's there and often they don't cross; There's firewalls that prevent those kind of things. And so, it does limit if, where I can actually open up the client, because of the network that's out there. So typically I can open the clients anywhere on the OT side, but then the business wants to get access to the data, licensing model for Ignition's unlimited so why not? The network gets in the way. And so in this particular case, it can be important to add Ignition on the DMZ side.
15:09
Travis: So if you look at this network here, this diagram, I've got DMZ where I can install an Ignition server with the visualization, so that can be Vision or Perspective, and we can connect that server... So it's an additional server with an additional license, unfortunately, but we can connect that server to the OT server so we can allow that. And using Ignition's Gateway Network, we can have all the same data. We can have the same application that we have on that side now available to the business so they can have lots of people out there getting access to it. And this is the most secure way of doing it. There are companies that will just simply open up firewalls or allow port forward, things like that, to get access to it and that's perfectly fine, as well. That does take advantage of Ignition's licensing model, but this allows it for the best security possible.
15:51
Lauren: So we've been focusing on visibility at the site level. What happens if I want to have visibility across an enterprise?
16:00
Travis: Yeah, it's a great question. So all the architecture diagrams we've shown so far have been... Have all those servers at that site, on-premise there. It would be able to handle that functionality locally. And it's true that I could put all that stuff at the corporate level and I can use Ignition's unlimited licensing model to talk to all devices across all different sites. It’s just not done in practice because, traditionally, that is over the WAN connection which could go down, right? We can't guarantee that connection from corporate to all the sites. So usually, we're talking about deploying a set of Ignition servers locally but as your question there is, we wanna get data visible centrally, as well. And so that's where, if we had a lot of different sites, we can bring it up to a corporate level for visibility of all that data, as well as management of all the Ignition systems we've got out there. It's easy to manage one Ignition installation but if you've got hundreds of them, you've got a lot of things to back up. You got a lot of things to consider. So when you look at a full enterprise solution, you wanna make that part really simple. You wanna have people in the corporate side to see data across all their locations and to make it easy for IT to manage the system.
17:06
Travis: So here, if you look at this diagram, I got two sites and I can have many, many other sites in there but that's got the Ignition systems whether it's the Edge products locally, whether it's the full Ignition server at that site or a scaled architecture at that site, whatever it may be... Each side could certainly be different than others, you have to look at the requirements of that site, but we can then connect those sites up to a central Ignition gateway, where we can look at the data. We can see all the live values of tags with our Gateway Network, we can see the history, we can pull history from those sites. We can easily mirror data, historical data, from those sites to a centralized database, as well, so we can get visibility there at the corporate level. We can see all the alarms that are happening across all the sites, a lot of visibility there. But more importantly, we have the management so we can use Ignition's enterprise administration module to centrally take backups of all those servers, to check the health and diagnostics of those servers, to be able to essentially manage a license, to remotely upgrade those servers and more. There are a lot of tasks that we can run with that, so it just makes it really easy to bring those up to a centralized system and to get that visibility and get that management going.
18:17
Shay: So what happens if I have a DMZ between a site and that corporate layer?
18:21
Travis: Yeah, so that's a good question. A lot of people, again, the DMZ,those layers, they want protections in there and so that the OT side would very much be that lower layer they'd wanna protect and the business side would be an IT side, higher layer and they don't talk to each other, although they can through a DMZ, right? But the business side cannot go to the OT side directly and the OT side can't go to the business side directly, but they can both talk to a middle layer. And so, that's a very common approach whether that's at the site level or whether it's between the site and corporate. It'd be really easy, in this particular case, to introduce Ignition in the DMZ, that really is gonna act as a proxy, between the site and the corporate location so that all of the services in management I was mentioning can just funnel through that proxy. So we can still get access to that and they get all the protections that are in place of a DMZ.
19:08
Lauren: Now, what if I want to leverage the cloud or even inject data into the cloud?
19:13
Travis: We can do that really at any layer, whether we do that at the site or that we do that at corporate. There are modules in Ignition that deal with getting data to the cloud. So we can utilize MQTT, for sure, we also have direct injectors to all the major cloud platforms, so whether it's Azure, or AWS, or IBM Cloud, or Google Cloud. Any of those, we can get that data, stream it up to the cloud and work with it. And so, that just put data up there and utilize their services. But keep in mind that we could also deploy Ignition to the cloud. We can have a hybrid approach, where we have our centralized corporate system and management in the cloud and we have all of the servers on site, locally there, so that we can guarantee that functionality right there at the site.
19:56
Lauren: As I go try and help customers architect systems, what sort of questions should I be asking?
20:01
Travis: A million questions. Unfortunately, we have to really probe the customer for these details. It really starts with first understanding their requirements. So what sorts of applications are they trying to build? Are they... That would determine what modules for Ignition that we need. And we also have to look at that network in a lot more detail, typically get involved with IT, we gotta understand what the layers look like. Are there DMZs that we have in here? Are there firewall considerations that IT wants, or security concerns that are there? And we have to know are there any points in that network where we could have the link cut? 'Cause that of course is one of the biggest considerations of architecting, is network failures.
20:40
Travis: If we have that, we've gotta put more robustness in, which means Edge products closer to PLCs and the redundancy, those kinda things in place. So we really have to understand that network. We also have to understand, not only the functions they want, but how big is this? What kinda devices are we talking to? What type of devices are they? How many tags are we dealing with in a day? How many clients, how many people wanna look at that data? What does it look like today and what's it gonna look like five years from now? Because I don't wanna put a system today that's gonna hinder me five years from now when I wanna scale that and make it bigger. So unfortunately, there's a lot of questions we have to look at, what's not only what they need now, but what they need in the future and sort of architect around that because there are considerations, especially in how we build projects for those kind of things. So unfortunately, there's a lot of questions, but you get used to them after a while and it gets a little easier as you go forward.
21:31
Lauren: Well, Travis, we're so glad we got to sit down with you today, thank you so much.
21:35
Travis: Thanks for having me.
21:36
Lauren: Any final takeaways for our viewers?
21:39
Travis: Yeah, so there's a lot of different ways we can architect systems, and it really comes down to having fundamental knowledge of Ignition, the modules, the features that are there, so once we have that foundation, we can then put an architecture in place that protects us from things, like network loss. So we really gotta look at the network and communication issues, and also the sheer size. How big is these systems gonna get? Are they gonna grow? Because those are two big things that will help us in how we architect that from the beginning, and do it correctly.
Lauren: Welcome back to our sales training videos. I'm Lauren.
00:11
Shay: And I'm Shay. Today we'll be going through how to architect an Ignition system, showing how Ignition can be used anywhere from a local HMI client to a full enterprise solution and everywhere in between.
00:20
Lauren: We're sitting down with Travis Cox, Co-Director of Sales Engineering, to talk best practices and more. Travis, thanks for joining us.
00:27
Travis: Excited to be here.
00:28
Lauren: We are excited to talk to you a lot about the different Ignition architectures, but I thought we would start with kind of a softball question?
00:39
Travis: Okay, sure.
00:39
Lauren: Or maybe more of a bowling ball question: We heard a rumor that you are a champion bowler?
00:46
Travis: Well, I have been bowling since I was nine years old and I have been a regional pro for quite some years. And I'm very much active in bowling leagues and tournaments and I have 45 300 so I'm... been … bowling’s been a pretty big part of my life.
01:01
Lauren: That's awesome.
01:02
Shay: Yeah, so with this, we're gonna be talking about architecting Ignition systems. But it's not just about picking out a diagram; largely, we'll also be looking at how Ignition can scale, right?
01:14
Travis: Absolutely, yeah, we're gonna show how Ignition can be used from anywhere from a local HMI, something really small, maybe just an historian or alarming solution, all the way to a full enterprise solution and everywhere in between. So, Ignition has a large, wide range of applicability here.
01:28
Lauren: Well, we're really excited to dive in, but we wanted to kind of start with the basis which is that knowledge of Ignition, that's really central to building out any architecture.
01:38
Travis: Yeah, absolutely. In order to really build architectures correctly, we have to have a good foundation of understanding of what Ignition can do and that really requires understanding what every single module of Ignition, what it provides to the platform and all the features that those modules provide; understanding the technical considerations there are; understanding user requirements; and of course, the environment that Ignition's is going into, as well. You have to have the full picture, so once you have that, then you can start putting the pieces together correctly.
02:05
Shay: So, with looking at building this foundation, where do we recommend people get started with Ignition?
02:10
Travis: So, we recommend getting started with a really basic architecture. And that would be to simply have an Ignition server that could be installed on a desktop, a laptop, a high-grade server, could be a virtual machine, something small, that has, a couple of modules for Ignition so it could be our OPC UA module and drivers to some PLCs to basically connect to PLCs, bring some data in, and maybe the historian just to log historical data to get some data into the database so we can see over time. So, start really, really small with just using a couple of modules for Ignition.
02:41
Lauren: And where would I put that server?
02:43
Travis: So that server could be anywhere from the plant floor, right next to the PLC, if you will; there's embedded PCs and people who have desktops on the plant floor at their desk there; could be all the way in the IT room in a server room, centrally; could be in a virtual environment; could be on-premise, could be in the cloud. Of course, typically it is on-premise for these systems, but it can be anywhere, it just depends on what makes the most sense for where they wanna put it.
03:07
Shay: So, once we get started with maybe a smaller project, like you said, maybe using it just for a historian or for alarming, what do we need to do to start building that out and adding more functionality?
03:19
Travis: Yeah, so once we have that server in place, essentially, if we have a couple modules and we're got a project configured, we're getting some success, we can easily then add additional modules to add more functionality to that server. So an example I used before where I just had the OPC UA server and the drivers to some PLCs and the tag historian, which is just a local historian, then we can add the visualization, so maybe Vision or Perspective and then we can start building out applications and providing that to people as a client anywhere within the facility, whether it's right there on the plant floor, or whether it's back at their desk, or even on their mobile devices.
03:51
Lauren: And let's say I have my system, but I wanna add some new functionality through a module, but I don't want it to affect my current system. How does that work?
04:00
Travis: Yeah. So, there's some people that have a system already in place and you could easily add a module to it, but they're worried about affecting that particular server, that instance, then they could simply just add an additional server. We can break up our modules onto different servers very easily; so here, I've got two servers: I've got the existing system and then I've got a brand new one with just that new module or that new version or functionality, and we will connect those together. It'll be one big system at the end of the day, but it'll be separated on two different machines so they don't affect each other.
04:28
Lauren: So, with the architecture that we're looking at now we're seeing a single point of failure. So, what happens if the server fails? Can I add redundancy to that?
04:35
Travis: Yes, that's a great question and one that we get quite often. Certainly, if I have one central server, and that's the one that's connected to all the PLCs and that's the ones launching out clients to everybody; if that server crashes, we're gonna be down. We're gonna lose data, we're gonna lose visibility, and that's not good, right? So, we got to have protection against server crashing or potentially network outages, things like that. So, there are two ways we can do redundancy. One would be software density, which is what we provide. So, we can have two Ignition servers, one would be the master, one would be the backup. Very simple to configure, we simply, after we get the master configured, we go to the backup, point it to the master and they'll be synchronized. So, at that point, if the master was to crash, the backup would take over automatically for us and we wouldn't lose anything in terms of data or visibility of the application.
05:19
Travis: Software density also protects us from being able to patch the operating system because if I patch the operating system, I have to restart the machine, and that way, if I had a redundant pair, I can move the primary to the backup, patch my master. Then once that's done, the primary will come back to master, we can then patch the back-up, and we're good to go. Another form of redundancy is harbor redundancy, which doesn't protect you against the OS patching, but it is the stuff that a lot of customers are doing, especially in virtual environments where they can have clusters setup and easily have a VM that would run across an array of servers in that case; so it's less licensing, but it doesn't protect you in all the cases.
05:58
Lauren: Now, what happens if I lose communication to a PLC from a central server?
06:04
Travis: Yeah, that's also a great question, right? Again, I have one central server, I have to rely on my network and I have to have communication to those PLCs. As I said, there's got to be protection against server crashing, as well as network outages. So, if I have a lot of hops to get to that device, that could be a lot of points of failure. We have stories of forklifts cutting the fiber from the main room to some other building, and if that happens, of course, we lose that data because we have no longer to be able to talk to the PLC. So, it can be really important for critical machines to move the connection or the polling closer to that device. And so, in this particular case, I've got using Ignition Edge here, right there next to the PLC so I can talk to the PLCs locally. Again, there's really a lot less risk for losing communication to that PLC right next to it, and I can do store-and-forward, and I can bring that data back to our central system so that way we never have any loss of the data.
07:03
Shay: Now with the edge-of-network functionality, we know there are lots of benefits to using MQTT. And we're seeing a lot of sensors that are starting to support that natively. So where does that fit into this picture?
07:13
Travis: Yeah, so in this particular case, there's a couple different ways we can bring that data from the Ignition Edge, up to the central Ignition server. So one of the ways is through our Gateway Network, which has services and we'll go through that in some more detail. But the other method is MQTT, where we can have all the PLC data being brought up, published up through MQTT, or we can utilize that for other applications besides Ignition. So if we take a look at this diagram here, that shows the same Ignition Edge that we have locally, so again, polling the PLCs locally, bringing the data back up through MQTT, but once we have the infrastructure in place, then that allows us to add additional new sensors, new equipment that does speak MQTT directly, and we can just plug it into our infrastructure. Especially if they have store-and-forward capabilities, as well, then we have it from our legacy devices, as well as our new devices, being able to leverage all of that in our application.
08:04
Lauren: Awesome. Now, what happens if I lose communication between my client and the central server?
08:09
Travis: Another great question, right? So if I'm out there on the plant floor and I have my client that is talking to my central server, we fix the issue whereof our data, we'll have store-and-forward there, locally, but then now our client would be rendered useless; it has to connect to that central server. So in that scenario, we gotta have something local, as well, if we're worried about our network. So instead of having those clients talk directly to the central server, we can have... You can use Ignition Edge, in particular our Panel product, which can provide a local HMI. It's a low-cost, one client HMI that we can have right on that machine, on that critical asset, to guarantee that visibility if we lose communication to our network. We still, of course, can open up clients anywhere from the central server. When that network is good, I can have a client open right there on the plant floor or anybody's office, but this guarantees that on that machine, the operator can walk up to it at any given time, and he can see what the process is and control that process right there.
09:02
Shay: What about talking about lots of PLCs or lots of tags. So essentially, how do we get into scalability with Ignition?
09:09
Travis: Yeah, so that's a good question. Ignition's licensing is unlimited, so that gives you not only the tags, screens, clients, device connections, projects, and more, so once we have that server in place, we can continue adding on to it. We can add more PLCs, we can add more people to look at that data. And that all is great, but we do run into hardware considerations when that happens. There's only so much we can run on a given piece of hardware. Now, if you're on a Raspberry Pi, obviously, it's gonna be a lot smaller than if we're on a high-grade server that's in our facility, so we do, at some point, have to consider the amount of data that's out there. And a kind of good rule of thumb is if you're over 100,000 tags, you might wanna consider looking at a more scaled-out architecture or utilizing more resources or at least pay a lot more attention to these numbers.
09:54
Travis: So in that case, though, we could easily, if rather than having one central server that does everything, both the IO and the front end, we could easily split that apart into two servers. We can move the modules that are responsible for the IO on one side, and then move the modules that are responsible for the front end on the other side, as we're seeing here. So I've got these two servers, I/O here and front end, and now we have dedicated resources to those two pieces so we can scale them up easily and have more that's available on each of those sides... So more clients on the front end, more tags on the back end. But again, still at some point, we're gonna get to a place where those servers might be overrun.
10:30
Lauren: Now, when you separate those two out, what happens to my cost?
10:34
Travis: Yeah, that's a great question. So if I have one server, it's gonna have all the modules on that server that I wanted to purchase and that'd be one license that they got from Inductive Automation. If I wanna split that into two, where I move half the modules on one, half module on the other, there's no change in price. All we gotta do is provide two licenses in that case, so it's a free way of being able to utilize more resources in that case.
10:54
Shay: Awesome. So can I add more I/O servers as my number of devices and tags is growing then?
11:00
Lauren: Absolutely, that's the great thing about it: Once we have started out this scaled-out architecture, we can easily horizontally scale each side of the fence, whether it's the tags on the IO side, or it's the front-end side. So here I'm showing one I/O server that's connected to a certain set of PLCs. If I then want to add an additional I/O server, no problem. We can bring that in the mix and we can bring all that into the same application server that we have so we can easily scale those out. If I have millions of tags, I'm gonna wanna have multiple I/O servers out there to handle all those tags.
11:29
Shay: And then what if I have hundreds of people who want to see my client?
11:33
Travis: So as we scale-out, we're not only scaling out tags, we're scaling out the front end, we're scaling out people that wanna look at that data on those clients. And so in this particular case, I have one application server, and you could probably get around a couple hundred people looking at that data the same time, but if I have thousands, we're gonna need to look at a different approach which would be to simply have multiple front-end servers. And in this particular case, we can put them in front or put them behind a load balancer, so everybody has one access point, which is the load balancer, could be an IP address or hostname to that, and then they can get access to clients, but we have the ability to have really thousands and as many as we want behind the scenes.
12:08
Lauren: So, Travis, you talked about redundancy earlier, but I'm not seeing any redundancy on this particular architecture. How would we go about adding redundancy?
12:17
Travis: Yes, that's a great question. So really, anywhere we put Ignition, we could have a redundant backup for that. And so we do have to consider where we should have redundancy and where we shouldn't have redundancy. It does, of course, increase the amount of servers we have and increases the cost when we look at redundancy. And so I left it out of these diagrams because it just makes the diagrams a little more complicated, but I could have redundancy here on the Ignition Edge side... I can have two servers out there locally, one that's a master, one's a backup, no problem. I can also have it, of course, on the I/O side here where I can have redundancy on the I/O and typically that's where people are doing it, on the I/O, whether it's local on the critical machines, or it's on the central, they usually put redundancy on that side 'cause you don't wanna lose data and you wanna make sure you're logging all of that.
13:00
Travis: On the front-end side, however, you may or may not want redundancy. It may be okay that if the server crashes, the applications down for a few minutes, no big deal. But it may not, so with some of our very critical applications. But if you look at this diagram, I would place redundancy on the Ignition Edge side on the I/O servers, but in this, here we have these three front-end servers that are behind the load balancer... That actually already is redundant. It has high availability in this case, so if I were to lose a front-end server, no big deal. All the clients would switch over to the remaining two that are there and I could have a lot more of these. So actually in this scale-out, we do get redundancy automatically with the front-ends having multiple of them, but we do have to consider redundancy on everything else.
13:41
Shay: Why are front-end servers behind a load balancer treated differently than I/O servers in regards to redundancy?
13:47
Travis: The answer is actually pretty simple: It's because they have different use cases. So the I/O servers are talking to a set of devices and they have tags, and that requires state so we have alarms that are happening there, long-running processes that are going on and we only want one set of those, so it has to be redundant for the I/O side. On the front-end side, though, we can have as many of these as we want because it's stateless. It's just an application and the application is getting the data from the I/O over at Gateway network or from the database directly, so we have high availability here and I can have hundreds of those servers that are starting up the same application at the end of the day.
14:21
Shay: So we have customers that have different OT networks from their IT networks and so when those cases were often implementing a DMZ layer, what does that look like with Ignition?
14:31
Travis: Yeah, so in these diagrams that I've been showing, the clients that we have are typically opened on the OT side of the fence which is usually there's an OT Network and then there's a business network or an IT network that's there and often they don't cross; There's firewalls that prevent those kind of things. And so, it does limit if, where I can actually open up the client, because of the network that's out there. So typically I can open the clients anywhere on the OT side, but then the business wants to get access to the data, licensing model for Ignition's unlimited so why not? The network gets in the way. And so in this particular case, it can be important to add Ignition on the DMZ side.
15:09
Travis: So if you look at this network here, this diagram, I've got DMZ where I can install an Ignition server with the visualization, so that can be Vision or Perspective, and we can connect that server... So it's an additional server with an additional license, unfortunately, but we can connect that server to the OT server so we can allow that. And using Ignition's Gateway Network, we can have all the same data. We can have the same application that we have on that side now available to the business so they can have lots of people out there getting access to it. And this is the most secure way of doing it. There are companies that will just simply open up firewalls or allow port forward, things like that, to get access to it and that's perfectly fine, as well. That does take advantage of Ignition's licensing model, but this allows it for the best security possible.
15:51
Lauren: So we've been focusing on visibility at the site level. What happens if I want to have visibility across an enterprise?
16:00
Travis: Yeah, it's a great question. So all the architecture diagrams we've shown so far have been... Have all those servers at that site, on-premise there. It would be able to handle that functionality locally. And it's true that I could put all that stuff at the corporate level and I can use Ignition's unlimited licensing model to talk to all devices across all different sites. It’s just not done in practice because, traditionally, that is over the WAN connection which could go down, right? We can't guarantee that connection from corporate to all the sites. So usually, we're talking about deploying a set of Ignition servers locally but as your question there is, we wanna get data visible centrally, as well. And so that's where, if we had a lot of different sites, we can bring it up to a corporate level for visibility of all that data, as well as management of all the Ignition systems we've got out there. It's easy to manage one Ignition installation but if you've got hundreds of them, you've got a lot of things to back up. You got a lot of things to consider. So when you look at a full enterprise solution, you wanna make that part really simple. You wanna have people in the corporate side to see data across all their locations and to make it easy for IT to manage the system.
17:06
Travis: So here, if you look at this diagram, I got two sites and I can have many, many other sites in there but that's got the Ignition systems whether it's the Edge products locally, whether it's the full Ignition server at that site or a scaled architecture at that site, whatever it may be... Each side could certainly be different than others, you have to look at the requirements of that site, but we can then connect those sites up to a central Ignition gateway, where we can look at the data. We can see all the live values of tags with our Gateway Network, we can see the history, we can pull history from those sites. We can easily mirror data, historical data, from those sites to a centralized database, as well, so we can get visibility there at the corporate level. We can see all the alarms that are happening across all the sites, a lot of visibility there. But more importantly, we have the management so we can use Ignition's enterprise administration module to centrally take backups of all those servers, to check the health and diagnostics of those servers, to be able to essentially manage a license, to remotely upgrade those servers and more. There are a lot of tasks that we can run with that, so it just makes it really easy to bring those up to a centralized system and to get that visibility and get that management going.
18:17
Shay: So what happens if I have a DMZ between a site and that corporate layer?
18:21
Travis: Yeah, so that's a good question. A lot of people, again, the DMZ,those layers, they want protections in there and so that the OT side would very much be that lower layer they'd wanna protect and the business side would be an IT side, higher layer and they don't talk to each other, although they can through a DMZ, right? But the business side cannot go to the OT side directly and the OT side can't go to the business side directly, but they can both talk to a middle layer. And so, that's a very common approach whether that's at the site level or whether it's between the site and corporate. It'd be really easy, in this particular case, to introduce Ignition in the DMZ, that really is gonna act as a proxy, between the site and the corporate location so that all of the services in management I was mentioning can just funnel through that proxy. So we can still get access to that and they get all the protections that are in place of a DMZ.
19:08
Lauren: Now, what if I want to leverage the cloud or even inject data into the cloud?
19:13
Travis: We can do that really at any layer, whether we do that at the site or that we do that at corporate. There are modules in Ignition that deal with getting data to the cloud. So we can utilize MQTT, for sure, we also have direct injectors to all the major cloud platforms, so whether it's Azure, or AWS, or IBM Cloud, or Google Cloud. Any of those, we can get that data, stream it up to the cloud and work with it. And so, that just put data up there and utilize their services. But keep in mind that we could also deploy Ignition to the cloud. We can have a hybrid approach, where we have our centralized corporate system and management in the cloud and we have all of the servers on site, locally there, so that we can guarantee that functionality right there at the site.
19:56
Lauren: As I go try and help customers architect systems, what sort of questions should I be asking?
20:01
Travis: A million questions. Unfortunately, we have to really probe the customer for these details. It really starts with first understanding their requirements. So what sorts of applications are they trying to build? Are they... That would determine what modules for Ignition that we need. And we also have to look at that network in a lot more detail, typically get involved with IT, we gotta understand what the layers look like. Are there DMZs that we have in here? Are there firewall considerations that IT wants, or security concerns that are there? And we have to know are there any points in that network where we could have the link cut? 'Cause that of course is one of the biggest considerations of architecting, is network failures.
20:40
Travis: If we have that, we've gotta put more robustness in, which means Edge products closer to PLCs and the redundancy, those kinda things in place. So we really have to understand that network. We also have to understand, not only the functions they want, but how big is this? What kinda devices are we talking to? What type of devices are they? How many tags are we dealing with in a day? How many clients, how many people wanna look at that data? What does it look like today and what's it gonna look like five years from now? Because I don't wanna put a system today that's gonna hinder me five years from now when I wanna scale that and make it bigger. So unfortunately, there's a lot of questions we have to look at, what's not only what they need now, but what they need in the future and sort of architect around that because there are considerations, especially in how we build projects for those kind of things. So unfortunately, there's a lot of questions, but you get used to them after a while and it gets a little easier as you go forward.
21:31
Lauren: Well, Travis, we're so glad we got to sit down with you today, thank you so much.
21:35
Travis: Thanks for having me.
21:36
Lauren: Any final takeaways for our viewers?
21:39
Travis: Yeah, so there's a lot of different ways we can architect systems, and it really comes down to having fundamental knowledge of Ignition, the modules, the features that are there, so once we have that foundation, we can then put an architecture in place that protects us from things, like network loss. So we really gotta look at the network and communication issues, and also the sheer size. How big is these systems gonna get? Are they gonna grow? Because those are two big things that will help us in how we architect that from the beginning, and do it correctly.
Series Order
15
The High Road
Joanna Cortez
Fri, 05/22/2020 - 11:18
Lauren and Shay are sitting down with Co-Director of Sales Engineering Kevin McClusky about how and why we take the high road when selling Ignition. Kevin explains why a big piece of our values is not comparing ourselves to the competition and not speaking poorly of competitors. Kevin shares how you take the high road when a customer is insisting on a comparison. We learn how to remain truthful and positive, stay in an educational mindset, direct the conversation, and focus on the solutions that Ignition provides
Video Transcript:
00:08
Lauren: Welcome back to our sales and marketing training series. I'm Lauren.
00:12
Shay: And I'm Shay. Today's video is on taking the high road.
00:14
Lauren: We're talking with co-director of sales engineering, Kevin McClusky, about how and why we take the high road in our sales strategy. Kevin, thanks for being here.
00:24
Kevin: Thank you for having me.
00:25
Shay: So, you're a musician. We got to hear a little bit of your music at ICC 2019. And I heard that you play three instruments. So, what are they?
00:35
Kevin: That's true, yeah, yeah. So, I play keys. I've actually played piano since I was five.
00:40
Shay: Oh, wow.
00:40
Kevin: And then, I play bass, and I play enough drums that I kind of consider myself a drummer. I sing, too.
00:47
Shay: Yeah, oh, wow.
00:47
Lauren: You're a full band.
00:49
Shay: Yeah, seriously, you could do it all by yourself.
00:51
Kevin: Well, that's all you need, so you don't need anybody else, then. Right?
00:55
Shay: Yeah, no, that's true. Very independent.
00:57
Kevin: No, no, obviously I put the Kevin and the Ignition 8 band together back at ICC. So, yeah, other people are important.
01:04
Shay: Kevin and the Ignition 8, Kevin and the Ignition 8?
01:06
Kevin: Well, depends on who you talk to.
01:09
Shay: Yeah, that's true.
01:09
Kevin: Somebody said, Kent and the Ignition, and there's...
01:11
Shay: I don't know where they got that idea from.
01:15
Kevin: Yeah, I know, yeah. It's ridiculous.
01:15
Lauren: It's so weird.
01:16
Lauren: Hot-button issue.
01:18
Shay: Here's the real question: So, you're really into music, it's a really big pastime of yours. So, how does that relate to your other big pastime, which is your career here? You're a co-director of sales engineering.
01:29
Kevin: Yeah, yeah, it's a really interesting question, because most people don't think of crossover between music and other fields. But in my position here, and really ever since I've been part of any sort of engineering team, it's always been a creative process. So, I started out in the integration business, I was working at a small integrator called Calmetrics, which Steve also owned, our founder/CEO.
01:55
Lauren: Yeah, sounds familiar.
01:56
Kevin: Right [chuckle]. And so, every integration job that I've ever done, or anybody I've ever helped, folks, helped projects with for those folks, they've always been creative endeavors. And so, some of that creativity in the music space, just sitting there, improvising, creating new things. I was really into jazz for quite a while. And so, you just sit there and you create whatever it is that you want to create. You're sitting down, you don't have a script for what you're doing. Engineering work is similar to that as well. So, you come in, you take a look at it, you say, ‘Oh, this would be great if we put this here. If we played a few notes here like this, it's gonna make the customer delighted,’ right? And so, there's the creativity and being able to run and kinda roll with the punches and adjust as things go along, I think really does cross over quite a bit between the two.
02:51
Lauren: Well, on to a slightly different subject, this video that we're doing today is on the high road, that's something we talk about a fair amount at Inductive Automation. And a big piece of our values around that is not comparing ourselves to the competition, and really not even talking about the competition. Why do we do that?
03:11
Kevin: There are many facets to the answer here, and I'll try to cover all of those over the next few minutes, as we're sitting here talking. One of those important things is that as a company, as a product, as folks who create Ignition for ourselves, we really strive to make a product that stands on its own. A product that is complete, the product that has a whole set of features that are going to be different from other folks. And so, we like to approach things as, ‘This is Ignition, this is all you really need to talk about. We don't really need to talk about other folks, we need to talk about what we're offering to folks.’
04:00
Shay: And what can be the downfall, then, of going that negative route and maybe focusing on competitors?
04:05
Kevin: Sure, sure, yeah, that's a good question. So, I like to think of it, liken it kind of to a political campaign, right? So, if you've got political ads that are out there, and yeah, every election cycle, right, you see all these smear campaigns, you see all these things that political rivals are talking negatively about each other. And even in this industry, we see it from a lot of companies, where they're saying, ‘Our software is better than X, our hardware is better than X. And this is why, and this is why, and this is why. They don't do these things, they don't do these things. We do 'em better.’
04:35
Kevin: I know that everybody probably has a visceral reaction when you think about these smear campaigns from political rivals, because it's never a positive thing, you don't walk away from those feeling like, ‘This is someone you want to engage with.’ You say, ‘Okay, maybe I'll vote for the other guy because this guy is so bad.’ We don't want that from our customers, right? We want them to vote for us, and to vote with their money or decide that Ignition is the right solution for them based on its own merit. And we've done a lot of work with the feature set, we've done a lot of work with the company to make our company a company that's as useful and as engaging and as supportive as possible for our customers.
05:18
Kevin: So, we really want folks to use the best solution, and 90% to 95% to 99% of the time, when folks are looking for a solution that's inside this space, Ignition is going to be that best solution, right? So, having an honest message about what we have and leading with the things that Ignition is really good at, and talking about those things means we don't need to go into that negative space.
05:44
Lauren: I know we'll be talking about the four pillars in other videos, but this feels like it really falls under that ethical pillar as well.
05:51
Kevin: Yeah, absolutely, absolutely. So, we've got the four pillars, we are going to have that inside the other videos. And for folks who are watching at home, right, go ahead and click over to those other videos, you'll see that. But one of those pillars, that's really important for our company, is that ethical pillar. And that ethical pillar says, ‘We're not going to compete with integrators, we're going to try to do things that are the right way with folks. We are going to respect the relationships that we have, we're going to try to do our business in as ethical a way as possible,’ and that's certainly part of it, right? You don't talk negatively about folks, all you do is you present what you have in as positive a way as it can honestly be presented, right? And then, they're going to make their own decision, they're going to self-select into what's best for them. We really want people to be successful in the long run, that's the overall goal. It's like, bring the things, show them. And we're really in the education business, so we wanna educate folks.
07:02
Lauren: What do you mean by that? What do you mean we're in the education business?
07:05
Kevin: We have a saying inside the sales engineering department, inside the sales department, inside the company overall as well, which is that the software sells itself. We're not here to convince folks to do something that they don't wanna do. We're here to show folks what Ignition does, how it does it, what features we've developed in the software, what our support structure is like, what our tech support looks like, what our Inductive University looks like; all these amazing things that we've created around Ignition. And let folks decide for themselves, is this what they need? Is this what they want? So, the idea is that education is going to bring folks around to help them to understand the feature set, understand how it lines up with their engineering needs. And then, they can decide, ‘Is this the best offer for me or not?’ And 90%, 95%, 99% of the time, they're going to go with Ignition, because we've put so many powerful features inside it, we have a price point that is amazing inside this industry. We have the unlimited licensing model. I could go on, right?
08:17
Shay: Yeah, I'd agree. So, with all of these things considered, then we're talking about taking the high road application-wise or putting these things into practice, how do you do that? How do you take the high road?
08:29
Kevin: Sure. So, I think the first thing for some folks, is to take a look at their own approach. So, I know that a number of folks who've come on with our organization, and with other organizations, too, might be in a mindset that, ‘You've gotta get out there and you've gotta sell, sell, sell.’ Right? That's not really the right mindset to be in. The right mindset to be in is, ‘Educate, educate, educate.’ Show people what the software can do, be honest about what it can do. If there are certain things that they're looking for that it doesn't do, be honest about that, as well. And talk about an overall solution, as Ignition is here, maybe there are some other pieces to it or maybe Ignition does everything.
09:11
Kevin: But talk about the solution space, talk about what Ignition is going to bring to the table. And if you're coming in from that positive mindset of, ‘I'm showing off something that is amazing, and I'm coming in with something…’ Because it's true, right? You don't have to fake that, right? If you're coming in from that perspective, you're not coming in from a perspective of, ‘I want to compare Ignition to this other thing. I wanna compare it to this. Ignition's better because this thing isn't as good as Ignition because Software X has this limitation and Ignition doesn't.’ You're instead, coming in from a perspective of, ‘Ignition has all these features and completely stands on its own. So, these are the things that are great about Ignition, this is the whole feature set.’ And then, customers can compare as much as they want to, to other things as well.
10:08
Kevin: It's also useful sometimes to talk about some of the big differentiating factors. So, if folks are asking about, ‘How does Ignition compare to Software X?’ You don't have to go into a negative space, right? But you can say, ‘Well, we're not experts on Software X,’ that's definitely true for Inductive Automation. We're not experts on all these other softwares, we can't really talk about exactly what they do. We've heard plenty of stories from integrators and other folks who've given us reports on certain things, but that doesn't make us experts. We just have some anecdotes here and there.
10:41
Kevin: So, it's not really our place to talk with authority about these other softwares, but we can say just in general terms, ‘Compared to the number of other things that are out there, these are the big differentiating factors with Ignition. We've got the unlimited licensing model, which is different than almost every other software out there. We're built on one platform, we have all these different modules that add to the functionality, we run as a single service, we're cross-platform, where we're running on Windows and Linux and Mac OS. We have full, true mobile-responsive options inside Ignition with the Perspective Module,’ and you could go on and on and on, right?
11:18
Shay: Literally.
11:20
Kevin: I think there's a specific video that we're doing on this as well, where you'll be interviewing Vannessa.
11:27
Lauren: Yes, exactly.
11:27
Shay: Yes, talking about differentiating factors, yeah.
11:28
Kevin: Yeah, yeah. So, that'll probably go through a whole slew of these, right? But you can focus on those and you don't have to compare it to another specific software product. We do have a comparison sheet that sometimes we'll send out that says, ‘Here's Ignition, here's all the boxes that Ignition checks.’ And then, you, if you're comparing it, you can go ahead and fill out the boxes for Software X. Fill in the name, up at the top, and fill in the boxes there, and come to your own conclusions about that. Of course, we're highlighting the things in Ignition that are the biggest differentiating factors in Ignition. Most of the things that are going to be common across softwares are certainly still worth mentioning on a phone call, but they're not gonna be highlighted in that document. And we often also talk about the Inductive Automation organization. So, that can be a really big differentiating factor for folks, too.
12:22
Kevin: We mentioned the four pillars earlier. We're a company that, in my experience, is extremely different from just about every other company out there. I started with the company about 10 years ago. And at the time, it was a very small group of folks. We've grown like crazy since then. But as the director and as someone who's grown with the company during that time, and is in charge, along with Travis Cox, the other co-director of sales engineering, is in charge of the sales engineering department, one of my jobs and one of the things that I've taken very seriously, is attempting to keep that small company feel as we get larger, and attempting to keep the agileness, attempting to keep the ability to work with customers and delight customers and have those one-on-one relationships. And that's one of our values inside the company, the delighting of customers, right?
13:18
Kevin: And so, as an organization, we have a lot of things that make us different than other folks. Sales engineering's talking directly to development on a regular basis, or (the) sales department is right next to other folks. We have direct lines from tech support to development, and we have a lot of interdepartmental communication that helps keep things smooth, helps folks get quick resolutions to different things, we have nightly builds for Ignition. There's just so much that makes us, as a company, a very different type of company to work with, versus a lot of the other folks that are out there. So, that's one that I like talking about as well, and also one that folks will find if they're comparing what their interactions might be with other companies, versus what ours is. We can't say exactly what their interactions with other companies might be, but we can tell them what we'll do, how we try to delight the customer, how we're very focused on trying to be responsive to what folks need, how a lot of our development is built on customer requests.
14:25
Lauren: Inevitably, when we're taking the high road, we most likely are going to eventually run into a customer who really wants to get into the nitty-gritty, and they say, ‘No, really?’ And they keep digging, and they want that comparison, and they want you to even speak poorly of a different company. How do you approach interactions like that?
14:44
Kevin: That's a really good question. So, I've been in the conversation with folks many times, where they say, ‘No, we're using Software X, we're using Software Y.’ What we really need to do is compare Ignition over to this software. ‘Can you give me a line-by-line comparison, can you tell me what is better about Ignition than these things?’ And they're really looking for information where we're going to provide this, and we're going to say, ‘Ignition's better in this way, in this way, in this way.’ And they most likely are going to get that list from a competitor, right? So, if they're talking to the competitor, we've seen many lists over the years that the competitor has said, ‘This is what Ignition does, and this is what we do, and this is why we're better than Ignition.’
15:29
Kevin: So, they're not gonna get that list from us, and the reason is everything that we just said. But to your question, ‘What is your response?’ One thing that's important is to have a response ready. So, have something prepared as you're talking to a customer, and they say, ‘Hey, we really want to compare you to Software X.’ One of the things that's really important for us in that response, is that we're not an expert when it comes to that other software. So, I mentioned it earlier, but we're not an expert. We don't know Software X. We may have some training, we may have some engineers who've gone through, we may even have some folks on our design team who've done some implementations inside this other product, but that still doesn't make us an expert on this other product.
16:16
Kevin: We know a few things, but there could be new versions that have been released, there could be additional things that have been added to the platform since we worked with it, they may have changed their architecture, their infrastructure, or we may just have an understanding of the software that's completely wrong. So, our engineers worked with this one section of it and not the whole software platform, and maybe there are certain things over here that do things in a different way. So, it goes along with taking the high road, but it's important that we're completely honest with folks, right? And so, when we talk about these things, we might respond in a way that says, ‘We're not an expert with the software, we can't claim to be an expert with the software. If we claimed that, we would be doing a disservice to you, because we would be giving you a comparison chart that you don't really know is true,’ right. And we're not going to be dishonest in the way that we express ourselves in the response that we give to them.
17:14
Kevin: So, ‘We can't give you that, but what we can give you, is this comparison chart that I mentioned earlier. And we can give you information about the differentiating factors of what Ignition, how it generally compares to other softwares in this space, the things that generally are going to be winners on the Ignition side.’ And I mentioned some of those earlier, and you can watch the other interview that you're doing around the differentiating factors specifically, right? But we'll go through that, and we'll have a response there. And I think it's really important that when someone is answering that question, that that response is something that is easy to pull out, easy to talk about and easy to express to folks.
18:04
Kevin: And I'll just give you an example of why this is really important, is because, I mentioned earlier that a number of our competitors do this comparison, side-to-side. Every single one that we've ever seen is wrong. So, we have never seen one that is factually accurate about what Ignition can do. Some folks say, ‘It can't do this, it can't do this, it can't do this. We do these things better.’ And then, when those comparisons come back to us, it's very easy for us to go through and say, ‘This is wrong, this is wrong, this is inaccurate. This company is giving you bad information about this, because Ignition does do this, it does it this way, these are the modules that you use, this is how you do it.’ And immediately, the other company loses credibility because they've expressed something that is just wrong. And part of our ethical pillar, and part of our expression of our software, and part of our core values is being honest about all these things, and being able to talk about what Ignition does, what Ignition doesn't do, and letting folks make that decision. So, if we started giving out comparison charts, then we would be in the same boat as some of the folks who ... we want to stay differentiated, right? We wanna stay honest, we wanna stay ethical, as a company, and it's really important that we maintain those lines.
19:23
Lauren: So, Kevin, as a company, Inductive Automation has taken the high road since the beginning, and you've been there for much of that, you've seen how that's panned out for us. How would you say that that's panned out for us as a company?
19:37
Kevin: Yeah, yeah, good question. So, we haven't always, full disclosure, been perfect about it, right? And so, there's some coaching that goes into the process when we bring new sales folks on board and new sales engineers. But overall, it's been really valuable for us as a company, and it's been a really cool thing to see. Because we don't have to trick people into things, we don't have to give people comparisons to other softwares that we think is probably right, but we're not 100% sure, we don't have to go the route of going into negative smear campaigns. We're able to be in the education business. Talk to folks about Ignition, talk to folks about Inductive Automation, talk about what an amazing thing it is that we're doing here and what an amazing company that we have and let 'em choose for themselves.
20:32
Kevin: And we've seen that rewarded over and over and over again, as folks start to understand where we're coming from, what we offer, who we are, how we're going to support them going into the future, and the organization that's really behind them as a customer when they purchase Ignition. So, it's been a really cool thing to see, it's been a really cool thing to be part of, and I'm looking forward to continuing being part of this far into the future.
21:00
Lauren: Well, excellent. So are we [chuckle].
21:01
Shay: Yeah, I was gonna say the same thing. Thanks so much for being here today.
21:04
Kevin: Absolutely. Yeah, thanks for having me.
21:08
Lauren: Thank you.
Hero
Integrator Program Level
Thumbnail
Wistia ID
pvki45eemk
Learning Series
Series Order
13
Sales Training
3. Understanding Customer Pain Points
Lauren and Shay invite VP of Technology Colby Clegg to talk about solving industrial pain points. Colby shares what those pain points are, how Inductive Automation is solving them, why they are critical to our foundation, and ways to use them as selling points for Ignition. Colby stresses the importance of getting information into people’s hands quickly and shares ways to overcome challenges to getting buy-in. Colby explains how the pain points will evolve as systems scale and technology grows, and where IIoT and Industry 4.0 fit into this. Learn how Ignition is unlocking innovation without limitations, saving users time, money, and energy.
Locked
You must be Registered to access this content.
See how to become Registered
Sales Training
1. What Makes Us Different
Lauren and Shay are talking with Chief Strategy Officer Don Pearson about the industry at large and Inductive Automation's role in revolutionizing the industrial space. Don shares his journey into the world of automation and realizing Steve’s vision for integration. Don discusses the evolution of this competitive landscape, addressing the barriers to entry over the last 15 years. We learn what separates Inductive Automation from the competition, the ways in which we’re empowering our customers and making knowledge transfer successful, and where we go from here.
Locked