Episode #5: Prison Break: Finding freedom from CA Gen lock in

Prison break: Finding freedom from CA Gen

Rob 0:09

Good day everyone. Thank you so much for joining us today. I have John Regan Head of Development, Central Services at Advanced with me to talk to you guys about CA Gen modernization - a big topic, especially of late. John has over 25 years’ worth of experience in application modernization. He's been on the front lines with CA Gen projects, as well as many others, has a lot of great opinions and a lot of great experience that can help you guys figure out the right path for your very bespoke situation when it comes to mainframe modernization and good old CA Gen.

Rob 0:46

So recently, we finished a survey of a bunch of global heads of IT and key stakeholders that we do every year we call it the mainframe modernization business barometer report. Nice short title, easy to remember. And a lot of the answers this year were really fascinating 90% of companies that we surveyed, which is a representation of users of mainframes across the globe, reported that they started or finished a modernization project within the past three years. Sounds about right. But only 10% reported that they had ever done a modernization project that focused on mainframe workloads before that time. I found that super fascinating. The biggest problem that they all share, although they come from different places is finding the right IT talent in a shrinking talent pool of people. So as most of us that are sitting on this, this webinar knows, people that are capable of understanding, maintaining, and extending the mainframe, and its applications and databases, etc, are reaching retirement age. And they're starting to retire. And so, there is nobody coming to fill behind them. universities aren't teaching procedural code bases, or, you know, application development environments, like CA Gen to new entrants, new entrants aren't interested in this stuff they're interested in in modern development practices and paradigms. And when people talk about their concerns over finding the right talent, most of those companies are talking about their COBOL estates. So unsurprisingly, our respondent’s said COBOL is the most popular language that we use in our estate, when it comes to things like CA Gen, which are far more obscure than COBOL, 25% of respondents said, hey, yeah, CA Gen is our is our most prominent language / development environment that we use, and the talent squeeze in within that subgroup of people was being felt more. So, we know, based on the survey, based on the experience that we've had in the market, and, you know, based on the stuff that John is going to talk about today, that getting away from CA Gen and into a modern environment, or at least away from the confines of it is a big priority for folks.

John, thank you for joining me.

Rob 3:27

First, tell us a little bit about yourself, what kind of experience do you have in legacy modernization, and you know, CA Gen in particular?

John

Okay, yeah. Thanks, Rob. So yeah, as you said, I've got many years’ experiences in application modernization really, having worked on must be 30-40, different application modernization projects. So, a lot of those are CA Gen and a lot of those technologies, a whole mix of technologies quite often.

John 3:55

I've seen it all really. So, from different levels as well. So, I've been a technical person, project management, you know, overall management of delivery resources, all kinds of perspective. There's a lot of commonalities between all those projects. Everybody thinks they're unique, but there's a lot of commonalities between the challenges that people face.

Rob 4:23

That's very interesting. And I want to dig a little bit deeper into that in a couple of minutes. When it comes to CA Gen it is a very interesting beast. This application development environment is less of a language and more of a of an environment and there's some downstream impacts of the way that it operates. That makes it a special case when we're considering modernization. Can you talk a little bit about the characteristics that makes the CA Gen unique?

John 5:00

So, CA Gen is a CASE tool, was popular back in the late 80s, early 90s, so Computer Aided system systems engineering. So, tools to help you write applications more quickly. So, the idea was that business users believe it or not, could write applications. Because the code, the language was very simple, much more English like than even COBOL. And that they were about to produce, especially in the case of CA Gen, or if it was back then before it became called Gen, and then became CA Gen, great business applications, client server business applications, so applications with a flat factory client. So, all the functionality you expect from a factory client, you know, checkboxes, radio buttons, combo boxes, all that kind of stuff, running against data on the mainframe, so that's really what the tool was, was designed for. And it was a very popular thing. Lots of people use CASE tools to build some very major applications that run their businesses, you know, some people, you know, have used it for all their applications, which runs their entire site.

John 6:02

So, it’s unique because it's not just a mainframe thing. There's a whole client portion to it. So, it's not just, purely a mainframe thing. But obviously, it was all designed around using the mainframe as a server.

Rob 6:19

