Going Deep on the Database
ProData's Nick Thelen and Alex Olvera highlight the company's RDB Connect and DBU tools, discuss the security factor, and explain why IBM i developers are the best database creators
This transcript is edited for clarity.
Peg Tuttle: Welcome to another exciting episode of PowerTalk with Peg Tuttle, where we dive deep into the world of IBM i and the brilliant minds that drive innovation in this space. Today I am thrilled to be joined by two key players over at ProData Computer Services: Nick Thelen, Chief Technology Officer, and Alex Olvera, Senior Developer and lead behind the powerful RDB Connect product. We’ll explore their journey in the IBM i world, the groundbreaking tools that they’ve developed, and how RDB Connect is transforming the way companies interact with multiple databases in realtime. Stay tuned for an insightful conversation that’s sure to inspire and educate.
So happy to have you all with me today. I am super excited to welcome behind the mic today the team from ProData Computer, Nick Thelen, the CTO, and Alex Olvera, senior lead developer. Welcome to the podcast, guys.
Nick Thelen: Thank you.
Alex Olvera: Hello.
Peg: So happy to have you both here. So let’s go ahead and just have you guys give a little bit about your role and what you guys do over at ProData. Let’s start with you, Nick.
Nick: Yeah. I’ve been here for 17 years. Started out just kind of as a main developer and then I kind of fell into the chief technology officer role or whatever title that it leads to.
Peg: So you’ve been there 17 years—you’ve seen a lot over the years, haven’t you, from maybe idea creation on a product to bringing it to market?
Nick: Yeah, I would say when I got into it—it wasn’t as fast-paced. I know prior to me kind of getting into the IBM world it was pretty crazy there for a while—especially pre-Y2K. But after that I’ve just—you know, IBM has been growing. Whether that’s just being more dynamic, they have really grown their hardware and software, so I’ve seen a lot of third parties trying to develop software that compliments that for companies.
Peg: Yeah, yeah, absolutely. I think it’s interesting that you said it wasn’t crazy and now it’s super crazy and I think we’re all trying to keep up with the digital age—you know, how can we do stuff more faster, easier, and bring product to the market. We’re going to talk a lot of about today, because that’s what you guys are doing and helping people do that, so it’s really exciting. Thank you, Nick. How about you Alex? A little bit about you.
Alex: Well I’ve been here at ProData for a little bit over ten years, this year was my 10-year anniversary and it’s been awesome. I’m the lead developer for RDB Connect and it has evolved into an application that a lot of people I feel are going to be using moving forward, and I’m excited about that.
Peg: I think that’s great. So, ten years—congratulations. I know when we work in technology—at one point when I started my career here on the IBM platform, it was the System/38 and the AS/400, and now IBM i—but back in the day, some of the developers that we had working for us would say things like, if you’re at the same company for more than three years, you’re missing out on technology and advancements that are happening out in the industry. But I tend to disagree with that because as long as we are going out and looking for that technology and creating that technology, our roles continue to develop, right? I mean look at you, Nick. You started as a developer and now you’re the CTO.
Nick: Yeah, it’s an interesting environment in the IBM i world, because I mean typically it’s a little bit older generation that’s been carrying us and now, I’m kind of in the middle. You’re starting to see some younger people come up in the same platform. There’s a lot of opportunity for growth for young people, that’s for sure.
Peg: Yeah, I totally agree with you. We’ll have to maybe talk about that some time. I don’t know if we’ll have time today but I love talking about how everybody talks about the skills gap—and yes, we all recognize that it does exist out there. However, people when they were coming out of college in the 1960s and 70s, they had to learn how to code on these new platforms that were coming out of IBM and other developers. So it’s no different today. They just need to come and experience how awesome the IBM i is, and also IBM Power [Systems]. So Nick, you’ve been around for 17 years. You’ve seen a lot of the evolution in IBM utilities first hand. What do you think really sets ProData apart from some of the other companies in this space?
Nick: Well, we were able to get into that space early. That helped develop some good relationships with customers. It also allowed us to kind of expand our software offerings and continue to build our mainline products. I mean most of our software is driven by customers that are looking for new features, options, and we can usually turn that around pretty quick.
Peg: I love that because—you know the customers, they’re living and breathing in that world, so we’re not developing in a vacuum, right? We’ve got to have input from what our customers are doing, and everybody’s environment is so different. You guys continue to do that today. So like if you could say—you know, what? 50% of your enhancements come from your customers? Or is it a larger number, like maybe 75-80%?
Nick: I would say with RDB Connect maybe 50%, but most of our other offerings it’s almost 95%, just because we’ve kind of thought of everything that we can possibly think of and we’re not going to use our software like our customers are going to use it. We have somewhat of an idea what’s going on, but we’re always surprised what they’re looking for, and a lot of times we can make it happen. So why not, right?
Peg: Yeah, yeah. So Alex, you’ve played a critical role in helping to modernize RDB Connect. Can you share a little bit about what excites you about this product?
Alex: Like I mentioned before, RDB Connect has a lot of potential, and I feel that with RDB Connect, customers will be able to integrate IBM i systems with modern databases, cloud, and CRM platforms. There’s also a lot of potential to add RDB Connect to AI and be able to assist customers, developers to create sample RPG code or whatever they need. They’ll be able to easily create those instead of trying to figure out on their own. Or if they have trouble with any of that initially, because that’s the main—not problem, but that’s the main thing that we have with some customers that are a little bit hesitant to develop applications on their own. They usually just want to use tools that we have created in RDB to be able to import/export data from databases to the IBM i or vice versa. But I think that will also be a lot of help.
Peg: Yeah, I think just what you said there—the ability to do more with your product and it gives them the comfort level. Nick, did you have anything you wanted to add on that you’ve seen?
Nick: Yeah. You know dealing with the customers and some of their questions, I think they want to move data simply—and I don’t mean that like in a good or a bad way. Like we have an export/import, which is kind of more of a mass type movement. But with this software, they can just utilize like RPG code to access data, on like an Oracle box. They don’t even have to be using Db2. I mean, they can—it just opens a new way of getting data. It’s not really getting it, it’s just using it—use your IBM i to work with an Oracle database or an Excel spreadsheet. It doesn’t have to be just Db2 anymore with RPG code. I think a lot of people don’t realize—like you can use this tool to utilize your whole company’s data resources.
Peg: Yeah, and all of that is done realtime.
Nick: Correct. So I know it sometimes can be a big project for somebody that’s on the other side—you know, buying this product. It’s a lot of setup, but now looking at AI, an ability for us to help create example codes for them, I think we can simplify this going down the road for them.
Peg: So I know that there’s a lot of work happening in AI right now. Does your product work with watsonx, or does it need—you know, what does it use for an AI back end? Is it anything that the customer wants to use? I don’t even if I know I’m asking the right question.
Nick: It’s a great question. We’re a little green to it right now. We just kind of decided this is maybe a route we need to start going. We’ve been playing with ChatGPT, just kind of looking at putting some of our APIs out there, and then eventually it just starts to help give the AI more intelligence to build some of that code for them. So we’re a little late to it, but it’s been fun. I think it shows a lot of promise.
Peg: Oh yes, absolutely, I agree. With what we’re seeing from other vendors in this space, IBM in this space—and even what Steve Will is trying to do over at IBM with the RPG Code Generator. I actually probably should connect with Steve and get an update on that as to where things are because I know they had some big plans here for the end of the year. But anyhoo, yeah, I think that will be really interesting to see what happens with that because everybody is exploring with it. So then that leads us to security, and security is just a huge concern always for everyone. So how does RDB Connect ensure secure connections when you’re interacting with those remote databases, and then we can go ahead and just throw some AI in there too. How you know where do you guys sit with security and supporting the customer in that area?
Alex: I’m going to answer that. RDB Connect ensures the connections or uses a lot of the encryption authentication, and all of that can be used based on also their systems or their encryptions—any SSL certifications that they have. So all of that plays into it to be able to get everything secured.
Nick: I mean we’re using the native drivers. That allows us to access that data most of the time—I mean almost all the time. So within that, there’s security. Typically you’re working within your network whether it’s a cloud base and you have a VPN connection set up to that. There’s security built into that as well.
Peg: So you guys are definitely addressing all of the areas and if customers have questions, I know they can reach out to you and explore that in more detail.
Nick: Correct.
Peg: What are some of the different platforms that run alongside the IBM i that your product RDB Connect facilitates that integration with? Can you maybe just list a few of those or talk about them individually?
Nick: Yeah. I mean the big ones are always going to be Microsoft SQL servers, Oracle, MySQL, Postgres. Now we’re starting to see a little bit more cloud-based options, whether that’s just for storage. Some of the big servers that RDB works with—Microsoft SQL server, Oracle, MySQL, PostgreSQL—those are kind of the most common, familiar names, but you can also drill down into like an Excel spreadsheet, and I know cloud is becoming super popular—like AWS Cloud and stuff like that—and it all works with that. I mean really you’re just kind of in control of those connections, so that’s nothing we haven’t dealt with. It’s been pretty seamless. I do know that it does slow down a little bit when you start going cloud-based, because that server is not right next to your IBM server.
Peg: Sure. There’s a little bit of latency there.
Nick: Yup. But like AWS, they have sped it up so much that I don’t think you really even see it anymore. You know everybody was kind of, new things were a little bit slower, but they’ve definitely caught up.
Peg: Yeah, they’re doing a lot of over there. Well, they all are. Azure, Google—all of those play into that too as well, right?
Nick: Yup and we’re working with Azure now. You know a lot of people use CRM systems, so we can get that data. I know that data is valuable. Some of them lock it down but so far, we haven’t been stopped on those. We’ve figured out a way to get that data, which is I think resourceful for companies.
Peg: So how does it simultaneously manage the connections then?
Alex: Well, it uses a Java-based connection which has a multithreading—that’s where you can have multiple connections at once running, that’s how it’s all handled. So it is a multithreaded job that is running on the IBM i side.
Peg: I always like to have an example—you know where you can talk about a customer. No names are necessary, just maybe a real-world example of how a customer or maybe two customers are using your product successfully today.
Nick: A manufacturing company that we work with, kind of mid-size, they use IBM. That’s their main system. They purchased another company. They’re using SQL Server for their financial data, so they’re using RDB Connect to kind of streamline some of that so that they can integrate their financial data with their IBM i as a way to integrate data from both systems without the costly and time-consuming process migrating data to a single platform. By using RDB, they’re significantly improving their operational efficiency and reducing costs associated with data integration and reporting, gaining the ability to seamlessly connect and integrate data from different databases.
Peg: …I know that ProData is a very popular company out there. I’ve seen you guys at trade shows and know that you guys are well loved out in the market. When people come up to you at like POWERUp, our big conference in the spring here in the IBM i space, they’ve got to be sharing with you, you know, what’s hot for them—you know, in areas. When you sit and talk to them, do you go, oh you need to be using RDB Connect and this is why as they’re sharing their stories with you? When you guys hit these shows, is it an opportunity for you to gather information to come back on the product and enhance the product? Then is it also an opportunity for you to share—I’m sure it is—to share what other customers are doing with your current customers, or people that are thinking about the product? I think that that’s probably a lot of conversations going on at the shows.
Nick: Yeah, the shows are—it’s a good meeting point. I mean a lot of people do own our DBU product so that just kind of draws them in, but with any tool you’ve got a minute or two—you know, the quick sales pitch to try and explain what RDB can actually do. Sometimes it can be just overwhelming, so it’s nice to do like a podcast like this where maybe there’s a little bit more information and some actually listen to just see what this product can really do. The product shows for RDB Connect can be a little bit difficult. I’m sure there are other vendors—you know, how do you get that little quick pitch of what this product can do for you? So trying to find that little bit—they’re going to be like okay, I’m interested in other systems you know. And sometimes they’re like yeah, we have that but we don’t work with it. It’s like okay, we need to talk. Like if you’re not working with that and you’re not talking to that other side, you need to be working with us because that data is important to your whole company, not just people that are on the IBM i.
Peg: Yeah, and then helping them understand how you can bring it altogether, right? You’ve got that single source tool that helps get everybody talking together.
Nick: Correct—and you know a lot of people are moving big piles of data back and forth and they use our software to do that as well. I’m just like, you’re moving a million records, the same million records sometimes with a few updates to it nightly. That’s a lot of data to be moving. We can make that so much more streamlined and so much more efficient, more realtime. Like why are we doing it in big groups? There’s a lot of software out there that do move data very easily, seamlessly, but it’s not drilling down to we don’t need to move the data. Leave the data where it’s at—just update it. We don’t need to move the data from a MySQL server to your IBM i to work with it. No, you just leave it there. Let our software work with it on MySQL.
Peg: Yeah, absolutely. I think that you just hit on a really big point right there, Nick—the fact that you don’t have to move the data. Just leave it right where it is. Here’s a great opportunity for people to go and learn about products, go to the shows and check it out, and they might not be doing that. So maybe they’re tuning into this awesome podcast right here, but you know it’s one of those things where it’s significant. It’s a significant impact. It’s a significant cost savings. So why wouldn’t somebody do it, right?
Nick: Well I think it’s more of a comfort too, because it’s like you’re familiar with IBM i, you’re familiar with RPG, let’s say. Well you can still use the language to get that data or to update that or you know, whatever you want to do with that data. So I feel like it’s a familiar place for developers that are on the i. There’s really no learning. You don’t really have to learn anything new, you just have to code. It’s just using APIs and SQL, which I would say a large majority of the IBM community is familiar with.
Peg: Yeah, they are. I agree. So, here’s a question for Alex. You’ve been kind of quiet, Alex, so I’m going to pick on you for a minute. As the lead developer, you really help to modernize this product and you added the new APIs and different tools into it. What were some of the challenges that you faced during this process? And maybe you can share a little bit about how you overcame them?
Alex: Well, the main challenges that I encountered initially when I started—it was mainly making sure that the data that was going back and forth was the correct data that was supposed to be there. IBM does a really good job at translating that back and forth, and so that was one of the main crucial things I was concerned with. The other thing was the SQL syntax. Each database has their own little ways of specifying SQL syntax. Some are identical or similar, but for example, MySQL has their unique way of specifying the SQL statements and all that. So that was one of the main crucial things that I encountered.
Nick: Yeah, trying to match the data types up.
Alex: As long as data types—because some have different data types and some have the same data types and some don’t even include that, so that was another.
Nick: We just dealt with a company who was not defining a field and they have it as a 25,000 value, and he had multiple 25,000 values. Well, you can imagine the IBM i goes wait—what is all this?
Peg: Oh my. Yeah.
Nick: Some of the other challenges that we have to deal with is we kind of back support to 6.1, 7.1. We’re kind of you know, you have to kind of limit yourself a little bit of what we can and can’t do. There’s a lot of different Java versions out there, so that’s a little bit of a challenge. There’s a lot of challenges, actually. I mean, trying to get that data and getting it to fit in the right bucket and you know, hold that data properly—especially when you start talking about blobs and globs and double-byte stuff. I mean there’s a lot of that we see, so there’s a lot of special coding that goes into that and how to handle stuff like that because we have to kind of take a 25,000-character field and kind of limit it. Then if we have a customer come back and say hey, this is being cut off, then we have to come up with another solution to figure out how to handle that. So it never ends.
Peg: Yeah, yeah, absolutely. And then when you talk about that, you just make think about best practices. How do you optimize best practices for your customers with these queries that are running through this product?
Nick: I think IBM i developers are the best database creators. We work with other databases like an ORACLE 1, and they’ll put no max for every single field—I mean it’s just going to fill that space up sometimes. So I think IBM i developers are a little bit of ahead of the game. They know some of the older generation had to learn how to not use space, because space was expensive.
Peg: Any pitfalls that you think developers should try to avoid?
Nick: I don’t know. It seems like every time I think of something they shouldn’t do, then—
Peg: They do it [laughs]?
Nick: Well, I’m really amazed how we deal with customers, especially in DBU. We know data, right? That’s what we know. So when we see the way people are doing things, it’s like oh well, I would have never done it that way or thought of doing it that way. Then you talk to them and okay, now it makes sense—and then sometimes it just doesn’t make sense. They had somebody that worked there, they didn’t know what they were doing—so you have to deal with it. I mean every third-party software development company out there has dealt with handling wild stuff you know, so a lot with DBU too.
Peg: Oh my gosh, yeah. You made me think of a few people I know [laughs].
Nick: Yeah.
Peg: I love it. Yeah, there are some cowboys out there.
Nick: Yes, and we work with international companies, so you know double-byte stuff and there might be a field that has double byte and single byte within the data. So how do you handle that? RDB, the JDBC drivers handle a lot of that for us so that’s helpful, but like on the DBU side, I mean you’ve got to parse that stuff out. You’ve got to see that and handle it.
Peg: Yeah, yeah. Well, that’s interesting. Any other customer highlights or stories or maybe conversation or success stories that you want to share before we talk about the future of the product?
Nick: We had a customer who like I said was moving a million records a day. He was complaining. He was like, is there like a faster version of your software? I’m like well that’s not very efficient, so we wrote a little bit of code for him just to kind of help him out. Like you can update this individually, you don’t need to be handling this massive amount of data. I know it seems easy in the long run but that’s a long process. I mean it was taking an hour or two hours? I don’t even remember.
Peg: Oh my gosh.
Nick: It was too much time, right?
Peg: Yeah.
Nick: So our software is not limiting anything. I mean I guess we could put a boost package on there and charge extra for it or something? I don’t even how to code that.
Peg: Hey, there’s a product idea right there [laughs].
Nick: Yeah, yup. There you go. So yeah, that was one. I was like this is simple, and once we did one little thing for him, he was like okay well, just kind of rinse/repeat.
Peg: Yeah, I think that’s interesting. Now I’m just thinking about how much time and money he just got back from that one little process. Every week and a half, that’s a day of time back you know.
Nick: I mean he had people waiting for that data. They kind of had a planned downtime where that data wasn’t available, and you think about realtime. Me and Alex have both worked from the trucking industry, which is a pretty difficult industry. I mean data is moving fast and a lot of data. It’s a very intense. I worked manufacturing and trucking—it just blows me away how diverse it is just in how they’re handling all the factors that go into it.
Peg: Yeah, yeah. You made me think of a big company down in Florida that is moving a lot of trucks and their product every day. That’s a whole other conversation. You could talk about the trucking industry all day long, I think. Those good people out there doing the hauling stuff and I don’t know—I was talking to a team the other day. That’s a railroad company and all of the things, the data points that they’re collecting on their trains every day? Amazing.
Nick: Yeah.
Peg: Every day from the temperature of the wheel to fractures, how the line is looking—everything. It’s amazing to me.
Nick: We have a few RDB Connect customers out in the railroad industry, and it’s kind of cool to hear what they’re doing. They have some pretty smart cats working in their IBM department, so they’re pretty solid on it. I mean they don’t really talk about going away from it, so it’s working for them.
Peg: Yeah, well where else would you go?
Nick: Exactly. There’s nowhere else to go.
Peg: There’s nowhere else to go. This is it. Yeah. So, you’ve been in the industry a long time and you’ve been working with your products for a really long time. I mean they’re just solid, but everybody wants to know where are we going to go from here? What’s the future look like? What are you hoping for? So maybe you could talk a little bit about that with regards to the product, but then even with ProData—what’s coming down the pipe from you guys and what are you thinking about? I know you mentioned AI, but what else is out there for you?
Alex: This is Alex. I’m going to answer that and Nick can tag along, but what we see RDB Connect in the future is getting it to where a lot of companies or customers are able to use it and be able to tie their databases—well, from the IBM i and other databases that are out there now—along with, like we said CRM, platforms, cloud-based. That’s kind of where we’re seeing it being used most now, on the cloud and CRM platforms. Like I said, we’re going to look into the RDB Connect, adding it to AI and seeing if that helps some of those developers that are still green on developing our actual programs, customize programs on their own instead of using our tools just that we have by default such as RDB Connect for RDB export that are simple to use.
Nick: Yeah, I mean the security factor in this world, that’s driving us a lot because people are updating their system. So that requires new JDBC drivers and new Java versions just to maintain that level of security that they need, whether it’s encryption or authentications. It’s wild some of the things—you know it’s not just a user/password anymore. It might be a token that expires in four hours. Okay, how do you handle that? We’ve come up with solutions for that as well, so I think security is going to keep driving us. I wouldn’t want to say it’s reactive, but it is a little bit just because what the customers need, we can’t always influence that. They’re going to influence us.
Peg: Yeah, they’re going to have a situation or they’re going to have something come up, and they’re going to call you guys like on the bat phone and go hey you guys, we need an update or hey we need help, or what are doing in this area?
Nick: And developing code, that takes time. So if we can use the tools around AI—you were talking about another tool that’s for code developing, like a code generator. I mean if we can tag onto something like that and help the customer out to get code out quicker, that’s great. I mean I’ve seen some of these people’s SQL statements and I’m like, how long do you spend creating and testing these things? This thing is like three pages long, you know. Some of those SQL statements get pretty crazy. We try to kind of feel the market and kind of figure out what’s going on, but I mean it really is just customer-driven. I mean that’s just how we’re set up right now. Like we’re not out there running the software with these—you know, we have a billion record files that we test against and do things regularly just to see how it works against that. But still, the customer is telling us what they need. So we’re small enough to where we can make adjustments pretty quick, pretty easily—like we don’t have a big process where well, it might be a year. Sometimes some of the stuff is, so we pride ourselves on that and being able to work with them. I mean we’ve had people come with databases like, we don’t really know anything about this. So we start looking at it. Hey, this is going to work. We can do this for you.
Peg: That’s awesome. I think it’s great and remind me again: How long has ProData been around? I think it’s what? 30 years maybe?
Nick: I think it’s 40-plus.
Peg: 40-plus years. I love it.
Nick: I should know this answer. It’s like 45 years. Somebody is going to be sending me a message on Slack pretty soon going hey, it’s this many years. I’m waiting for it. Yeah, it’s been around for a really long time which is great because we know a lot of the customers. 1981—I just told you. I just got a Slack.
Peg: There you go.
Nick: I knew I was going to get one. There you go.
Peg: There you go.
Nick: So whoever wants to map that for me go ahead, but so it’s nice to be able to go to these shows—like we’re going to be in Florida which by the time this podcast comes out this will be past that—but it’s nice to see our customers, talk to them a little bit. We’re starting to see more new faces, which is nice.
Peg: Yeah. Yup.
Nick: I think people are getting a little bit better about sending some of their newer employees. Sometimes you see the same people over and over, which is great. They love going and that’s where they learn. They’re excited about the platform, but it’s nice to see some new faces coming in.
Peg: Yeah, younger faces. Yeah, yeah, absolutely. Even if you know somebody’s job changes and they need to pick up another area of the business, they’ve got these awesome resources from TechChannel, from COMMON, from all of the different people out there that are offering education. So it’s good. Yeah. Well maybe I’ll see you when we’re in Florida. I’ll only be there for a couple of days, so let’s plan on it.
Nick: Yeah. Sounds good.
Peg: Well thank you so much Nick and Alex for joining me on PowerTalk with Peg Tuttle and just talking about product and just how solid it is, how solid you guys are in this market. Your ability to support the customer where they’re at and where they want to go is really, really instrumental. So thank you so much for coming on the show and sharing your insight. I know that if anybody has questions or they want to learn more about the product, just head over to their website, Prodatacomputer.com. There’s going to be information out there. Alex, Nick, and the team will all be there to lend support and get you additional information, whatever you might need to get your job done faster and easier, right?
Nick: Right, yeah. Come get a demo. We can do those and we could do a little bit of coding for you and get you to see it in real time.
Peg: There you go. I love that. Well thank you so much everybody for tuning in, and we’ll see you on the next show.
Nick: Thank you.
Alex: Thank you.
Peg: Thank you.