In this episode of the Pipeliners Podcast, host Russel Treat welcomes Jeff Allen, Global Pipeline Practice Lead for Esri and a board member of PODS, to discuss the latest developments in the Pipeline Open Data Standard (PODS).
Jeff shares insights into his role at Esri, the evolution of geospatial technology in the pipeline industry, and his extensive experience in surveying and geomatic engineering. The conversation delves into the historical context of PODS, its transition from a purely relational database structure to a spatial data model, and the recent release of PODS 7.03.
Listen to the episode now to learn more about how PODS serves as a critical standard for managing pipeline assets, incorporating spatial intelligence, and addressing regulatory changes.
PODS 7.03 Update Show Notes, Links, and Insider Terms:
- Jeff Allen is the Global Pipeline Practice Lead at ESRI and a board member of PODS. Connect with Jeff on LinkedIn.
- ESRI: A provider of GIS and mapping software, technology, and services. Esri is the global market leader in geographic information system (GIS) software, location intelligence, and mapping.
- PODS: Pipeline Open Data Standard, a nonprofit organization comprising pipeline operators and consultants working to formulate a standard for managing pipeline assets.
- GIS: Geographic Information System, a system designed to capture, store, manipulate, analyze, manage, and present spatial or geographic data.
- ILI: In-line inspection, a method for assessing the integrity of pipelines from the inside using tools that travel through the pipeline.
- Linear Referencing: A method of spatial referencing that uses a linear measurement system, often used in mapping linear features such as roads, pipelines, or rivers.
- SCADA: Supervisory Control and Data Acquisition, a control system architecture that uses computers, networked data communications, and graphical user interfaces for high-level process supervisory management.
- AI: Artificial Intelligence, the simulation of human intelligence processes by machines, especially computer systems.
- MTR: Material Test Report, a document that certifies a material’s compliance with applicable industrial standards.
- HCA: High Consequence Areas, locations along a pipeline where a potential failure could result in serious harm to people or the environment.
- NPMS: National Pipeline Mapping System, a system used to collect and maintain information about pipelines in the United States.
- Digital Twins: Digital representations of physical assets, processes, or systems, including real-time data and predictive analytics.
- Data Governance: The overall management of the availability, usability, integrity, and security of data used in an enterprise.
- Spatial Data: Data that identifies the geographic location of features and boundaries on Earth, providing context to traditional relational data.
- Risk Modeling: The process of quantifying the potential impact of risk and uncertainty in an investment decision, with a focus on standardizing risk registers for various pipeline operations.
PODS 7.03 Update Full Episode Transcript:
Russel Treat: Welcome to the “Pipeliners Podcast,” “Episode 312,” sponsored by EnerSys Corporation, providers of POEMS, the Pipeline Operations Excellence Management System. Compliance and operations software for the pipeline control center to address control room management, SCADA, and audit readiness. Find out more about POEMS at EnerSysCorp.com.
Announcer: The Pipeliners Podcast, where professionals, bubba geeks, and industry insiders share their knowledge and experience about technology, projects, and pipeline operations. And now your host, Russel Treat.
Russel: Thanks for listening to the Pipeliners Podcast. I appreciate you taking the time. To show that appreciation, we are giving away a customized YETI tumbler to one listener every episode. This week, our winner is Aaron Donat with Holly Energy Partners. To learn how you can win this signature prize, stick around to the end of the episode.
This week we speak to Jeff Allen, Global Pipeline Practice Lead for Esri, and a PODS board member about what’s new at PODS. Jeff, welcome to the Pipeliners Podcast.
Jeff Allen: Thank you very much. Happy to be here.
Russel: As I often do, I like to ask the guests to tell us a little bit about themselves. If you don’t mind, tell us a little bit about who you are, what you do, and your involvement with PODS.
Jeff: Sounds good. My name is Jeff Allen. I’m the Global Pipeline Practice Lead at Esri. What that means is I get to run around the country, run around the globe, and help customers figure out how to use geospatial technology with their pipeline asset information systems. Cool job. I’m a surveying engineer, geomatic engineer by training, and have been doing this for about 25 years.
Russel: A geomatic engineer?
Jeff: Yes, sir.
Russel: I don’t know that I’ve ever heard that term before. What is a geomatic engineer?
Jeff: Basically, a bunch of folks split out of the civil engineering group and decided, “Hey, we really need to focus on GIS, GPS, and land surveying.” There are a number of departments and a number of programs around the country now that just focus on geospatial engineering and what that means as a technology and a science.
Russel: Fascinating. I did surveying when I was in my engineering degree, and I’ll date myself because I did it all on a theodolite with a stick.
Jeff: I was right there with you.
Russel: Shooting stadia. I learned it the old-school way.
Jeff: The first GPS we had was in the back of a pickup truck with three twelve-volt car batteries, all put in series.
Now what I can do on my phone, I used to have to travel around in a pickup truck with.
Russel: No, that’s funny. We’ve come a long way, baby, I’ll tell you. What is your involvement with PODS? What’s your role with PODS?
Jeff: PODS has been around for 25 years now. I’ve been around, unfortunately, most of that time, if I want to date myself as well. Right now, I serve on the board of directors, and I serve on a number of the technical committees as well to help put my two cents in where it’s needed and help the organization along in its journey and its mission.
Russel: For the listeners that might not know, what is PODS?
Jeff: PODS is not those things that you order up when you have to move your house. That’s a different kind of PODS.
PODS is a Pipeline Open Data Standard. If I wanted to summarize it in a nutshell, it’s a nonprofit organization made up by a bunch of pipeline operators and a bunch of pipeline vendors that come together to figure out what is the best way to formulate a standard to manage your pipeline assets.
It doesn’t have to be GIS, but what all goes into a data model when we’re setting up these systems.
Instead of having everybody go off and build their own and have a thousand different flavors out there, what if we all got together and agreed on that and created a standard around it and all coalescing our solutions around it? What would that look like for the industry? That’s what we set out to do with PODS.
Russel: I’ve been knowing about PODS probably since shortly after its inception. When PODS was first founded was about the time that relational databases were starting to proliferate throughout the oil and gas industry.
Jeff: 100 percent.
Russel: One of the things about those databases is all of a sudden I could store a whole lot more data, but everybody was doing something different because they were all custom-built.
The data models themselves were all different, so if there was any need to look…Anytime you tried to do a merger acquisition, even within larger companies trying to look at multiple assets, there was a lot of disparity at that time and just how the data was structured that caused a lot of difficulty and a lot of costs and everything else.
PODS was originally formed as a way to say, “This is the way that we as an industry agree you should build a relational database to store pipeline data.”
Jeff: 100 percent right. As we started building out these data models, you can imagine a bunch of smart individuals sitting around the country with blank pieces of paper, going, “What should go in this thing? O.D., wall thickness, grade, manufacturer.”
What if you all get together and agree on what should go in this thing? That’s where this all started. It was just a bunch of smart individuals all doing the same thing.
Russel: What tables we put it in and what names we call it and all that kind of stuff.
Jeff: 100 percent.
Russel: At that time too, there was no GIS. Pipeline data sets were linear data sets. They were all based on mileposts. They weren’t even two-dimensional data, certainly not three-dimensional data.
Jeff: If you want to think back to those early days, what were we trying to do? We were trying to automate the mapping to some degree.
We were trying to take this data that was inaccessible, to a large extent, in CAD, and even paper drawings to a lesser extent, and we were trying to put that into some type of database so that we could turn around and automate the mapping back out to the field engineers.
Remember AM/FM? Automated mapping and facilities management. That was a whole term of the day. That’s where this all started from…
Russel: You’re shaking cobwebs out for me now, Jeff.
Jeff: [laughs] Exactly.
Russel: That’s the genesis of PODS. What kind of things is PODS more recently working on? How did that migration from that original just relational data structure to now pipeline data and GIS data are synonymous these days?
Jeff: Even back in the early days, it was just relational, but that didn’t last very long. Most of the solutions that were built around PODS, you would have a relational PODS database. Sitting adjacent to it, very close by, would be some type of graphics representation of what was in that thing.
The industry built solutions and software that would read PODS and put those spatial objects into a database that we could then visualize on a map. Those were the early days. It worked, but it was a little bit disconnected. You could have a situation where maybe something was updated in PODS and didn’t make it onto the map or vice versa.
Two things happened as the solutions went forward in their maturity. One is that companies realized, “If we’ve got two different databases here, one spatial and one relational, can’t we have it all in one spatial database? Can we just get rid of some of these complexities?”
More and more companies, starting around PODS 5, started looking at “Can we build a spatial version of PODS?” That’s been ongoing for a couple of years. If nobody can agree on the data models or what goes into them or what flavor or what version, almost everybody can agree it needs to be spatial.
The spatial location intelligence component of this is really what’s driving a lot of these new requirements coming out from the organization. That’s the slow progression PODS has been taking. It is, yes, refining the data model. Continue to meet regulatory requirements. Continue to meet business requirements, but also then utilizing spatial more in those processes as well.
Russel: The other thing that’s happening too is that, even in the field now, because of what we can do on smart devices and on the Web and such, that the whole work is spatial. It’s changing things. It’s changing the way we think about things. I expect to show up at a site. My device knows where I’m at, so it should know what equipment is there with me.
Jeff: Exactly. Having a digital data collection device in the field is something that surveyors have had for 30 years. This is where a lot of this came from, is traditional surveyors showing up on pipeline projects, going, “Why are you guys still writing all this in a paper notebook?”
Jeff: “We do this digitally. Let me show you how it’s done.” Data capture started to become digital as well, which fed those digital mapping systems in the back. Now we see the progression of these mobile devices to operations.
I can then send that data back out to the people who actually have hands-on collecting data during the operations phase, which then feeds back to the integrity management program? We start seeing that big loop happen.
The other thing we talk about here at Esri is this idea of consumerization of GIS. When I first started doing this and showed up with my survey data collector, I was just a fast-talking kid from Boston. These guys in the field are like, “Heck, no. We’ll just stick with our paper notebooks.”
That generational change has happened. Now people in the organization are saying, “I can find Starbucks on my phone. Why can’t I find the nearest mainline valve?” They expect this technology instead of having it pushed upon them. That’s the big sea change around this digitalization or digital transformation that these organizations are going through.
Russel: Again, I think you’re right on it, Jeff. It’s so true. I remember coming out of college. My first year of engineering school was the first year slide rule was not required…
Russel: …in Introduction to Engineering. I got out of college and I went to work in the military, I’m like, “I’ve built a personal computer. I can do all this math on this personal computer. I don’t need to do this on a slide rule.” People thought I was nuts. Nobody would do it any other way than on a computer now.
Anyways, I know that PODS just put out a new release. Let’s talk a little bit about what current work is going on with PODS. What is PODS focusing on currently in terms of improving and expanding its data model?
Jeff: If you look at the timeline, back at version 4.02, which was a very popular version of PODS, that was strictly relational. As we moved into 5 and 6, we started adding spatial. Then, at some point, we realized, “We’ve done this a little bit piecemeal. We need a blank piece of paper because this thing’s been around for 15 years. Technology has changed. Thinking has changed.”
I often say that a lot of the people that work on PODS, it’s like being in the Harvard chess club. We all get together in a conference room. We argue about things for a couple hours. Then you go back to what you argued about 10 years later. You go, “Oh, man. I would have done that completely different now.” [laughs]
Russel: We have a term about that in our company, old Russel and new Russel.
Jeff: Exactly. New Russel would be…
Russel: Old Russel did that, now new Russel is looking at it wondering what the heck old Russel was thinking.
Jeff: That was PODS 7. PODS 7.0 was our opportunity to pump the brakes for a moment and say, “How are we going to structure this going forward, knowing now all the lessons we’ve learned over the past previous versions?”
One of the key ideas or premises of PODS 7 was that we would create modules. To get all the ILI vendors to agree on what should go into a set of ILI tables is like pushing a string. We said, “Let’s create a module. If we cannot agree, maybe we’ll be two. [laughs] One for this type of ILI data and one for this, but it will bolt on to PODS 7.”
PODS 7.0 was the core. 7.01 improved that core. Now we’ve been building modules. In a sense, we did get enough folks to agree on an ILI specification. PODS 7.01 now added some new ILI tables. 7.02 expanded on some of the regulatory compliance tables and filling that out. 7.03 added the idea of connected networks and pipes.
You mentioned this idea of measures. Everything was measurement based in these original systems. The total length of steel in the ground is still very, very important, for regulatory, for matching up ILI data. Just because you have coordinates doesn’t eliminate the need to know how much steel is in the ground.
We have modeling techniques that allow us to do that. That’s called linear referencing. Linear referencing isn’t something pipeline people made up. Civil engineers have been using pipeline referencing in roads and highways and railroads for hundreds of years.
Russel: That dates back to the 1800s in railroads. Before that was Roman roads.
Jeff: PODS was built around that idea of linear referencing. That was its fundamental building block. The problem with linear referencing, it’s really hard to connect pipes together and form a network of pipes. If you really don’t have linear reference pipes, like inside a facility or upstream in gathering, it’s really difficult to put those pipes into a linear referencing system.
What 7.03 did, with a technology called the utility network, is formed a foundation of connected pipes. Then you could put those linear assets on top of them. You get the best of both worlds in those two modeling techniques. That’s 7.03. That’s what we’ve released out just recently.
Russel: It’s been probably three years or so since I took a look at the PODS model. One of the things that came up for me as I was looking at that model is there’s a lot of other kinds of information that probably is more suited to relational data structures than to geospatial data structures, like all the tags in my SCADA system.
However, there’s still a need to do some kind of georeferencing. Is PODS now looking at how do we bolt on other kinds of data?
Jeff: Yeah. One of the things that we start to talk about are information models, versus the larger data model. One of the things that PODS has done is look to Esri and said, “You guys have a core set of geospatial features for managing linear data. Let’s put that inside of PODS and then build around it.”
From an Esri perspective, we use the same technology on railroads, roads and highways, pipelines. I tell people, “You could map bugs and bunnies along the pipeline if you wanted to.” We don’t really care what the business attributes are. That’s the operator.
What PODS brings to the table is what surrounds that core. It could be SCADA. It could be CP information. It could be ILI information. It could just be the basic characteristics of the steel, in some cases.
Every operator chooses at which level you want to put that data into PODS and spatialize it and where that data lives in conjunction with all the other information systems that make up the larger companies’ infrastructure. SAP, Maximo, all these systems have information that really ties to PODS. We want to figure out how to interoperate between these systems as well.
That’s really what we’re here for, is to try to think through those ideas, talk to operators, figure out what the needs are, and then come up with a template or a starting point where people can download, be part of that organization, gain that knowledge, and then build upon it for their needs.
Russel: That’s really interesting. Esri or Esri’s tools are basically a platform. They’re not an application. What PODS does is say, “This is the kind of data that you need to store.”
Then there are still other folks, like us, that need to build the tools to make it become an application. It’s really a stack. There’s the platform. There’s the data model. There’s the application layer which has all the intelligence in it. Then there’s the presentation layer.
Esri has lots of cool stuff for presentation layer, particularly as it relates to mapping, but you still have to build those other parts to actually be able to do a job.
Jeff: I tell people all the time, if you boil the ocean, you’re down to points, lines, and polygons. Then we build up from there. Lines become pipelines. Points become valves. [laughs] All these things have a spatial location and a connectivity, but…
Russel: That is such a surveyor’s answer, man. I have never heard that before. It’s true, but that’s very much a surveyor’s perspective.
Jeff: [laughs] If you talk to a surveyor and a GIS guy, and you say, “I want to model this.” One of the first questions they’re going to ask you, “Does that occur at a single location, or is it a span location, or is it a box?”
We try to figure out what type of object this is, and then we start asking you all the detailed questions about the business attributes that get tied to that feature, that make it come alive to all the things we’re going to do with it.
Russel: Oh, my God. That conversation right there, Jeff, is spinning my head out. I think, for the first time, I have a way to conceptually understand what is the difference between a relational database and a geospatial database.
Jeff: The one thing I tell people all the time is location can be your ultimate foreign key. If you can tell me where two things are at, I can tell you a whole bunch more about them than I ever could if they were just sitting in relational data model without location. I can tell you if that valve is within HCA. I can tell you how far it is from the next valve. Is it in a floodplain?
All these things that if it was sitting alone in a relational database, without having to go research those things, I’d never be able to answer that question. Location starts to bind things together in a way that we never could in just a pure relational model.
Russel: No, it makes perfect sense to me. It also makes sense to me that when you’re thinking about a geospatial data model, the whole points, lines, and polygons makes a whole lot of sense because you need to know what it is I’m trying to put into the data structure.
Jeff: 100 percent.
Russel: Am I putting a valve in a point? Am I putting a pipeline in a line? Or am I putting in a facility a polygon? You can scale that idea up or down.
Jeff: This will blow your mind. Now, we’ve taken that idea of points and lines and given them business intelligence in this connected network. When I place that point valve, I wire it to the pipes on both sides.
You can imagine a check valve, depending on how I connect it to the points on both sides, now it gives that check valve intelligence of flow. Same with a pump or a compressor or regulator. I now start to understand the low pressure, high pressure situation and flow along those pipelines.
That’s another thing that we’ve added to the PODS model, is this idea of business rules. Yes, two pipes, two polylines can connect, but if one’s 12 inch and one’s 14 inch, I better have a reducer in the middle because 12 inch and 14 inch don’t naturally connect.
That’s this idea of adding more business intelligence to the PODS model as we go forward because, ultimately, what we’re trying to do is get the best quality data that we’re basing all our decisions on. If that data is suspect, then all the decisions that come out of it are suspect. This idea of the single source of truth is the thing that everybody’s striving for with these systems.
Russel: The other thing too that you’re pointing out in this conversation is we’re to a point where the technology will allow us to identify every single unique feature that makes up the pipeline.
Jeff: That transitions us into digital twins. When we start thinking about where our next step is, companies are building these digital twins of their pipeline that does have every little bit and piece. Digital twin is three things. It’s the physical assets, it’s the real-time data, and it’s the ability to do forward predictions using that bot.
Russel: It’s the algorithm to model the process.
Jeff: Exactly. Then, I can do what-if scenarios and say, “If I have a storm event in the northwest and I know it’s going to be cold, and I can look at all my historical weather and all my historical flow information, I can predict what the demand on that steel is going to be in the next week, and maybe I can line pack ahead of that weather event and save on putting pressure on those assets.”
That’s where we’re heading with those more advanced digital twins as we move forward.
Russel: There’s a lot of people doing those kind of things now. As I think about this, and I think about where we’re coming from and where we’re headed, there’s a whole lot of pipe in the ground that we don’t have full information about because at the time we built it, we didn’t even collect all that information.
Jeff: 100 percent. Or if we did, we stripped it off of these paper maps, we put it into the database. We folded up the paper maps. We sent them off to Iron Mountain, never to be seen from again. Now we start thinking about this idea of the witness of installation documentation. Where is that signed chart? Where is that MTR from the mill? Where is that…?
Russel: All that stuff should have been scanned and dropped into the database.
Jeff: We want to be able to click on the GIS, look at a piece of pipe. If it says it’s this wall thickness or this material type, how did that data get in there? How do I prove that that is the data?
Russel: It’s traceable and verifiable.
Jeff: …complete, but it’s traceable and verifiable. Companies are struggling with that because these assets are buried. It’s not easy to go back in time and…
Russel: Even when you’re doing a new construction project, being able to know, here’s the purchase order for this string of pipe. Then here’s the inspection record for that string of pipe. This string of pipe landed in this particular place. When I go and pull a dig, I would go, “Here’s the string of pipe. There’s something on the pipe that identifies it as that particular string.”
It gets complex, really, really fast. I guess the point I’m trying to make is having a standard way to gather the data, it’s not everything that needs to occur, but it’s a very big step in the right direction.
Jeff: I just had this conversation the other day. I told the customer, because they were trying to figure out this as built-in process, and how to get the new construction into their PODS database the most efficient way.
I said, “You need a specification for that because surveyors like to collect points. GIS systems and pipeline systems love linear, begin and end of things.” [laughs] You’re given a bankers box of documentation and a whole bunch of surveying points, and then you’re left to make sense of it to get it into a pipeline information system.
That transition from those two worlds is very important because often, in a pipeline operating company, those two worlds are very separate. One is project management and project execution. The other one is operations and GIS. The companies that get that are the ones that have that dialed in, that transition from…
Russel: Again, I couldn’t agree with you more. I would language it a little differently and say that every work process has its own inherent data structure and data presentation. Two work processes working on the same thing will have different data presentation and different data structures.
The trick and this is what PODS does, I believe is to figure out what’s the underlying enterprise-level data structure that all this other stuff can be built on.
Jeff: Correct. Some of the projects that we’ve seen be not very successful is when somebody just picks up their PODS data model and hands it off to the surveyor and says, “Here, fill this in for me.” Surveyors aren’t PODS experts. They’re not even linear referencing experts.
You got to get that survey standards nailed down, what you want to collect, how you want it collected, and then build some processes to QA that data as it flows in. Ultimately, what we’re after, as soon as that pipeline is flowing product, it should be in the GIS and be in operations’ hands, day of.
There should be nobody out there operating a pipeline that they don’t have the same information on the one they’ve been operating for 10 years.
The other part of that is we don’t want to have to go back and touch this data again 10 years from now. We want to get it the way we want it, buttoned up and in the GIS day one. PODS gives us that guideline for what to collect. Now we just have to figure out what the best way to capture it is.
Russel: Again, I think that’s true. Where do you think PODS is headed in the future? What are some of the things that need to be added to…What are the holes and gaps that you’re seeing in terms of what’s next?
Jeff: Clearly, the regulatory environment is changing. We envision that there’ll be a set of regulations from well tip to meter tip and everything in between, at some point. This idea that this is regulated and this is unregulated will be a distant memory at some point.
As those regulatory requirements continue to expand, as NPMS continues to ask for more data, PODS needs to be there to say, “Yeah, we already have it,” or, “We need to add it to meet these regulatory requirements.” That is frontmost one of our things to do.
As these companies continue to go on their digital transformation journey, there are more and more stakeholders being added to this mix of things. This idea of modules that we could add on for leak detection and mitigation or we can add on for right of way or things like that, those are all opportunities to expand.
We also want to start thinking of PODS in a slightly different way. It’s not just an organization you sign up for and download the database. Those are the old days. This is an organization you sign up for to be part of a knowledge base around pipeline data management, and asset management, and GIS, and all these things.
The collective knowledge is what you’re signing up for when you become a PODS member. We’ve been working on changing how people view that. It’s not just a download anymore. It’s an organization to be part of. If you’ve got an idea and you see a gap, bring it to the table, we’ll bring you 10 experts to help you fill that gap.
Russel: Interesting. I can certainly see some opportunities, particularly in risk modeling. The industry’s been doing risk modeling for a long time, but there’s beginning to be a conversation about the need for standardizing the risk registers for various kinds of operations. That’s an area where PODS could add some real value.
There’s not even consensus across the industry about, “Here are the elements that absolutely, 100 percent of the time, should be in the risk register for this kind of operation or this kind of pipeline or whatever.” That is something that we as an industry are going to have to figure out.
Jeff: There’s two important parts there. One is the risk and integrity folks are the largest consumers of this data in the organization, typically. When they sat down and these regulations for risk and HCA and class and all the things that make up that, when these things first came out, some of them you can’t do without GIS.
You actually need a geographic information system to do some of these calculations. These groups that started to form around these regulatory and risk turned to the GIS that was sitting there, creating alignment sheets for people, and said, “This is the data we need.” They were the first to jump on board, start consuming, and then pushing that data model along.
Now what we’re seeing is this idea of AI and machine learning. If I have big enough data sets, what if I could create you an algorithm that could run across all the history of your operation and say, “We predict this is where the next failure might be along your pipeline”?
If I had that algorithm, I wouldn’t be here on the podcast. I’d be on my beach on Malibu somewhere. That’s where we’re starting to look at new technologies…
Russel: You’d be on the podcast from your beach house in Malibu.
Jeff: We’re trying to think of this newer technology and how that fits into the puzzle. It all starts with good data. This old adage, “Garbage in, garbage out,” still holds today.
Russel: I’ve recently been involved in several projects where they’re focusing on control room of the future. They’re looking at SCADA. They’re looking at digital twins. They’re looking at what is their control room doing currently, what might the role of the control room be in a future state.
What is 100 percent of the time consistently the current challenge to move into the control room of the future is I’ve got to get good data governance in place. I’m talking about data governance around, what assets do I have and what automation do I have, and how am I defining that automation? All of that. There’s not good tools out there for doing all that, currently.
Jeff: Companies are spending a fortune to fix old data, but they need to keep that data in as good a shape as it is when we went back…
Russel: It needs care and feeding. That’s the thing about governance. It’s not about “I write a standard, and then it fixes everything.” No. I’ve got to create capabilities and competencies and tools and systems to ensure that that data is maintained correctly. Every time I go out and touch the pipe, I’ve got to update the data.
Jeff, this has been awesome. Every time, I have a conversation with the PODS guys, I’m like, “I need to go spend more time on this.”
Russel: Then they make the offer, and I’m like, “Yeah, but I don’t have that time.” Again, I’m intrigued. I certainly am. I like what you guys are doing. I think you’re adding a lot of value for the industry.
This is firing off a whole bunch of thoughts in my head about what we ought to be doing and where we ought to be focusing on. Probably, having this conversation will trigger those thoughts all again in another year or two. [laughs]
Jeff: It was interesting. As I was getting ready for this morning, I was thinking, “Why did I get involved in PODS? Why am I still involved in PODS?” It comes down to a couple of things for me. This is just a really fun, smart group of individuals.
When you surround yourself with like minded people who are very intelligent and have the same goals, it doesn’t feel like volunteer work. It feels like you’re part of something bigger. That, for me, is what keeps me involved in the PODS organization. Yeah, I love GIS. I love technology. I’ve built a career around it, but if you don’t have that camaraderie…
Russel: It’s about relationships and adding value, being part of a mission.
Jeff: If you’re trying to figure out, “Why should I join this PODS organization?” that networking and that relationship building and expanding your own base is as important as downloading the model, on some levels.
I encourage people to come check us out or just reach out to any one of the board members and see where the opportunities are. A lot of people come into the organization just on a technical committee on their area of expertise. Then they get swept up in the whole thing. Next thing you know, they’re helping us out in multiple ways.
Russel: PODS is starting to get to the point where they’re going to become much more relevant. They’ve been relevant for integrity management folks for a long time, but I think they’re going to start becoming relevant for a lot of other folks as well.
When I was looking at the model, the last time I looked at it, I was asking questions about “Where do you plug the SCADA data into this?” Everybody cocked their head sideways a little bit…
Russel: …and like, “Huh, hadn’t thought about that.” Again, it goes to your point of figuring out what are the business needs and how do you plug those into the overall model.
Before we wrap, I do want to come back and ask you a question. You used the word information versus data earlier in our conversation. Can you define for me what you mean when you say information in the context of a data model?
Jeff: Yeah. The term I use is an information model. I use that to differentiate when I’m talking about the capabilities around Esri and pipeline data modeling. Esri, in itself, as a technology, is data modeled agnostic. You can slide our feature classes into your own data model if you don’t use PODS or some other version. It will still work.
One of the things I try to separate for my customers is the idea that there’s a core set of Esri feature classes and columns that you need. Beyond that, it’s PODS or it’s whatever you need to run your business that we enable that technology on.
I try to focus them on the core first, core linear referencing, core pipeline data management, and then build that onion. It’s the physical assets. Next, it’s the pipe, it’s the casing, it’s the coding. Then maybe it’s operational data, then maybe it’s SCADA, then maybe it’s right of way or integrity management. We keep continuing to build around this core.
The core is what keeps it all linked together so that when I ask questions on the different datasets, it’s got some foundation that then understands how they all interact with each other.
Russel: The information model is more about what the data is and how the data relates, versus the data model is more, “This is how you deploy the information model in this tool set.”
Jeff: Yeah, the PODS data model is everything. It’s all the fields for all the things. In Esri’s world, we’re going to give you a core set of features or core data model for linear referencing. Bugs bunnies, piping coding, casing valves, we don’t care.
This is what you need as a minimum to link it all together and that’s the DNA that we’ve injected in the PODS 7. If you download PODS 7, and you’re an Esri shop, those feature classes, that core information model is already in there. You’re not having to retrofit this to work with your GIS. In fact, the GIS features are already there for you. That’s the magic in the soup.
Russel: Got it. That’s no small thing, by the way. I started working in data modeling tools back in the ’80s. We’ve come a very, very, very long ways about what we think about how we ought to be building databases in order for them to capture huge amounts of data and yet run quickly and be easily searched and all that kind of stuff.
The core idea about, what is it that you need to know? What’s the best way to put it together? That’s still the starting point, and that is independent of platform and approach. I guess that’s the point you’re making.
Jeff: Yeah, and going back to how PODS works. People think, “Oh, this was some grand strategy.” This was literally a friend of mine who was very involved with PODS, Pete Veenstra, and I, in a whiteboard in Redlands going, “We should really put this stuff in PODS.”
Jeff: Taking that idea back to the technical committee, working its way through its process, and pitching this to the rest of the team. The rest of the operators going, “You’re going to put that stuff inside of PODS and it’s just going to work with my Esri stuff? Yeah, we want that.”
A lot of these ideas and grand scheme, they evolve over time. They’re just a bunch of smart people standing around a whiteboard going, “How do we do this better, smarter, faster?”
Russel: The value of the PODS model is if you follow that, you’re getting the benefit of 25 years of history and hundreds of people and their best thinking getting distilled into this is the best way to put this data together.
Jeff: Still, one of the most popular things that PODS produces is the poster that basically is in everybody’s cube that does anything with PODS and GIS. Some stakeholder from the organization comes in and goes, “Where do I put this?” We all spin around our chair, run our finger, and go, “It goes right there.” I have a spot for it.”
Russel: That’s crazy. You spin around, you go, “We don’t have a place for this.”
Jeff: Yeah. That could be true as well, but it is that PODS poster that brings people together, and it’s a finger on the map that says, “Here’s where you live in our ecosystems.” You go, “Ah, cool.” [laughs] “I need this, this, and this.” “No problem. We’ll add that for you.”
Russel: Awesome. Look, there’s so much here. It’s a lot to chew on. My takeaway from the conversation is it’s probably time for me to take a deeper dive into PODS.
Russel: I want to have to put that on my strategic plan for next year.
Jeff: We have a lot of great events, usually around the Esri events as well, so you get a two-for-one. We’ll have the PODS spring form that will be directly adjacent to the Esri Energy Resources Show that’s in Houston, so two days you get back to back. Then, we do a fall event as well in…
Russel: Do I get free admission if I bring my microphone?
Jeff: Absolutely. Press is welcome. I’ll get you a press pass to both.
Russel: I’m going to let Monique know that you made that commitment.
Jeff: I’ll get you a press pass to both. I’m on the board. I’ll guarantee it for you. [laughs]
Russel: Awesome. Good deal. Jeff, I appreciate. This has been fun.
Jeff: Russel, it’s been great fun. Thanks for having us on. Thanks for talking about PODS, and GIS, and all this fun stuff. It’s been a real treat.
Russel: I hope you enjoyed this week’s episode of the Pipeliners Podcast and our conversation with Jeff. Just a reminder before you go. You should register to win our customized Pipeliners Podcast YETI tumbler. Simply visit PipelinePodcastNetwork.com/Win and enter yourself in the drawing.
If you have ideas, questions, or topics you’d be interested in hearing about, please let me know, either on the “Contact Us” page at PipelinePodcastNetwork.com, or reach out to me on LinkedIn. Thanks for listening. I’ll talk to you next week.
Transcription by CastingWords