Mainframe Modernization with Paul Holland and Chad Jones

Walter Sweat

Hi everyone, welcome to the latest edition of Walter's World, the podcast series from Astadia, a new Amdocs company. We appreciate you being here today and hopefully if you've seen some of the other podcasts in this series, you know that we try to bring in industry experts to talk about the topics of mainframe migration and modernization and all the new areas that are applicable in this mainframe space. Today we're going to do something a little bit different.  

Walter Sweat

I am delighted today to have joined me two new members of the Astadia team who happen to have been industry experts in this space for a really long time. We're delighted to have them join us here today so that they can share not their Astadia experiences so much, but what they've seen in this industry and how that might apply to be applicable for you as you look at your alternatives. So Chad Jones and Paul Holland.  

Walter Sweat

Welcome to the podcast series today.  

Chad Jones (01:04.679)

Thanks, Walter. Glad to be here.  

Walter Sweat

Thanks. my pleasure. Thank you. Paul, Chad, perhaps it would help if you just kind of started to give a little introduction of yourselves for those people who may not know you yet.  

Paul Holland

Yeah, thank you, Walter.  

Paul Holland

Yeah, happy to do that. So my name's Paul Holland. I've recently joined Amdocs Astadia in the position of CTO. Big boots to Phil because Walter is focusing more on client relationships and I'm picking up some of the pieces that he's no longer responsible for. My history with application modernization goes back a long way. So I won't bore everyone with taking them back through.  

Paul Holland

the decades, but I joined Astadia from IBM, IBM Consulting. I was a partner there for mainframe modernization, focused on the financial services sector and focused on mainframe modernization in that group.  

Walter Sweat

Thank you, Paul. appreciate it. Chad, how about yourself?  

Paul Holland (02:14.202)

Good job.  

Chad Jones (02:19.571)

Yeah, hey everyone. My name is Chad Jones. I am the newly appointed Chief Revenue Officer for Astadia. I joined Astadia about six weeks ago, the same day as Mr. Holland did. I've been in sales and sales leadership my entire career in the last 15 years in the technology space in the last seven years in the legacy modernization mainframe to cloud space. So seven years to me,  

Chad Jones (02:49.341)

feels like a long enough time to feel like I've been doing it forever and I guess I earn expert status, but I'm on the call with some guys who have been in this market and in this field for decades. So anyway, I came here by way of AWS. was a mainframe go -to -market leader for global financial services at AWS for a couple of years before joining here. I was within Sono for a short  

Walter Sweat (02:53.816)

Ha ha.  

Chad Jones (03:18.003)

period of time before that running sales for their mainframe modernization practice. And before that, I was with Modern Systems, an advanced company as VP of sales for four years. And they were recently acquired by IBM earlier this year. yeah, I've been fortunate enough to work with some great guys and people in this industry with great experience. And yeah, good to meet everyone.  

Walter Sweat (03:35.746)

Fantastic. Thank you.  

Walter Sweat (03:46.872)

Thank you, Chad. And Paul, I think what Chad just did was call us old, saying that we've been around for a while. Paul, you and I have known each other since the 90s. We have worked as partners. We work for the same company. At one point in time, I worked for a company that you were a vendor for. So you happen to obviously be someone that I have a both of you guys, but Paul, you and I have been together forever and great deal of respect.  

Chad Jones (03:53.073)

Hahaha  

Walter Sweat (04:16.117)

One of the places where we  

Paul Holland (04:16.878)

Yeah,  

Paul Holland (04:17.42)

Walter, despite knowing me so well, you still asked me to join Astadia. It's incredible.  

Walter Sweat (04:22.926)

And  

Walter Sweat (04:25.236)

delighted to have you here. One of your roles when you were VP of sales at Clarity Solutions where we had interaction at that time as well. Clarity was a market leader in mainframe rehosting solutions. I'm curious, based on your experiences here, especially in the last several years, do you think there's still the same level of interest and a market for  

