In this week’s Pipeliners Podcast episode, Russel Treat welcomes back SCADA and cybersecurity expert William Gage to discuss how to maximize your Operations Technology (OT) capabilities in pipeline systems.

William shares his insight on the difference between IT and OT, the role of cybersecurity in OT systems, the importance of risk management, and more valuable topics. The conversation also focuses on how to bridge the gap in communication between the IT and OT sides to create a common understanding.

Tightly Integrated & Loosely Coupled Operations Technology: Show Notes, Links, and Insider Terms

• William Gage is a supervisor for SCADA infrastructure and Cybersecurity with Enterprise Products. Connect with Will on LinkedIn.
• OT (Operations Technology or Operational Technology) refers to the hardware and software systems that perform critical functions — such as monitoring and controlling equipment and processes — to support pipeline operations.
• IT/OT convergence is the integration of IT (Information Technology) systems with OT systems used to monitor events, processes, and devices and make adjustments in enterprise and industrial operations.
• SCADA (Supervisory Control and Data Acquisition) is a system of software and technology that allows pipeliners to control processes locally or at remote location. SCADA breaks down into two key functions: supervisory control and data acquisition. Included is managing the field, communication, and control room technology components that send and receive valuable data, allowing users to respond to the data.
• Edge Communications is a method of building out the architecture for structured communication from edge devices in the field to a host server using connectivity to transmit the data.
  • MQTT (Message Queuing Telemetry Transport) is a publish-subscribe protocol that allows data to move quickly and securely through the system and does not bog down the system with unnecessary requests.
    • MQTT is credited with being invented by Dr. Andy Stanford-Clark of IBM and Arlen Nipper of Arcom. Arcom was bought by EuroTech in 2006.
  • Modbus is an older protocol that enables communication among many devices connected to the same network. The drawback is delays in the communication, oftentimes creating timestamp discrepancies.
  • Poll Response only sends data if requested by the host. This creates limitations because you may need to wait up to 15 minutes for the full data package to be received.
  • Report by Exception sends data to the host when there is a change to the data.
• Leak detection systems include external and internal methods .
  • External methods are based on observing external factors within the pipeline to see if any product is released outside the line.
  • Internal methods are based on measuring parameters of the hydraulics of the pipeline such as flow rate, pressure, density, or temperature. The information is placed in a computational algorithm to determines whether there is a leak.
• Computer Operating Systems (OS) is a system that manages hardware and software resources in the OS and allows for computer programs to run in the system.
  • DOS (Disk Operating System) was a popular operating system introduced in the early 1980s that ran off a computer’s hard drive.
    • MS-DOS was Microsoft’s version of DOS that was initially used on IBM computers.
  • Windows became popularized as the most well-known and broadly-used operating system in the 1990s. Windows started as a graphical operating system shell for MS-DOS in the 1980s.
  • Unix is a popular type of multi-tasking, multi-user operating systems that were developed in the 1970s. Unix is used on many platforms because of its common programming language.
  • VMS (Virtual Memory System) was released in 1977 to run micro-computers known as the VAX-11. It was succeeded by a new OS called OpenVMS.
• HMI (Human Machine Interface) is the user interface that connects an operator to the controller in pipeline operations. High-performance HMI is the next level of taking available data and presenting it as information that is helpful to the controller to understand present and future activity in the pipeline.
• DCS (Distributed Control Systems) are typically installed at facilities and are distinct from the SCADA system, which monitors and controls a geographically disperse system such as a pipeline.
  • OPC is a software interface that allows Windows programs to communicate with field devices that are integral to pipeline operations.
• NIC (Network Interface Card) is a circuit board installed in a computer for the purpose of creating connectivity to a network.
• RTUs (Remote Telemetry Units) are electronic devices placed in the field. RTUs enable remote automation by communicating data back to a facility and taking specific action after receiving input from the facility.
• PLCs (Programmable Logic Controllers) are field devices used in the pipeline industry to automate control in the field.
• EFMs (Electronic Flow Meters) measure the amount of substance flowing in a pipeline and performs other calculations that are communicated back to the system.