Yeah, very interesting. And, you know, once the development process is completed, generates COBOL that runs in the background, which is interesting. Is there, you know, you talked a little bit about popularity in the 80s and 90s, is there a demographic of companies that was drawn to adopt CA Gen that stands out off the top of your head.

John 6:45

It tends to be larger companies. So, it tended not to be because it was quite an expensive tool to buy, and to license. And it has always been quite expensive to license. So that hasn't changed. So, you know, people, we know, it didn't tend to be small companies. So, it tended to be where people were doing a big new development, they want a good, you know, a client server kind of system, they didn't want to get involved in the nuts and bolts of how the internals of that app to work and stuff, you know, something, they want this thing to do it for them. They want them to do it with some, some lower skilled, you know, not expert programmers, you know, so that's where so those can. So, a lot of companies bought it in that time when wrote big systems.

Rob

And it makes sense. And although it's powerful, and I know we've touched on the talent pool situation, can you provide a little bit more insight into why most folks is choosing to modernize at this stage when it comes to CA Gen.

John

It comes back to what you said earlier, Rob, so that I'd say the number one thing with CA Gen is the shrinking pool of resources. So, over the years, as people have, you know, either decommissioned the systems, I wrote in CA Gen or migrated them away or written new, gradually, the use of CA Gen has minimized across the whole market. So, there are less experts. And it's not something that people learn now, you know, so the average age of a CA Gen developers getting older and older. And if you can't deal with that the cost of CA Gen itself, you know, obviously now that's Broadcom, so Broadcom, a takeover CA and now, you know, got a different very different kind of licensing policy than, say, the past, which produces a much higher cost and the cost of the mainframe in general, then all of a sudden, you've got a perfect storm of increased costs, from the lack of shrinking pool of developers and increased costs from the operating environment itself.

Rob 8:42

Yeah, that's quite the combination.

Rob 8:46

When it comes to modernization, discussions, you know, I know, a few years back, conversations were very different, we would step into a prospect, and they would be looking for a lot of guidance as to what to do from a target environment and process perspective. And it seems broadly speaking, as though, folks know a lot more about what they want to get from their modernizations today than they did in the past. When you sit down with folks who have CA Gen, and you're having these discovery discussions to try and figure out kind of what they're looking at, do you find that they typically know how they want to get from point A to point B?

Rob 9:29

Or are they looking for insight into that? You know, what kind of questions do they have? Where are the blank spots? I guess?

John 9:37

Well, it’s interesting, because CA Gen generates COBOL on the mainframe people think that it’s a good idea to move to a COBOL based solution. But the CA Gen language itself, is not very COBOL orientated, which is why if you ever look at some CA Gen generated COBOL it’s horrible. You know, there's 15-20 lines for every line of CA Gen in the generated program. So, it fits much better into a Java or C# kind of paradigm, that's what you get, you get much cleaner code, it looks much more like the original CA Gen. And it behaves better, it performs better. So that's something we that people don't necessarily grasp. First, because they feel like it's a mainframe thing, they feel like COBOL was, you know, the way to go. The other problem as well with thinking to go to cope is of course, there's not a lot of resources for that either. So, whereas if you go to Java or C#, you're in a much better place. Obviously, on the data side, it's much better because CA Gen customers are already in a relational database, you know, they're already got their data in DB2. So, it's much easier to migrate that data to zero SQL or Oracle, or SQL Server or D2T, off the mainframe.

So people, people have some ideas, but quite often, we have some discussions about how to how to move forwards, because, you know, they want to keep their keep a decent level of maintainability of the applications, because typically, these things are not applications that are going to retire anytime soon in their applications that they rely on to run their business, they're going to be around for another 15-20 years. So, they're going to need to maintain them, then it's a much, much better prospect to move to a to a Java or C# type environment.

Rob

Yeah, that makes perfect sense. Do you feel like there's a common shared concern among folks that are looking to modernize? Is there a challenge or a gotcha situation that, you know, raises the cackles that needs to be addressed early? When, behind the scenes?

John: 11:49