Walter Sweat (04:50.848)

re -hosting mainframe workloads as an alternative, a pathway for people to move forward.  

Paul Holland (05:01.241)

Certainly not the same. I think it's worth going back and you and I were laughing about this the other day because if you actually think about when I was at Clarity and really focused on mainframe replatforming, the cloud was very much in its infancy by then, if really having any traction at all. It was at best...  

Paul Holland (05:29.16)

sort of infrastructure driven. And the reason people were getting off the mainframe and actually it was really at the height of the recession, the great recession that this was happening, people were getting off the mainframe. The main reason was cost saving. There were not the pressures that we see today around availability of people with  

Paul Holland (05:58.234)

COBOL skills or some of the other even more legacy technologies back then. There were obviously pressures around licensing costs of software on the mainframe. That's one of the main drivers of costs on the mainframe, but not so much the technology drivers back then. And of course what we were doing, as well as our friends at Micro Focus, we were replatforming without really making  

Paul Holland (06:27.108)

big changes to the underlying technology. So if you have COBOL running on the mainframe, you could move off the mainframe pretty rapidly, pretty smoothly, but you ended up with COBOL running off the mainframe as well. And I think things have moved on to the point that first of all, cloud adoption is prolific. And cloud adoption now is not just about infrastructure on demand, it's about a stack, it's about a platform.  

Walter Sweat (06:39.309)

Right.  

Paul Holland (06:56.336)

for applications and the underlying technologies and ability to find people with those skills has diminished enormously since we were doing those refactoring. So I think the market's changed. think time's different. don't think refactoring is dead or sorry, I don't think replatforming is dead. I think there are certain situations where that may apply but  

Chad Jones (07:24.099)

Thank  

Chad Jones (07:25.082)

you.  

Paul Holland (07:25.444)

But I think it's a different time and solutions have changed.  

Walter Sweat (07:30.56)

I agree. was going to ask you and you kind of already addressed this. So thank you for doing so. You know, obviously the needs of the customers have changed and the solutions that they're looking for. You talked about, you know, back in the day, perhaps it wasn't as important, but mainframe resources retiring no longer being available became just as important as cost savings.  

Walter Sweat (07:56.672)

And then the other thing that I see now as we're looking to assist organizations with their biggest challenges, they talk about agility as well, being able to be more responsive and make that transition away to be in an environment, most often the cloud, where they're able to utilize a different set of tools. Have you seen the same thing?  

Paul Holland (08:21.764)

Yeah, very much. And I think it goes hand in hand with the cloud being the target of choice in the majority of migrations that we're involved in now. And that being so much more than just an infrastructure led decision. It's about building our applications on a platform and leveraging the...  

Chad Jones (08:22.487)

Thank  

Paul Holland (08:49.488)

capabilities that come with the cloud, the scalability options, and the agility of being able to modify applications and respond to business needs in a much more agile way using the latest technologies. So those are big drivers that have certainly changed over the last 15, 20 years.  

Chad Jones (09:07.947)

Thank  

Walter Sweat (09:15.798)

I agree. Thank you so much. Chad, we were talking about the cloud. You obviously joined us from AWS. And AWS has both replatforming and re-hosting solutions. In your experiences throughout your career, do you find that people choose to go in a particular direction, or do they look at what is most applicable for them?  

Chad Jones (09:27.763)

Chad Jones (09:40.594)

That's a really good question, Walter. think it's, and I'll answer it from two points of view. I think first of all, it's important to kind of work backwards from what the customers  

Chad Jones (09:56.177)

goals and objectives are in moving their workload off the mainframe into cloud. There's Gartner's five Rs, there are different patterns that you can leverage. We're talking about the automated options, replatforming and refactoring is the most common. Replatforming is a great option to follow if your goal is to get off of the mainframe quickly, you don't have an issue with COBOL skills.  

Chad Jones (10:25.235)