Tightly Integrated & Loosely Coupled Operations Technology: Episode Transcript

Announcer: The Pipeliners Podcast, where professionals, Bubba geeks, and industry insiders share their knowledge and experience about technology, projects, and pipeline operations. Now your host, Russel Treat.

Russel Treat:  Welcome to the Pipeliners Podcast, episode 46.

Thanks for listening to the Pipeliners Podcast. We appreciate you taking the time. To show that appreciation, we are giving away a customized YETI tumbler to one listener each episode. This week, our winner Carin Meyer with MarkWest, our first two-time YETI winner. Congratulations, Carin. Your YETI is on its way.

This week, William Gage returns to the Pipeliners Podcast. We’re going to talk about loosely coupled, tightly integrated operations technology. You might not know what that is, but let’s find out.

Will, welcome back to the Pipeliners Podcast.

William Gage:  Hey, Russel. It’s so great to be back.

Russel:  I asked you on — I had reached out to you just to catch up. We hadn’t talked for a while. We go into this conversation about tightly integrated and loosely coupled OT.

I think the way to start for the listeners is to talk about some basics to build a context for that conversation. Then, we’ll talk about integrated and coupled and what that means.

The first thing is, what is OT?

William:  That’s a great question. There are a few of you that are listening going, “Oh, yeah. I know what that is.” Some people are going, “What? Is that like IT?”

It basically is. Information technology versus operation technology — or operational technology. Operational technology includes many things that you wouldn’t even think about. Health care devices. You go to the hospital. It seems like everything’s connected now.

Of course, the line of business that we’re in — pipeline controls, down well production pieces, all of that’s very integrated into a connected environment where that data comes back to a system. That data’s then parsed out for decision making, whether it’s even decision making from an environmental perspective. There’s lots and lots of data.

For the company that I work with, which will remain somewhat nameless unless you go to my LinkedIn page and see where I’m at, we have hundreds of thousands of data points coming in from our fields into just three systems. That’s not including any of the other systems out in the field. I’d like to talk about it just a little bit, the IT model versus the OT model. IT is all about making sure that your data’s secure. Availability is the third piece of the triangle.

If you flip that, OT is all about let’s make sure that it’s available. We’re using SCADA systems, which are OT systems, to monitor and control pipeline systems, and hazardous materials, and sometimes just water. Still, you want to make sure that those systems are available.

In between that is, is your data good? I want to make sure that my information is accurate. Accuracy is the next piece.

Third is, is it secure? For a lot of people, they’re like, “Oh, my goodness. That’s almost terrible. That’s sacrilege. You should be secure first.”

When security trumps the availability and we can suffer loss of life or environmental impact, that’s not going to cut it. You can’t necessarily treat IT as OT.

They do share very similar platforms and some of the concepts and ideals work interchangeably, but you have to take the time and understand each of them because each of them are very important, in their own way implemented. Sometimes, you cannot take and implement one into another.

Russel:  We just had a very similar conversation in last week’s episode with Clint Bodungen as we were talking about the convergence of IT and OT.

William:  Yeah, Clint’s a good guy.

Russel:  Oh, yeah. We had a bit of an “aha” in that episode. You’re actually framing it a little differently…one of the disconnects is that…we were talking a lot about risk management and how IT and OT coming together affects risk management and people’s perspective. IT people, they’re concerned mostly about keeping the data secure, where OT people are most concerned about keeping the system up and reliable.

Those two things are in conflict. From a risk context, it’s, “I don’t want to lose data. I don’t want the system corrupted,” versus on the OT side it’s, “I don’t want to create an environmental issue or a safety issue.”

It’s similar technologies but with different focuses in terms of how they’re used. What you’re doing in this conversation is you’re framing that a little bit differently around availability versus reliability.

William:  Yes.

Russel:  Those two things are both required, but it really matters what you focus on first.

William:  Sure.

Russel:  What would you say is the state-of-the-art approach to OT? Let me tell you a little bit about why I’m asking the question. That is simply this, that SCADA systems, most of the SCADA technologies, and for that matter the operation technologies, the DCS technologies, and so forth. Most of that stuff is 25, 30 years old in terms of when it was originally invented.

