<img src="https://secure.leadforensics.com/78049.png" style="display:none;">
Skip to content

Based in the Houston, Texas region, HTRI is a world leader in heat exchange systems research, design, training, and testing software. For 55 years, HTRI has collected and interpreted data, developed thermal process design and simulation software, delivered customized services and testing software, and trained their customers in its use. Chris Walker shares the HTRI transition to the SAP HANA in-memory database and the benefits this journey delivered to HTRI and their customers.

Subscribe to us on iTunes 


Full Transcript

Carl: Welcome to The Connected Enterprise Podcast, where our guests share with us how they stay connected. I'm your host, Carl Lewis, from Vision33, and my guest today is Chris Walker from HTRI. Chris, welcome to the podcast. I know you well, but for our guests today, share a bit about yourself, HTRI, and your role there.

Chris: Hey, Carl, thanks so much for having me. I'm the Director of IT and Business Applications at HTRI. We're an engineering firm in Texas, and we specialize in research for heat exchangers. We service any company that needs a heat exchanger within the oil and gas manufacturing industries and have customers worldwide. We're an international company. My team is responsible for making sure our research is running and the software and technology are being executed properly.

Carl: The big topic about this podcast is connectivity. There are so many buzzwords in the industry today with artificial intelligence and machine learning and robotics and the internet of things and in-memory databases and stuff like that. In what areas has HTRI invested over the last couple of years?

Chris: We’ve looked at a lot of those buzzwords. We have six rigs running processing fluids, analyzing how they react to certain conditions and environments, and we looked at IoT. We would love to have done IoT on our rigs, but we found it wasn't the best for us right now. We educated ourselves, however, and we learned how it works because you're right, it’s all about buzzwords. People look at them and say, "Hey, I have to have that. That's what everybody's doing." But it's important to evaluate if those technologies are appropriate for your application.

So, we looked at IoT, and it wasn’t the best thing for us. However, you mentioned other things that applied to us. First, in-memory database. We run HANA, and we run a lot of data through HANA. We're a data company; we perform research all the time and we need to analyze that data quickly. We constantly want to run different models. We want to understand the world better so we can help our customers predict certain situations better, and in-memory databases do that. We use HANA to have high-performance analytics and the things that come with an in-memory database.

Carl: That's an interesting project, and I know a little bit about your history with that, but what I don't know is how that project got started. Where did the impetus come from? If you're going to move to an in-memory database, which is relatively new, somebody must come up with the idea and the company has to spend money and feel confident about it. Tell us what the behind-the-scenes journey was like to get it going.

Chris: In my role – and I have a great team that helps me make good decisions – I make sure the company is prepared, from a technological standpoint, to compete with the market in five or ten years. My resource came to me several years back and said, "Are we prepared to do X, Y, and Z?" I looked at our environment and said, "No." He said, "Well, do we need to be prepared to do X, Y, and Z?" I said, "Yes." 

There's a good chance our CEO's going to say, "Hey, can we do this?" I want to be able to tell her, "Yes." And if I tell her no, I want to be able to tell her I can get it in a couple of months, not a couple of years. The X, Y, and Z had a lot to do with our analytics and ability to process data in a high-performance way. At the time, we were running an SQL server instance that wasn’t an in-memory version, and we identified that moving to something like HANA could offer that opportunity. We performed an analysis to say, "How much effort, how much money, how many resources would it require to get from where we are now to where we want to be so we’re prepared five, ten years down the road?"

We discovered, "Okay, it would take a reasonable amount of effort." We asked, "Do we have those resources? Do we have those dollars?" We checked those boxes and said, "Yes." So we went forward with that and we've been running HANA for two years, and it's one of the better decisions we've made – at least since I've been in my role at HTRI.

Carl: What were the top two or three goals you wanted to achieve by moving to the HANA in-memory database? 