and you're fine continuing to develop your application in the cloud and COBOL. And that was common 10 years ago. I started to really see a shift in the market about five years ago with more companies looking to refactor versus replatform to address the skills issue primarily. I mean, it's a combination of addressing the skills issue if you're refactoring your  

Chad Jones (10:53.585)

you're modernizing all of your underlying technology, you're now out of COBOL, you're in Java or C Sharp, so you can maintain and move that application forward using Java and C Sharp skills. But it's also, five years ago, it took longer to get through a refactor project. I think that replatforming has historically been viewed as the lowest risk, easiest way to get off the mainframe. That's not the case anymore.  

Chad Jones (11:22.867)

Automated testing has really changed the way you look at those two patterns next to each other. Today, we can deliver a refactoring project in the same timeframe it takes to deliver a replatform. And you're two steps down that modernization journey instead of just one. That's kind of what I've seen here in the last five years.  

Walter Sweat (11:26.146)

Yes.  

Walter Sweat (11:42.402)

That's a great, yeah.  

Walter Sweat (11:44.593)

It's interesting, we've all kind of talked about COBOL, but obviously there are a lot other technologies that exist on the mainframe. Just my thoughts, when we at Astadia just did classic replatforming, it was great for COBOL. Absolutely a wonderful solution. But you still always had the concerns, what do you do with those other technologies like Assembler or Natural or IDMS?  

Walter Sweat (12:11.918)

How do you make sure that things cohesively fit together? It's been my opinion that refactoring has allowed people to work with more of those technologies than just that classic replatforming that we all worked with for so long. Would you guys agree with that?  

Paul Holland (12:31.854)

Yeah, absolutely. I think, you know, you're touching on the evolution of the capability of code conversion. The truth is, if you go back to when replatform in rehosting was really at its peak, code conversion had a bad name. It was seen as unreliable.  

Paul Holland (12:58.928)

It was seen as rarely achieving good coverage that you would get, you know, up to that 100 % conversion. It got you somewhere along the line, but there was always some manual intervention that was going to be needed at the end. And also, you know, its ability to get you to a point where you knew you had functional equivalence was, was unreliable. Things have radically changed.  

Paul Holland (13:28.944)

There's just the level of investment and evolution in code conversion over the last 10 years has really accelerated. And to the point that Chad was making, we have now reached a time where you can refactor an application from COBOL to Java or C# as quickly and as cost effectively as replatforming. There's no doubt about that.  

Paul Holland (13:59.232)

Especially when you look and I always stress this when I talk to clients, always look at the entire project, the end -to -end process. It isn't just about taking the code and replatforming it or taking the code and converting it, but you need to add in the testing windows on that. You need to look at the discovery phase of that. But if you look at the project as a whole,  

Paul Holland (14:23.554)

It really is a wash now between refactoring and replatforming in terms of costs. And that is that development. And a lot of that development stemmed from the fact that there were always going to be code components that weren't COBOL, that were Assembler, was always the big one, right? Because you have no choice with Assembler, that you have to do something with it. Assembler was always probably a more challenging one to look at from a code conversion point of view.  

Paul Holland (14:51.876)

but it was something that had to be done just to facilitate re-platforming as well. But I think when people started to look at COBOL and some of the more prolific languages, COBOL PL1 and others, as a means of applying code conversion to it, that we really started to enter the new era and where we are now.  

Walter Sweat (15:15.054)

that absolutely makes sense.  

Chad Jones (15:15.783)

Yeah, and would  

Chad Jones (15:16.364)

just, I would add that I think you need to look at it from a bigger lens than just the project itself. You need to look at where that project fits in your modernization journey or roadmap. For most customers, it's more than just one project. If you're moving hundreds of applications off of a mainframe, it's not something you do all in one go.  

Chad Jones (15:43.635)

So you've got this journey that you're on. And for most people, the journey is to get to a place of being off the mainframe and into cloud native microservices. So it's kind of to the point that I made earlier, refactoring gets you further down the road and closer to that goal. You're not just off the mainframe, you're now in modern technologies. You can now start peeling away your refactored modernized application from the cloud into microservices from the target environment.  