We’re using those in modern systems with IP networks and all that. Maybe you could talk a little bit about that reality and what that means regarding the current state in the industry around OT.

William:  Goodness.

Russel:  Did I throw you a bit of a grenade right there?

William:  You did. It’s funny. I was going to start off by saying I am 36-years-old. I have had the experience, so far, within the 16, 17 years I’ve been doing this, working with things that are older than me and learned a lot from a lot of great people. I definitely want to say that. You know who you are.

From a state-of-the-art perspective, I think it’s funny how…I’m going to say that a lot of larger companies, we’re just doing the same thing over and over again. We’re using what works and continuing forward.

That is not necessarily great from a cost saving perspective. Sometimes being able to get data in to create additional business capabilities. I’d like to separate it. I think that our innovators in the culture are smaller companies. They have the ability and the agility to take and apply new types of science to this industry.

There’s a protocol that’s been out for quite some time, MQTT. I know the folks over at Arcom. Now, they’re Alexis or something [EuroTech bought Arcom in 2006]. They’ve been using the technology for quite some time to report by exception. Report by exception is great in theory. It technically saves quite a bit of bandwidth. Even with the revolution of…

We’re almost at, what is this, 5G. 5G signals actually create enough attenuation within a particular device to create electricity. You don’t even have to have battery packs in some cases. It’s fantastic. I think that’s a neat little topic, too. That’s a whole another podcast.

What I like to say is your smaller companies are doing more because they have the agility. They can take and say, “You know what? Let’s do this. We don’t have a big system. We’re not archaic. We don’t have to jump through so many hoops that Congress looks like a great place to go spend time at.”

I also like to see that sometimes it’s the folks at the top. I like to say the top five. In Houston, that’s an easy one. You’ve got Kinder, and TransCanada, and Enterprise, and Enbridge, and folks. They typically do the same thing. Their back-ends are very similar. They’re using Modbus.

Russel:  It’s an interesting observation, I think, Will, because the big guys…Just in general, pipeliners are risk-averse. From an operations perspective, we’re risk-averse. I always say, for good reason, innovation means risk. Risk in a small organization, from an innovation standpoint, is really quite different than a larger organization.

These big guys, they have issues around having every, particularly when they’re looking at leak detection, and SCADA, and operating risk. They need to be doing things very consistently across their entire system.

When they make a change, they have to isolate the experiment so that it can be done in a controlled way, where in a smaller company, you can just do it. That affects things.

Coming back to this conversation about state of the art, I think you characterized it well. Basically, what the nature of the technology is is we have surrounded these old systems with new technology. What I mean by that is things like SCADA systems, a lot of those SCADA platforms, that technology, what it’s doing and its base function is 30 years old. It’s been over time wrapped in newer stuff, but the base engine’s still old and that has consequences, right?

William:  Absolutely.

Russel:  Most SCADA systems that are on the market today were built around poll response. They weren’t built around report by exception and that’s a big material difference.

William:  Yes, in the way that it’s implemented. It’s one of those things as you’re looking from a compliance perspective, too. I know that there’s heartburn when we talk about we’re not a report by exception, polling organization. We do like to poll.

We like to poll extremely frequent just because from our perspective, we’re controlling it. We’re not having to worry about deadbands and, oh, it changed this much. Even with that, even with the technologies that we have, a great example is leak detection.

Russel, there’s a project going on that I know of that they’re using SCADA data. This leak detection system is not in the SCADA system.

Some truists out there are like, oh, it has to be part of that SCADA system because we’ve got to ring alarms in. I’m actually a SCADA purist saying, no, we need it to be separate. I think that’s where the state-of-the-art piece is coming in.

We spent a lot of time in the past 10 years, and even a little bit earlier on, from maybe 2001 to 2016. We spent in the industry more time integrating things into a single platform, then we did trying to actually innovate the platforms themselves.