Yeah, I mean, for any company embarking on a modernization, it's a call from a trip into the unknown, because they're used to doing it projects all the time. But those IT projects are to affect change. So, they're to make an application do something he didn't already do, or build a new application or whatever, you know, when you embark on a modernization project is the exact opposite. You're trying to make the migrate application do the same as the old one. So, it's, it's a different paradigm in terms of testing in terms of thinking about it in terms of behaviors. And it's not something that most other places have done, you know, on a big scale before, you know, certainly on a mainframe side, as you said earlier. So that is the biggest, scariest thing, I think, for people is how to do that. I would say the second one is the knowledge because obviously, whilst there aren't many CA Gen developers, they typically tend to be experts in the business that the application serves, just because of the years of experience. And that's a worry, because obviously, if you move to say Java or C#, then how are you going to maintain that experience. But we found that what really works well, for the customers after a migration is a blended team. So, a team of original CA Gen developers who learn Java or C# so that they can understand that there's the source, and working alongside new people who didn't know anything about CA Gen, and, but know a lot about C# or Java. And then they those teams tend to work well together and productively.

Rob

Yeah, and it's interesting, because survey respondents from the survey that I was talking about, that we conducted earlier repeated, that the most successful post modernization strategy that they had was blending the team to make sure that, you know, everybody could contribute. And it was it was good for the existing resources. And it was good for the new folks on the team as well.

Rob: 13:44

When it comes to modernizing CA Gen, in your opinion, what are the most viable options? You talked about Java and C# and object orientation based on you know, the application development system? Can you dig into that a little bit deeper?

John

The beauty of the Java and C# is that you can build from the CA Gen encyclopedia itself, what we've effectively got is a generator that generates minor maintainable, performant readable Java and C#. So, we don't deal with the generated code. We're looking back at the Encyclopedia itself. So, the original definitions of the application, which produces much cleaner, much more readable, much easier to understand code. But it's not just all about the CA Gen. So, a CA Gen application always has external actual blocks to do stuff that you can't do in CA Gen, which is quite a lot of things. So, you need a strategy for handling those two. So, we've got a good strategy for migrating those to Java or C# and fully integrated with the with the CA Gen approach. And then if there's batch which there always is, then we've got to absorb some solutions for the JCL to how to angle that side of the house too. So, it all needs to join up, it's no good just thinking about these things in isolation, you need a strategy that takes care of all the parts that you need to take on.

Rob: 15:13

Yeah, and I think that's also where having a trusted partner, whether that's internal or external, who has been through a modernization process like this before, who has experience and expertise in the area, because there are tendrils all over the place that you don't consider until you get into the weeds and, and it can become a lot bigger of a beast than you thought, without the right, without the right steady hand behind the process.

Rob: 15:41

On that note, a lot of people who are attending today's session are considering legacy modernization for the very first time, as somebody who's been through this on the battlefield quite a few times, you don't flinch when the bombs drop, what advice could you give, regarding vendor selection for CA Gen modernization? And just generally for folks?

John

I think it's important to pick a vendor who's going to work well with your culture, and the way that you operate. So different companies have quite different ideas about how they want to do IT projects and how they want to work. So, you need to pick someone who's going to fit in to that kind of approach, you need to think carefully about how the parts of the project that are not done by a migration technology vendor are going to be done.

So, for example, someone needs to test the converted system to make sure it's good, or you're going to do that you're going to get a systems integrator involved to do that, you know, obviously, there's a lot of cost involved in maybe getting a systems integrator involved. So quite often it can work out cheaper to go direct, but then the systems integrator can pick up a lot of other, you know, integration work around the project, and you know, help with that. So that's a big a big decision to make, and a big, big financial and responsibility kind of decision that people need to think about. But then it's about proven track record. So, you need to understand, what type of projects people have done in the past, what's worked, what's been successful, asked to talk to some of the least one of their previous customers to get a feeling for not only how the migration went, but how it is after the migration, because both of those things are important. It's not just about the journey, it's about the end destination, too. So that's, that would be my key advice, really get to talk to some people, because they've been through what you're thinking of going through. So, they can probably give you some quite good advice in general, not just about one vendor, maybe they can give you some overall, you know, their experience of their selection, decide how they decide who to choose, and then how it went and what was good and what was bad, you know?

Rob

Yeah, that's great advice. And it's very easy to simplify the process in slide wear, but in the end, it really is a journey, and who you go on that journey with is a huge deal. Okay, so I'm going to put you on the spot a little bit. If you're CA Gen user, and you're looking to modernize, what is the one question that you would absolutely need to ask to any vendor that you're that you're trying to qualify?