Chad Jones (16:13.661)

self-funding it with the operational savings that you're realizing from being off of the mainframe.  

Walter Sweat (16:21.838)

Chad, you bring up an interesting point for me, I think it may be the same for you. Ten years ago, and one of you alluded to this before, people just wanted to get off the mainframe to save costs. So they moved everything all at once. Of course, there were smaller mainframes back then, but today, my goodness, we're having the opportunity to talk to organizations that are 100,000, 200,000, 300,000 MIPS, who are probably never going to move everything away from the mainframe.  

Walter Sweat (16:51.864)

But that means that we've had to adapt to be able to say, let's identify the order in which things come off and let's understand the dependencies between them. Now, it's my opinion that being able to do refactoring where you're getting into the cloud environment, where you have a broader range of tools to work with means interfacing back to the mainframe.  

Walter Sweat (17:19.788)

that are still using the older languages, but being able to build those bridges with the tools that exist off the mainframe after refactoring makes that easier than it ever would have been able to be done back when all we did was replatforming. Would you guys agree with that?  

Paul Holland (17:42.424)

Yes. Yeah, sorry. I thought you were going first, Jeff. No, I look, I think now as we are, as you rightly say, Walter, we're dealing with the big stuff, right? We particularly a stadium now, I think is tackling the large, large, you know,  

Chad Jones (17:42.867)

Paul, you wanna take that one?  

Chad Jones (17:47.251)

You  

Paul Holland (18:10.018)

massive number of MIPS mainframes instance and that will always either create a situation where not everything is going to move. There isn't that need to move absolutely everything off the mainframe, close it down or as a minimum everything's coming off but it's going to take quite a while to get it all off. And so this idea of a coexistence strategy  

Paul Holland (18:37.016)

becomes increasingly important in our modernization projects. How do we build out the new, but bridge and synchronize with the old? And it could be that that has to be a temporary thing. So what we always used to call temporary scaffolding that needs to be put in place through the course of the project. Or is indeed the final end state

Paul Holland (19:04.48)

that the cloud instances are going to need to coexist with the mainframe. And in fact, you probably understand when I was at IBM, that was a model that IBM liked a lot, right? IBM wasn't saying, hey, you've got to keep everything on the mainframe forever. But they were saying, you can move things off, but let's keep some stuff on the mainframe. So you can understand their motivation for that. So this idea of what I used to call an integration hub.  

Walter Sweat (19:15.758)

Course.  

Paul Holland (19:32.42)

And the design requirement for an integration hub early on in the project so that you know, you've got that capability largely around data integration But sometimes at the programmatic levels an API level And you need to take that into account and build out that design as you're thinking about how you're going to move forward with the project It's very important component  

Walter Sweat (19:58.606)

Thank you. Paul, I'll start with you talking about just the projects. What do you see as some of the key components that help guarantee a successful refactoring project?  

Paul Holland (20:09.58)

Well, there's a couple I can say, is pick, organizations can't do, in my opinion, organizations will struggle to take on mainframe modernization totally by themselves. I think this is one of those situations where you need to bring a partner vendor into play and you need that expertise that...  

Paul Holland (20:39.056)

track record, just that knowledge base. It's not dissimilar to any IT project in that it's about products, process, and people. But the people bit here is quite important. You need to have people who have walked down this path before. There's a lot of potential potholes that can get in your way.  

Paul Holland (21:03.702)

And people who know what to look for and have been down the path before is a critical thing. So pick a good vendor. That's a good thing. And then going back to that products, people process, pick good tooling. Automation is critical to the success of these projects because otherwise they just become major rewrites and the track record on organizations being successful on time, on budget.  

Chad Jones (21:10.353)

Ahem.  

Chad Jones (21:12.967)

Yeah.  

Paul Holland (21:33.164)