Chris: Specifically, we have a division at HTRI that deals with fouling. Fouling is the phenomenon that happens when you have a liquid that runs inside a heat exchanger, and, based on the process conditions, that liquid hardens. It sticks to the side and essentially limits the flow you can have through a heat exchanger. As you limit the flux, the amount of flow you can have through a heat exchanger, you have to put more energy in to get that fluid through. More energy is more money, and it's a problem many people have – a billion-dollar problem in the oil and gas industry. We're constantly trying to help our customers predict how to do that more efficiently. They're going to have to tear down their rigs, clean them, and maintenance them so they're running optimally. When they tear them down, they also have the issue of they're losing dollars. It's this catch-22 they have to deal with. They don't want to have it down a lot, but they want to have it down when it's appropriate. We need to help our customers predict when to do that, so we're constantly running tests on our end, establishing new models and such. The process before was that we would run the tests, gather the data when they were finished, manually convert them over into a format we could run analytics on, and run the analytics. However, we couldn't compare that run to the prior run versus the run we ran a year ago versus the one we had two years ago. It was an overly manual process, but when we updated and could get the data in-memory, we could pull data in real time off the rigs and run it through the same models we ran the data on a year, two years, three years ago. We got a much faster turnaround as we were running live tests, and ultimately that's resulted in faster reporting and faster answers for our customers. They're much happier.

Carl: That's great. You probably didn't know this, but I had about 10 years of experience in the oil and gas industry. I was more on the distributor side, so I know a lot about hydraulics and motor oil. A lot of stuff I'd like to forget, actually!

Chris: It's a very involved industry.

Carl: It is, and there's a lot of science behind it, and it sounds like you guys are in the thick of it. Against those goals, how has this transition worked for you guys, big picture-wise?

Chris: It's great, and what I've found is, internally, I want the staff’s processes to be running efficiently, but we occasionally develop strange processes. I think our role isn’t necessarily to develop technology and software; we also do a good job of evaluating processes and, "Hey, is this process working for us? Why did this process happen?" We're creatures of innovation. We do whatever it takes to get the job done sometimes and sometimes that innovation may not be the best choice at that time. It got the job done, but long term it's not the best.

What our group has done is look at some of those processes and improve them. We now have a process that works for our fouling group, but we also have a condensation group. We have a boiling group. We have other groups peering over the fence saying, "Hmm, I like what you're doing there. What will it take to get our group to do that?" All the time we’ve been working on fouling, it's been in the back of our minds that other groups could benefit from this. They may not realize it now, they may not know they need it, but let's put ourselves in a position to be able to service them when their needs arise. We know what we're doing has a lot of value.

We're always considering, “What's the next step?” We don't want our projects to take on this huge breadth of functionality, but we don't want to pigeonhole ourselves into just that one particular project and have tunnel vision. What we've been able to do is service many other groups as we've made this transition.

Carl: Yeah, and it sounds like you couldn’t just take the old way you did it and make it faster. You did some re-engineering also, is that right?

Chris: Absolutely, and that's the problem a lot of these projects have: “Are we close to a solution or do we need to take a step back?” Have a paradigm shift and reevaluate the foundation of the process. That's exactly what we did. To do what we needed to do, we needed a completely different foundation. We had to have an in-memory database that could service the performance we desired. Once we did that, we could fix the nuances of the process that were broken and decide on the final product that best services the customer the way they need to be serviced.

Carl: This whole innovative step set the stage for a better tomorrow. You make it sound really good, but you and I both know there were surprises. Some good ones, it sounds like, but what about the bad ones?

Chris: The bad ones are that it sometimes takes longer than you think. Not always, but in this case. That was a product of the scope expanding, and what I've found is that it mostly depends on who you work with. Who's your customer? Have they worked on a large software endeavor before? Or a large technical revamp? Do they understand how many moving parts there are? I touched on processes earlier. A lot of these projects, they aren't just updating the technology, they're also understanding, “How are the processes going to work around the technology?”