Russel:  Let’s have a conversation about tightly coupled, or tightly integrated, excuse me. It goes right to that conversation. I started in the business, Will, probably a little bit before you were born, just to date myself. At that time, the effort and the risk associated with moving data between systems was extremely high.

Connectivity wasn’t that reliable. You had multiple machine operating systems. You had DOS. You had Windows. You had Unix. You had VMS.

Within each of those systems, you had multiple different applications for data, and so forth, moving data around was really, really complicated. It was actually less risky and less expensive to do it all inside of the platform.

That mindset or that approach comes out of where we have been given the systems we’ve been using. What’s happened is that the ability to connect systems has gotten quite inexpensive by comparison, and it’s become much less risky and much more reliable. The need to do everything in a single system is diminished.

William:  Greatly. I think it’s interesting. I like how you said it was the folks — and I’ve thought this for quite some time — the folks that have been in industry and who were older with making decisions during the time when it was very difficult to move data from this system to the next system, they were making decisions.

The folks underneath them kept that in their mind the entire time as we worked through into the 2000s where everything was still being integrated into each other within the single platform.

Until recently, we’ve realized we have monstrous SCADA systems and control systems. We are putting in hundreds of thousands — if not in some cases, in the electrical industry specifically — and I’ve seen these, three million point SCADA systems.

Russel:  Yeah, those exist in our business, too.

William:  Especially if you’ve got quite a few wells. I know some fields and some producers that could. I’ve seen some that are almost a million. I’ve never seen it, but I know they exist, and I know you have.

I think it’s entirely interesting that we want to tax systems the way… computing is so inexpensive now. Computing power, the virtualization, and using virtualization within a control system can be done and can be done well.

At the same time, not everything needs to be, and you need to really pick and choose how you’re going to do it. The mentality of course is the integration within your systems needs to be thought out.

Russel:  I was sitting here and I was listening to you talk, but what I’m thinking about is where we’re coming from is not really a place of integration but a place of isolation.

William:  That’s a good point.

Russel:  What I mean by that is integration infers I’m connecting things together. Really, what we were doing is we would take one system and it would all be done in one system. Basically, a single code base, and all the works done in that single code base versus a distributed code base.

If I have a polling engine, a leak detection system, a real-time database, a historian, an HMI, and a decision support system, the approach has been do all of that in one piece of software, one vendor’s toolset. Where we’re moving to is, no, I don’t need to do that.

I think I’ve talked about this on some other episodes, but there’s a large project underway at ExxonMobil. ExxonMobil has a huge number of DCS systems that are old and need to be upgraded. The nature of a DCS is it’s kind of an all-or-none type thing.

I need to have the new one up and running before I pulled the old one out. I can’t, well, I’m going to do this piece first and this piece second and this piece third — it just doesn’t work. That creates a resistance to change.

William:  Yes, it does.

Russel:  Again, for good reason because that’s high risk. I’ve got production throughput issues if I’ve got to make that kind of change. It’s just a big deal. They’re leading a project to flatten the typical IT architecture and make it more modular and that gets to this idea of integrated versus isolated.

A DCS, and everything you do in a DCS is fairly isolated. I could connect to it using OPC connectors and such, but as a general rule, everything in the DCS is isolated. It lives, exists, is maintained in the DCS, it’s isolated.

Really, what we’re saying the future is is for that to be decomposed, but yet, you don’t want to lose the integration. The benefit is because this thing is isolated it’s reliable. It’s secure. It’s well understood. Also, it’s very difficult to change and to modernize.

If I could break that apart and move from isolated to tightly integrated, I retain those benefits, but I also get some additional benefits.

William:  That’s well said. We know most DCSs live in plants. Typically, there is an elevated risk association with working in those environments. Everybody thinks that, “No, it’s got to be this way. It’s got to be in one, single spot so I can work on that.”

I think, over the last 15 years, and I would say even, really, the last five years, we’ve proven that’s not necessarily the case. As the workforce continues to actually diminish…what I mean by that is we don’t have as many people out in the field. At one time, when I started, there were probably twice as many people in the field as there were when you started. Everything was done by people. Now, we use people very carefully. We give them very oriented tasks. They’re specialized to do very special things. We have stretched things thin.