is quite well known as a problem there. But I think the other major, major criteria of a successful modernization project is testing. Testing is key and that also is where automation is key. Sorry Chad, I just wanted to put this point aside.  

Chad Jones (21:50.277)

No, no,  

Chad Jones (21:50.732)

no, sorry, I was getting ready to cut you off. I would add one more very critical thing that I think is important to a successful project, and that's planning. Especially if you're looking at trying to figure out how to dozens or in some cases hundreds of applications off of a mainframe. It's working with a partner who can help you go through the process of analyzing your portfolio to start in determining  

Chad Jones (22:19.601)

what the patterns are, what the priorities should be, using tools to see how all of your applications hang together, mapping out all of the dependencies. Tools are extremely important during the assessment process as well. planning on the front end is critical. You don't want to get down the road into a project and not have a clear, defined strategy and approach.  

Chad Jones (22:48.935)

to how you wanna migrate and move those workloads off of the mainframe from the very beginning.  

Paul Holland (22:54.52)

And if I could just add Walter, because I think Chad said something very important there. Look, know, Astadia has a very proven, reliable, primary modernization pattern solution that we bring to bear, which is refactoring code. But I think Chad made a very, very important point. We do not look at modernization as, you know, one approach is the right approach for everything. So...  

Walter Sweat (23:21.87)

Correct.  

Paul Holland (23:23.244)

As you mentioned, there are very often fringe technologies, surround technologies on the mainframe around the applications where refactoring them just may not make good sense. And indeed, you and I had a conversation earlier last week about Assembler. Yes, we do a great job at converting Assembler.  

Paul Holland (23:48.676)

But there are some pieces of assembler that exist on the mainframe that really don't need to do that kind of function when they're moved across to the cloud. And, you know, there may be existing capabilities in the new cloud architecture that already cover those type of functions. So making sure you're planning out a mapping to the right pattern is very important.  

Chad Jones (24:14.205)

Yeah.  

Walter Sweat (24:14.286)

You said a magic  

Walter Sweat (24:15.479)

word, I think, right there with mappings. That's one of the things that I personally have seen when projects aren't successful in this space. Where I've seen them fail the most often is where organizations think, if I convert code and data, voila, I'm done. I think you have to have 100 % mapping on the front end where you decide the resolution for every component that exists on the mainframe. Sometimes it's not necessary.  

Paul Holland (24:40.858)

Yes.  

Walter Sweat (24:43.274)

Sometimes you refactor it, sometimes you replace it with a third-party alternative, but you can't ignore any piece and expect to have a completely successful migration. So I absolutely agree with you about that mapping, Paul.  

Paul Holland (24:58.638)

Yeah, think you've complete-ness of solution is always in mind, but even back when we were doing re -platforming, it was the same issue. You must have a mapping for every component that you're looking at in the application portfolio.  

Walter Sweat (25:13.152)

Absolutely. Chad, I'd be interested to know your insights. How do you recommend a company start their mainframe to cloud journey? What are the magic things that they always want to consider?  

Chad Jones (25:27.687)

Yeah. So I think we just touched on some of that a few minutes ago. And it really starts with partnering with a company like Astadia, who has experience working with customers and taking them to the finish line in successful projects. We work with IT executives all the time who are working on their first mainframe to cloud migration. Maybe they've done two.  

Chad Jones (25:57.723)

If we run into somebody who has a ton of experience, they've possibly done three. We've worked on hundreds of them. So we've been through all of the bumps and the bruises that come from these projects, and there are bumps and bruises. And we follow a methodology that allows us to get to proven, repeatable, and predictable results in a project. So partnering with someone who has experience and tools is  

Chad Jones (26:27.471)

Number one. Number two, going back to proper planning. Once you find the right partner, it's working on that planning and that discovery and that assessment phase before you dive into any particular project. If you're looking at a portfolio with dozens or hundreds of applications, it's determining what the right disposition strategy is by application or by workload. As we've already mentioned several times before,  