While we're all software engineers and we love writing code and solving those problems, we spend a lot of time with the clients understanding how they’re going to use the technology. Those aren't as technical. They're questions like, “How can we be more efficient?” That's where a lot of time is spent, doing that type of planning. As the customer looks at what we're doing, their eyes light up because often it's hard for them to visualize how this will work. A lot of them, they want to get their hands on it. They want to see it, and once they do that, their eyes light up. Their ideas take off. They have all these grand new ways they want to use the tool or brand new features. That's where the scope creep comes in.

A project we say, "Hey, it's going to probably take 12 months," can easily take 24 months. Now, the scope has increased and ultimately, if it provides great value to the customer, it's worth it. So, yes, it doesn't always go well, and things could take longer. Amongst the small issues you have with change, many people don't like change. That's not a new thing, but once you get to that final point and they see the value, it's well worth it.

Carl: Yeah, it sounds like there were bumps along the way, but your team weathered them well. This is a big endeavor. Moving a lot of your internal processes into this in-memory database for analytics purposes and serving your customers better, whether they be external customers or internal customers. What do you want to do next to innovate or update the way you might work with suppliers, customers, and other business partners?

Chris: You talk about automation and those sorts of things, and people love automation because the technology can take work off their hands. I can scale up our business better. I'm not spending as much time tinkering with widgets, doing whatever it is to make processes work. Along the same lines are self-help tools. We're constantly trying to develop tools, enhance tools to allow our customers, whether they're internal or external, to provide self-help opportunities. Users love usability. They love something that's easy to use. We all have our phone preference; I choose a phone that's most usable, regardless of functionality breadth, because I like something that's easy. Even though I'm kind of a software engineer snob, if it's easy to use, I'm happy. We’re trying to make our products, the interfaces, user-centric, easier for the consumer, especially in our environment. There are still a lot of baby boomers in the oil and gas industry who aren't as tech savvy, and even though in 10 years they may not be the users, it's still important that they're happy with the product, that they're able to use it. Those are the expectations our younger users also have.

Carl: Well, I'm grateful you guys are out there taking care of us baby boomers.

Chris: No, you're always in mind. We're always thinking about you.

Carl: You talk about usability. My nine-year-old grandson's a little more adept at using my phone some days than I am, actually, so I hear what you're saying. You guys are looking at ways your customers can answer their own questions rather than having to contact you about every question and making it easier for suppliers to fulfill orders and things of that nature through automation. Is that the goal?

Chris: Absolutely. We want to provide the ability to handle those tasks. We're always cognizant of security and making sure that's an expectation. It’s always there, but we find there are repetitive processes that are communicated via email. My goal is to have my inbox at zero. I know I'll never be there, but if I can have technology communicate through a channel that isn't email I'm having to read and respond to with my fingers, I’d love it. The IO ability of a computer is much faster than the IO ability of a human, as I tell my team. If we can programmatically handle those processes through computers, through software, that's what we want to do.

Carl: Last question for today’s podcast. Chris, what's the next biggest thing you're going to work on at HTRI?

Chris: Well, the next biggest thing is something a colleague of mine, Daniel Phelps, is working on. He's working on indexing all the case files we currently have for our company. We're talking billions of rows, and that's something we haven't dealt with before. I always use to think millions was really big, but when you start working with billions and dealing with the issues that come with that, it makes you rethink how big were your problems really when you were working with millions?

People want to talk about big data, and I thought I worked with big data when I had millions, but the B word, billions, is taking off to a whole new level. It's opening a whole new world that I hadn't been a part of and I'm learning. Daniel's taking it with me, and we're excited to see how that project can grow and provide more value for our company.

Carl: That’s exciting; maybe I’ll have you back in a few months to talk more about that because talking about billions, I have to get my head around that.

Chris: You ought to hear those numbers when they talk about the U.S. GDP and deficit and all those sorts of things. You don't see those numbers too much.

Carl: No, you don't. Well, Chris, I greatly appreciate you participating in The Connected Enterprise Podcast. I know others will identify with the journey and experiences you've had and will be encouraged by hearing about it. It’s way too easy in these podcasts to be long and wrong, and I intend to keep this one short and to the point. Until next time, I hope everyone will stay connected.