John

How do you produce some modern code from the from my CA Gen application? Because if they don't say they make out of the Encyclopedia, you're not going to end up with very good code. It's got to come from the original definitions that the definitions that your developers made to have the application if it's coming from some generated stuff that CA Gen have generated. That's not going to be good.

Rob: 18:53

That is excellent advice. A little further on that we discussed the journey can you give us, and I know it's different for everyone. But you mentioned that there's always connected tissues between projects. Can you talk a little bit about a day in the life what is the modernization experience look like? At least from advanced perspective?

John

Yeah, this is, this is a good one, Rob. So going on a modernization journey isn't something that happens to you. It's not like someone turns up, and they just do stuff, you don't do anything. And then it's all done. That isn't how it rolls. I consider it more like going on a plane journey. So, you know, the modernization vendor someone like us, there's laying on the plane. Yeah, but that's not going to have a lot of success if you're relying on them for everything. You've got to find the airport. You've got to check your bag and you've got to find that gate you know, know is that want to help you do any of that stuff. You've got to get on the right airplane. And then when you get on the plane, people ask you questions, chicken, or fish. What drink what would you like to drink? You know, they asked you questions, and you need to answer, you know, because those answers are going to be important, and they're going to make a difference to the project. So, it's something, it's more like that it's a collaborative event, you know, it's not something that happens to you, it's like it happens along, you know, with your cooperation and your input. So that's, if people think somehow, it's all going to just be like getting your kitchen done, or, like, you're just going to get some guy in, and he's just going to do it all and go away again. I mean, even that's not like that, you know, they're going to ask you what dishwasher you want, and what fridge you want, and all that it's, you know, there's decisions to be made. And there's discussions to be had.

Rob: 20:38

Yeah, yeah, that's very good insight, because that can be lost sometimes in, you know, reading collateral and trying to get a high-level picture thing. So that's, that's awesome. And then after the project is complete, what can people expect are generally of course.

John

Well, it's quite interesting. Because obviously when a project is over, we're done. You know. So, you know, we don't always really know what happens. But I've made over the years, I've made quite a big attempt to keep in touch with some of our ex-customers, just to see how they get on really.

And, yeah, it's interesting. So just talking about one bunch of guys, I'm just picking from a CA Gen customer.

John: 21:21

So, they've, they were quite concerned about performance before they went live. And there was a whole big game that made on checking on performance and stuff. But, the new modern environment, in production, everything goes much quicker. So, so the performance is not an issue at all. And the most interesting thing that they found is they used to get on the mainframe, they used to get random crashes, you know, every night, something would crash and then needs to be fixed. And they never really got to the bottom of what it was. And, you know, this, this would just happen, someone had to be on call to fix it in the middle of the night. Nothing goes wrong anymore. But in the modern environment. And, and that's because the act of modernization has caused some of the underlying things that the mainframe lets you get away with, and that you do, which it does its best to carry on those the sorts of things that we faced and dealt with. So, they've found that they don't really get called in the night anymore at all. That just works. And they've found that the support of the system is now much better, they can get a much cheaper resources, to supplement the team and to work with the original CA Gen developers who have enjoyed the experience of learning. They went to Java. Yeah, so they've enjoyed the experience of learning the job. And they, they, you know, they feel like they're as productive as they were in CA Gen, because one of the big things about CA Gen is a very productive environment for developing apps. Now, they've got to grips with the Eclipse and you know, the Java world, and some of the debugging tools and stuff that's available, which is a lot better than they ever had in CA Gen, when they suddenly feel like they're equally as productive.

John: 22:58

And, you know, so that was, you know, that's the main thing afterwards, they've got where they wanted to go, they had high expectations of result. And what's interesting about this customer is the guy I talked to now, he wasn't involved in the project, he was the guy who kept the lights on with the system while the project was going on. So, he inherited the results of that project. So, as you can imagine, he was he feared what he was going to get, he was like, oh, my God, what are these people done? But he was surprised how good it's been. You know, that's not untypical.

Rob