Chad Jones (26:55.947)

Refactoring is not the right solution for every particular application. You may have an application that's just no longer meeting the needs of the business. It really needs to be rewritten or reimagined in a rewrite, maybe the right pattern in that case. But if an application meets the needs of the business, refactoring is the right pattern in most cases, because it's the balance between how much modernization you're going to get from the project, time, cost, and risk. And there's a...  

Paul Holland (27:19.94)

Okay.  

Chad Jones (27:25.011)

tremendous amount of risk in any pattern that doesn't include leveraging automation. So you want to leverage automation when and where you can. But it's finding the right partner, planning, using the right patterns, and then execution.  

Walter Sweat (27:41.646)

Perfect, thank you. I'd like to ask this next question to both of you, but I'll preface it this way. I think in the last 25 years, every new programming language I've ever learned, by the law it appears, I had to write a Hello World program first. That's just the way we do it. Same thing, any business conversation of late, you can't end the conversation without talking about Gen AI. So this is our point where I'm gonna ask you guys about your thoughts about Gen AI.  

Chad Jones (27:58.739)

you  

Walter Sweat (28:11.155)

And what are your thoughts on the impact on the mainframe modernization market? What have you been seeing happening in the market? And this will be hopefully interesting. If you're not seeing it now, when do you expect the market to start to see benefit, real benefit from Gen AI? Paul, let's start with you if you don't mind.  

Paul Holland (28:35.47)

Yeah, what a a what an enormous subject. Just to finish up on. Yeah, plenty of time. So I personally totally agree with you, Walter. You it is remarkable how our clients, our prospects have.  

Walter Sweat (28:40.558)

And you have 12 seconds go  

Chad Jones (28:48.125)

You  

Paul Holland (29:01.088)

adjusted their conversations and it is literally now I think impossible to have a conversation with a client about modernization without them asking how we would leverage Gen AI, how Gen .ai could play a part in it. And I think part of that is just the vendors in this space have sort of, you know, pushed Gen AI as  

Paul Holland (29:28.2)

something that has a significant impact on modernization and clients have picked up on that and Really started to ride that way now. I have no doubt the generative AI as a concept as in almost every other part of business is going to have a very material and probably You know almost represent a paradigm shift  

Paul Holland (29:57.164)

in the way that modernization is tackled. But today we're not there. And I think that's generally understood. I think it's generally understood at the moment that there is promise in how generative AI can be leveraged, but the reality is slightly different. So for example, when you look at refactoring, you look at code conversion, clearly,  

Paul Holland (30:24.654)

The idea of giving a large language model a COBOL program and saying, just rewrite this as a microservices Java application for me is very tantalizing and probably is realistically in reach. But there are big hurdles at the moment that are preventing that from being the reality.  

Paul Holland (30:50.158)

The reality at the moment is you can give a few paragraphs of COBOL to a large language model and it will do a job of converting that to Java, let's say, but it won't do that in a consistent way. And as I've indicated, it cannot do that at scale, just the token limitations on the models at the moment. And frankly, even as those limitations are increasing,  

Paul Holland (31:19.216)

because everything is costed out based on tokens, it's pretty expensive to convert code that way. So conversion at scale is really best done at the moment using the, if I call them classic type of refactoring tools, for example, that Astadia has, rules -based, can handle literally millions of code at a time and give you 100 % functional equivalence. Gen AI is not there for that now, but.  

Paul Holland (31:48.834)

When is it going to have an impact? It is having an impact now. And what we're seeing is that generative AI has been applied around modernization projects on the sort of edges of the type of classic refactoring that we're doing. And we're doing work in this area. So for example, improving our ability in discovery and  

Paul Holland (32:15.852)

the kind of understanding and output we get from our discovery. adding to that, and you're seeing this quite a lot in the market at the moment, a degree of code explanation and doing that, again, that's difficult to do at scale at the moment. The examples that you're seeing in the market are really, again, snippets of code and telling me what they're doing in English language.  