Russel:  Right. We used to use SCADA systems for safety only and to support operations. We now use them to run the business. Where 30 years ago, most people’s backup plan, if I lost the SCADA system, is, “I’ll just run it manually,” a lot of people don’t even have the staff to do that if they wanted to.

William:  Exactly. You’ve got to have a good plan and say, “I can’t do everything so I’m going to only do these.”

Russel:  Exactly.

William:  We test that out every year. It is interesting because I see the…again, it’s all about what kind of data we’re bringing in and how we’re utilizing it. That comes back to the integration piece.

Russel:  This whole conversation is not unlike what’s happened in the IT world. I was talking to somebody last night about this, about the nature of the software business. When I first started work, I started working in technology. It was in the ’80s.

I was building a computer on my kitchen table — solder pieces on the board, and then put the boards together in the backplane, turn the power on, and hope I didn’t see little smoke trails. Then, start writing code to program the thing. You had to do it all.

At that time, everything existed in a single piece of hardware and software. It was one, little, tightly coupled system. Mainframes were just bigger versions of the same thing.

What has happened, and at that time, one person could know all of the domains with some level of expertise related to doing the business. That would be absolutely impossible in today’s IT world. It’s impossible to know with some level of expertise all the domains. You just can’t get there. It’s too big a subject matter.

It would be like saying, “I could be any kind of engineer. I could be a civil engineer or a chemical engineer. It doesn’t matter.”

What has happened is as these systems have grown in capability, we’ve gotten different skill disciplines around networking, and firewalls, and data security, and application support. Now, there’s all these different disciplines to run the stuff, much less build it.

It’s gotten a lot more complex. I wouldn’t want the painter to do my HVAC work at the house. It’s the same kind of thing. If I were just building a wood cabin back in the 1800s…

William:  It wouldn’t matter.

Russel:  Yeah, it doesn’t matter.

What’s going on is we’re moving that direction in OT.

William:  You framed it real well — where my next piece of it was going. That is, even though we are now taking…we’ve stretched things thin in the field, and we’re highly specialized in the back office with all of this integration, and we’re making these systems talk to one another. They’re sharing data. They’re helping us make business decisions, even.

How do you stay on top of the compliance piece around it? That’s always fun. I’m over compliance where I work, as well, not just in the infrastructure piece of SCADA. How do we maintain? For these huge systems, how do we keep things going for all the various pieces and parts?

On top of that, how do you make sure that everything’s working? In a single, isolated cone, everything works. You don’t have to worry about trying to get data transported because it’s all right there. But then, how do we monitor it? How do we make sure we’re getting good data? It’s not stale. It’s good.

That’s an area where we’ve been thinking outside of where we have been and going, “Okay, what little tool are we going to…sniff the wire to make sure we’re getting data?” I know some people are like, “Whoa, whoa. You’re doing what in the SCADA system?” Absolutely.

Russel:  That is state of the art. We’ve been doing it for years on the IT side. It’s part of what you do.

This is leading to this conversation about loosely coupled. What is loosely coupled? I’m going to take a stab at this, just to kick us off.

William:  Please.

Russel:  Loosely coupled means that…Again, I’m going to make a hardware analogy. I think those are easier to visualize. In my day, if you wanted to connect to computers, you had to figure out how to wire them and you had to write software on both ends. That’s where I started in the world.

Nowadays, if I want to connect two computers, I’ve got to have a NIC card on the computer. That NIC card’s got to be connected to a switch. The switch has got to go through a firewall. The firewall’s got to go through a router. I’ve got to move it over a public network and do the same thing on the opposite side.

It’s like this thing that used to be, “I’ve just got to wire connect it.” Now, there’s these various parts. That system, once it’s implemented, is tightly integrated, but it’s loosely coupled because any one of those parts can be removed and used for an entirely different purpose.