Right. Yeah, of course. And that's what you know, that's what you want to shoot for? For sure. I know, we're getting to the end of our time here. Is there anything that that we haven't covered today that you think we should mention, for the folks on the call? Before we look at questions?

John

Yeah, I'd say one of the key one of the key things for people to think about is the scope of what they're asking to migrate. Because whenever you talk to someone like us, migration vendor, they're going to give you a price based on how much stuff you've got. So, if you go and tell them, you've got a whole bunch of stuff, and a lot of that stuff, you don't need to migrate and you could have got rid of, then you want to have to think about doing that first.

John: 24:23

Exactly like when the removal man comes to your house, and you say I want to move next week, next month, you know, can you give me a price to move all my stuff, and they look around your house and it's absolutely full of stuff, they're going to give you a much higher price than if you've tied it up first and got rid of the rubbish, you know, so exactly the same thing. You know, you want to think about what you've got, and we can help people tidy up, you know, we do separate activities where they just want to tidy up, they don't want to modernize yet, but they feel like they might later or whatever, they just want to tidy up their house. So, we do you know, assessment type activities to help people do that, but that's a key thing that I think people don't. They, once they get into it a bit, they wish they tidied it up a bit like, you know, when you move to your new house and all your rubbish turns up, you wish you chucked it away before you moved, I hadn't paid to move a load of old rubbish that they were going to chuck away exactly the same sort of scenario, you know, it's much better to tidy up before you move if you can.

Rob

That's fantastic advice. And it's funny, because, you know, by looking at this data, it has always shocked me how much footprint reduction comes from these assessment activities. There really is a lot of, you know, technical debt and rubbish, idiotic issues.

John

No one ever delete anything. So, if someone has a program to fix a problem, you know, in production that ran once, 10 years ago, it's still now no one will ever delete that program. Because one, people are scared that they might say the wrong thing. And so, who knows, in another 10 years, we'll need it again. So, no one ever gets rid of anything.

So, there's a whole bunch of stuff out there, that people, you know, when they initially count how much stuff they've got all think, you know, that's part of the scope. But, when they think about it, they don't want to migrate that thing. They don't want to try and test it. They don't want to have it, you know, it was a one off, it's not going to never going to be used again. Or it's been made redundant by some new functionality that's been built, you know?

Rob

Yeah. Makes perfect sense. Cool. Well, thank you so much for your time. We do have a couple of questions in here, a lot of this stuff. And I've been reading the chat. A lot of this is stuff that we covered further down the line. But the one, the one that sticks out to me is data, can you talk a little bit about how we handle data, or how I guess you suggest, data is handled, I know, you mentioned that DB2 tends to almost exclusively be the home of data that's paired with CA Gen, how's that usually worked through?

John

Well, a lot of people already replicate their data to something else. A lot of CA Gen customers already have a data warehouse in Oracle or SQL Server or something where they replicate the CA Gen agenda, the data that's in the CA Gen apps, and DB2. So, you know, what's wrong with that, you know, just expand that out to cover the whole scope of all the data. And you know, you're in business, I mean, in terms of migrating that data, because it's relational to relational, it's in general, straightforward. There are subtle differences between all the date over the relational databases, some not so subtle, some that can cause some quite major, major issues. So, we're experienced all those, you know, we've migrated people from DB2 to Oracle DB2 to SQL Server or zero SQL. So, but in general, the database vendors, you know, the new database vendors have tools to help with that process. So, we would try and use their tools as much as possible to do that work. Because why not? You know, they're built for that job.

John: 28:00

Yeah. So that's, that's, that would be my advice on the data side. Obviously, you got files as well, you know, in batch and stuff we've got, we've got some tools to migrate files, because obviously, if they contain a mixture of text and decimal and binary data, then they'll need to do some special handling. But yeah, we've got some tools to help with that sort of thing.

Rob: 28:25

Awesome. Thank you. That's, that's fantastic. That wraps it up for us. Like I said, I know we were hitting the edge of our time. I'd like to thank everybody for joining us today. This was an insightful conversation. John, thank you for your time again. If you'd like to know a little bit more about how Advanced modernizes CA Gen check out modernsystems.oneadvanced.com. And there's lots of data there for you and we're happy to jump on a call and have a conversation with you about your specific situation. Thanks so much, everyone.