Paul Holland (32:42.19)

But I think we see an opportunity to do that more at scale and make that part of our discovery process. And the potential to having got to a solid, functionally equivalent end state, which is very much our goal when we're tackling these projects, to start to leverage Gen AI on that next phase that Chad was talking about, which is how do we go from there  

Paul Holland (33:10.0)

to a truly cloud native microservices oriented architecture and maybe using Gen .ai to help with that journey. I think we're gonna see more impact on those type of directions than the pure code conversion at scale. Keep saying that because that's the issue. Over the next two, three years, then we're gonna see on that code conversion.  

Paul Holland (33:39.374)

direction in that same time frame.  

Walter Sweat (33:43.042)

that's  

Walter Sweat (33:43.188)

very helpful. Thank you, Paul. Chad, anything you would like to add to your thoughts on Gen AI and where it is today?  

Chad Jones (33:51.023)

Yeah, so I would add, thinking about it from the perspective of what Gen .ai is doing today or what it will do versus what it's not doing and what it may not ever do. So Paul covered the use cases that Gen .ai is helping support today well. Today, Gen .ai is an accelerator and an enabler for the patterns that already exist. Paul gave examples of  

Chad Jones (34:20.583)

how it's helping and will continue to evolve and help the refactor pattern, for an example. But what I would say is it's also important to talk about what Gen AI is not. Gen AI is not a new pattern. And I think that's kind of the reality that people had to wrap their brain around here over the last year as it relates to mainframe projects is Gen AI came out of nowhere, people are already on these journeys.  

Chad Jones (34:48.583)

Some people decided, hey, let's pump the brakes and figure out what Gen AI is all about. This may be the new latest and greatest thing. And it's not going to be its own R. We're not going from, you know, Gartner's five or seven R's, depending on which version you're looking at, to six or eight R's. It's going to be a technology that helps enable and accelerate the patterns that already exist. I think we're a long ways away from being able to prompt your way through an entire  

Chad Jones (35:16.699)

mainframe migration from start to finish without having other tools like the refactoring tools that we use to do co -conversions and database conversions and migrations that have been in the market for decades and proven and mature. But who knows, maybe technology will surprise me. My guess would be we're years away from seeing it as its own pattern.  

Walter Sweat (35:40.174)

It's been intriguing for me, I know, as we've talked to organizations who came to us originally and said, if you don't have a Gen AI story, I don't want to talk to you. We're 100 % in on this. And then four months later, they came back and said, you know, we're kind of rethinking this. We don't understand all we don't know yet about Gen AI. And I think that's the boat we're all in. I think we're obviously all intrigued by it. I am so anxious to...  

Walter Sweat (36:08.974)

not wish time away, but to see what in five years, Gen AI can do in this space. And certainly in 10 years, what it can do. But today's problems, the solutions that exist, I think it's all working together to find the right combination of solutions for organizations. And the really exciting part is those tools exist and they will only get better and Gen AI will also make it better to give people more.  

Walter Sweat (36:38.082)

more options I feel. And guys, looking at the clock, I hate to say this because I've really enjoyed this so much, but we're unfortunately out of time. I want to thank you both, Chad and Paul, for taking the time to share your thoughts, your experiences, and also to say thanks again for becoming part of the Astadia team. We are a much stronger organization with you and your experiences here now. So really, really looking forward to working with you both.  

Paul Holland (37:09.232)

Thank you, Walter. It's good to be here.  

Chad Jones (37:09.843)

Thanks, Walter.  

Chad Jones (37:10.842)

Appreciate it. Yep.  

Walter Sweat (37:12.675)

Thank you. And to everyone in the audience, thank you once again for taking the time to join our podcast series. I hope this was beneficial and helpful and informative for you. And please keep a lookout on our website for upcoming podcasts as well. We look forward to seeing you again. Thank you all so much and have a great day.