That’s kind of an analogy. I think what we’re talking about, though, as it related to OT is, what does it mean to loosely couple an instrument? Instruments, in our current world, are by and large tightly coupled. That’s changing to some degree in the plant space, but in the SCADA world the instruments are tightly coupled to the field device, the RTU, or the PLC, or whatever I’ve got out in the field actually controlling the process.

Then, from there, I’m more loosely coupled. Then, I get back up to the SCADA system. Depending on the technologies I choose, but for the most part, my SCADA real-time engine, my leak detection, my historian. All those are very tightly coupled. To loosely couple those means, I might have three different products from three different vendors.

That means I need to start focusing on, how do I make connecting these things up highly reliable and highly configurable without that being a huge level of work or risk? That’s my frame for tightly integrated and loosely coupled. Does that match up with the way you would describe it?

William:  I think that was well said. I have another piece of it that I like to look at. It’s similar. I like the hardware. I like how you said the network pieces and how you got all these different disparate pieces.

I like to also, then, add, “In that switch, or in that router now, I’ve added another system that’s connected off. Now, I can transport data back and forth to it, as well.”

My original purpose was, “I’m sending data here.” Now that I’m integrating more, I can now expand. Even better, SCADA system replacement. I know you know this. For those of you that are listening that have done this, I am extremely sorry. SCADA upgrades are horrible, horrible, horrible things because we’ve made it so difficult on ourselves.

As we begin to loosely couple these systems, for instance, we have a polling farm. That polling farm takes care of all communications to the field. It is comprised of the systems that go get the data for us. The next piece of that layer is the SCADA system, bringing data in for real-time operations, analysis, calculations.

Specifically to just the simple and basic control structure of a system, valve control, set points, things of that nature. Those are integrated. They can be integrated in various technological ways. There’s OPC, and MTGT, and various things.

I like the next piece of it where when you loosely couple these things, when it comes time to replace that SCADA system, I don’t have to figure out a way to go and, “Oh, I need a dual poll system, or triple poll system. I’ve got to have this much bandwidth,” and all these things.

No, no, no. I already have my polling farm. I’m going to go drop in my SCADA system. My SCADA system is now in there. I can duel everything. I don’t have to worry about anything. I can go and put all the pieces together.

Russel:  Making things modular, I have a lot more flexibility about how I expand the infrastructure, how I modernize the infrastructure. I can do that in a systematic way. I’m with you.

I think that’s where we’re going. I actually have a little different thought about what that’s going to look like. I think that polling, as it lives today, is going to move all the way out to the edge, meaning, it’s going to live where the… right now, we go buy an EFM or a PLC. We configure that thing and we set out in the field. I think we’re going to have computers that we do that with. It will be software that do what these PLC and EFM devices…I don’t think we’re very far away from that. I think that’s within five years.

William:  Funny you say that, Russel. We’ve actually been doing that for about 10 years in some areas, where we are…

Russel:  That’s my point. It’s not new. It’s the cultural change that’s the bigger challenge. The beauty of that is if all my custom polling, where I’m talking to instruments. I’m dealing with protocols and all that. If all that’s put all the way out to the edge and it’s on a computer. That computer is secure.

All of a sudden, what I can do with my communications infrastructures and how I can provide the ability to people to do their job, it opens up a whole bunch of possibilities that are going to lead to efficiencies and improvements.

I want to transition because we’ve been talking about isolated versus integrated and why tightly integrated is important. We’ve been talking about loosely coupled and how that’s important. Now, what I want to do is I want to talk about why do I care?

Because this all sounds kind of neat and geeky, which you know, you and I like neat and geeky. But as a businessperson, as a pipeline operator, as an executive, why would I care about all this?

William:  I think that’s a billion dollar question. If I could win the lottery, then that’d be a whole other story. To answer the question, I think, and the sense is why does it matter if I’ve taken the opportunity to really understand how our OT environments are set up, why is it important to invest the time in creating additional business worth?

My thing is you’ve got brick and mortar companies. You’ve got Barnes & Noble, right, and other ones. Barnes & Noble is looking for a buyer. For a long time, they were the big powerhouse in the bookstore market, and so were a few other ones.

Then all of the sudden, you’ve got these online companies, and their storefront is all completely digital, and the only thing they have is warehouse. Then they ship everything out, and voila, we have Amazon of today.

What’s the difference? The difference is Amazon has taken the opportunity to do the exact same thing that we’ve been talking about. They are very loosely coupled but still tightly integrated into their full house and suite.

They don’t go and do something unless it means something. They’re very intentional about how they’re using technology. A lot of areas, where, we just do the same thing over and over, the brick and mortar idea, there’s a place and time for that, but there’s also a place for innovation. There’s also an opportunity to create opportunity.

Russel:  I get where you’re going. I think I’d frame it this way.

For pipeline operators, we’re late adopters of technology, in general. There’s a couple of really good reasons. We’ve already talked about the risk reason and the operating reason, but the other reason is the nature of our systems. We’re highly geographically-distributed and highly-reliant upon reliable communications in order to be able to do our job well.

However, that being said, the reality is somebody’s going to figure this out as a pipeline operator, and they’re going to get this deployed. When they do, they’re going to have a competitive advantage over other operators.

They’re going to be able to lower their operating risk, because of the kind of oversight they have of their systems, and they’re going to be able to improve their decision-making, because of their ability to gather data and frame it into information for decision-making. They’re going to be able to do that at a price point and with a speed beyond their competitors, and that’s going to be a leg up.

I will tell you it’s probably going to be some small operator that figures this out first.

William:  Oh, yes. Just like I said, that’s…

Russel:  Then they’ll get bought by the big operator…

William:  Then what happens, right? [laughs] That’s my favorite part. It’s the never ending story of this is the song that never ends.

Russel:  That’s right. That’s the nature of our society and capitalism is the better mousetrap will win the day, typically, not always, but typically. There’s a lot that goes into that.

William:  I definitely don’t want to bash anybody buying a small company, and not taking their technology. Actually, most of the time, that’s exactly the opposite. Once the right people get involved and they see something, they’re very intent in saying, “Oh my. Why aren’t we doing this?” Then, that pushes forward.

Russel:  That’s right.

William:  I’ve seen that. I really have, and I’ve seen where… [laughs]

Russel:  That’s also the nature of our business. We do like to learn from others. When we see somebody doing something, and it’s working, and it’s being done, and all that, we will adopt it, but we’re also highly skeptical.

William:  Extremely.

Russel:  Again, for good reason. That’s a key part of all this.

I think, Will, that we’re kind of getting to the end of the conversation, here. We probably ought to wrap this up. I’m going to try, and again, I like to do the three key takeaways.

This conversation is kind of strategic, some of the takeaways here may not have been directly in the conversation, but we could take that liberty, and then if you want to, you can crush my presumptions.

[laughter] It’s because we’re just speculating.

I think there are several key takeaways. IT/OT convergence is here. It’s coming. It’s going to radically change the way we think about and work with our operational systems, normally thought of as SCADA, but it’s going to look a lot different going forward. That’s the first key takeaway.

The second key takeaway is there is a huge opportunity for businesses to innovate their processes and improve their operations by changing up how they think about their operating technology.

There’s a third key takeaway, which we didn’t really talk about, and that is that’s going to require a rethink about how we staff our organizations and build the management systems for managing, maintaining, and optimizing this new kind of infrastructure. This is not just a technology change. It’s also going to be a change in the way we think about staffing the support organization.

William:  I like those three takeaways. I think that was well said, Russel.

Russel:  Oh, man. You need to crush me on something.

William:  Well…

Russel:  Here it comes. Now, you can crush me. Go ahead.

William:  The one thing is on IT convergence, I’m going to say this. For all IT people and SCADA people, I’ve got two pieces of this. Russel, I think we both feel the same way in some instances.

If there are children in the room, cover their ears, but SCADA people don’t be jackwagons.

Russel:  [laughs] We’ll link that up in show notes. We’ll give you a definition of jackwagon. [laughs]

William:  There you go, don’t be a jackwagon.

Russel:  [laughs]

William:  The IT people only know what they know. Not to their fault, they’re really good at what they do. 99 percent of the time, there’s some very quality people out there.

I have the pleasure of working with some great people in my organization there. They do know their things. You need to help them very carefully understand where you’re coming from, and how you all can work for a common goal.

Now, to the IT side…

Russel:  To that point, Clint and I really kind of unpacked that conflict and the why behind it. It’s all about perspective. It’s all about the come from.

William:  It is.

Russel:  Both of those come-froms are valid. They’re just very different, given the realities of the risk and what you’re trying to accomplish.

William: Now, on the IT side, please stop saying to the SCADA people, “Well, we do it in the IT side.” That’s like saying, “Well, I painted my grandma’s car yellow.” That means nothing to me. I don’t care.

You absolutely have knowledge. We can learn from it, and we can help each other, just don’t be so presumptuous that you just come off as something you shouldn’t.

Russel:  I’m going to flip that, because there’s a likewise you need to tell the SCADA people, “You don’t have all the answers.”

William:  Oh, yeah. Don’t be a jackwagon, right? [laughs]

Russel:  Yeah, don’t be a jackwagon. “And there are risks that the IT people understand that you do not, and they need to be addressed.”

William:  And vice versa, exactly.

Russel:  That’s really what it boils down to. We have this lack of understanding, and a bit of a chasm between those two roles in the organization. They’re both valid, and they’re both needed and necessary, but we don’t typically do a very good job of arbitrating that natural, and what can be a very beneficial conflict.

William:  Honestly, if you’re a decision-maker, and you are within the controls organization, engineering operations, or IT, and you’re having to work with IT, or IT, you’re having to work with SCADA group, or whatever it might be, get together.

Have an opportunity, where, if you know that you have some challenges, get the groups together and have an opportunity that’s not going to boil into anything contentious. Just try to get to understand each other. Have an opportunity to sit down and talk about roadmapping with each other.

I know Clint. He’s the same guy that when we have had the conversations in the past, we try to see each other’s work — the things you know from each other’s point of view. Don’t force anything, just listen.

Russel:  What we do in one of our operating companies, Gas Certification Institute, we do a Fundamentals of SCADA training. The real purpose of that training is to help the various roles, the people.

Ultimately at SCADA, there’s a lot of people that interact and deal with the SCADA system. The real of that training is to create a common language, a common understanding, and a basis for communications.

That’s really the goal of that fundamentals training. We get into a lot of more technical details in that, but what we often do in this domain is we use a common language to talk about different things.

That can be problematic. If you get people on a common understanding of “Well, my role is to look at these things, and everybody knows that I’m coming from that place,” number one. Number two, these words mean these things in this conversation.

Those two things, that sounds really straightforward. That is hard to do, really hard to do.

William:  It is.

Russel:  Particularly in a larger organization or an organization where you’ve got a fair amount of turnover, for whatever reason. Moving people around, people retiring, or whatever, it’s hard to anchor that but it’s really critical.

Will, we need to wrap this up. We went a little long, but I always enjoy talking to you. I certainly think the listeners enjoy this as well.

We are a little bit in the red zone on the geekometer. We’ll try to in the post-production here, when we put together the web page and the show notes, we’ll try to take all the buzzwords and get them all down, those that are interested can go and decode some of the things we were talking about.

With that, I’d like to say thank you and look forward to having you back in the future.

William:  Absolutely, it was a pleasure as always. Thank you.

Russel:  I hope you enjoyed this week’s episode of the Pipeliners Podcast and our conversation with Will Gage.

Just a reminder, before you go, you should register to win our customized Pipeliners Podcast YETI tumbler. Simply visit pipelinepodcastnetwork.com/win to enter yourself in the drawing.

If you would like to support this podcast, you can do that by leaving us a review on Apple Podcast, Google Play, or any smart device podcast app. You can find instructions at PipelinersPodcast.com.

If you have ideas, questions, or topics you’d be interested in, please let us know on the Contact Us page at PipelinersPodcast.com or reach out to me directly on LinkedIn.

Thanks for listening. I’ll talk to you next week.

Transcription by CastingWords