John Rhodes and Roger Hammer on Solving Customer IT Challenges
In this sponsored advertising content series, zTalk Business with Reg Harbeck, Reg talks with John Rhodes and Roger Hammer of CM First Group at SHARE in San Jose about their work developing tools for analyzing and documenting legacy applications, and how they help organizations and systems integrators understand their mainframe code and large system code.
Reg: Hi, I'm Reg Harbeck and I'm here today with John Rhodes and Roger Hammer of CM First Group. Welcome John and Roger.
John: Thanks Reg.
Roger: Good to be here.
Reg: So we're going to get to know your company a little bit and see how you fit in the whole mainframe ecosystem and a sense of where you come from and where you're going. John, maybe if I could start with you just telling me about your mainframe journey and how that weaves in with your company and the mainframe.
John: Sure, Reg. I started way back in the day. When I graduated college, I had a computer science degree and I focused on artificial intelligence. I got out in the workforce and joined a consumer products company. They told me that they needed my skills on the mainframe and doing COBOL so I jumped into helping them. At that time, IBM i and PCs had just come out. They were trying to figure out how to fit the mainframe into their ecosystem, so we helped build distributed systems around the mainframe as a core, but pushing things out to where it made the most sense. So that’s how I got started.
Reg: Cool. Now Roger, how did you weave your career into all of this?
Roger: Great question. My background actually is in engineering, and I joined the mainframe space about 15 years ago as a product manager getting involved with products that help people better understand the mainframe code and doing analysis. That is really when I was introduced and got involved, and I’ve been managing products since then.
Reg: So you both have been at CM First since near the beginning when it was founded.
John: That's correct.
Reg: Cool. Can you give me a sense, John, of what role CM First plays in terms of the present and future of the mainframe ecosystem success?
John: Good question. I think where we play a role is — it goes back to my roots (and the roots of the company, really) around doing projects to help people understand their mainframe code and then make it work in a distributed environment. So that type of project is very, very complex and we are an integrator. We had some successes; we had some failures, and I was able to observe some failures. We learned from that and the reason I founded CM First was really to get into providing automated tools so people understand their mainframe code or large system code. I think that is a huge need because these systems are so complex, yet they're so vital. When I was with my consumer products company, every time the order entry system would go down, the CEO gets on the phone saying, “Hey, we're losing millions of dollars per hour. When are you going to fix this?” So it's a really vital system, yet it's incredibly complex.
Reg: Now you mentioned doing code on and off the mainframe, but my impression is that there is a lot of stuff you actually enabled people to do better on the mainframe, perhaps using what you have off the mainframe. How do you see a proper balance of on and off the mainframe code and development environments?
John: Well, I think that's different for every customer, really, to make his or her own decision. We provide tools to help them do what they need to do, so we provide tools that basically analyze the COBOL code and all the surrounding technology and put it into a big data database. They can then go in and query and make some decisions about whether this component should go here, or this component should be on the Cloud, or another component should remain on the mainframe. So really we enhance the customer’s ability to do that.
Reg: Now your product: I understand you have a fair amount that runs that in a graphical environment off of the mainframe and allows people to see things that aren't there, one way of putting it. How would you put that?
John: Yes, there is no way that a human can grasp the complexity of some of these systems. I was talking to a person here at SHARE who had COBOL programs with over one million lines of code; each program and some of these shops have 20,000-30,000 compilation units. It is just a massive scale that no human can really understand, so you really need a machine to help you, to assist the analyst, to assist the architect, so we provide that type of tooling. We take the code and put it into a big data database. It can then be queried and understood by folks like architects.
Reg: So my understanding is you are not just doing an enumeration of the code. You are actually doing something that could almost be characterized as understanding the code for the user so that they can go in and look at that code, the variables and everything that opens it up to them in a way that just looking at the text doesn't. Maybe if you —
John: Yes, that absolutely right. Maybe Roger, you could —
Roger: Sure. The whole concept of automated analysis is the idea of building models right and working with models rather than scanning and reading code, as John said. Millions of lines of code are extremely difficult to impossible for a human to understand. But when you can boil it down to some diagrams and scoping opportunities in a view, then you can drill down on specific aspects of the system and begin to understand how all of the pieces fit together. You can focus in on those elements that an individual might be working on day-to-day, or for a larger project, and modernization understanding the full scope of the system, and as John said, where you want to move things. It’s about how you want to modernize different elements on or off the mainframe.
Reg: So you can use your product to figure out which parts of an application belong on a mainframe, which ones should be off the mainframe, and get them working together properly. Now of course the technology is part of it, but it's all about people, isn't it? One of our big challenges I've been talking about for quite a while is the need to get a new generation on the mainframe. I think one of the big problems we’ve got now is that a lot of organizations aren't hiring the new people until the old people have already given notice, so they have zero or almost no mentoring time. How does your product step in and fill that gap?
John: Yes, that's a really good point. I think that a key aspect of our product is that it provides a map of the system that someone who is new the system — who has some training in COBOL but doesn't have any experience with a particular system — can go in and understand the system quickly and not have to pore through lines of code and do a laborious learning process like we did back in the day. It's like a step and a huge accelerator towards learning.
Roger: Yes, I remember back then one of our very first customers was an insurance company and we worked with a small group to bring CM evolveIT into the company. As we did that, we were working with many longtime mainframers — people who had been there 15, 20, 30+ years – and we did in fact engage a few people who were very close to retirement. There was one young lady who was new to the mainframe and actually had come out of the business side and was interested in learning mainframe COBOL. She was just getting started and it was interesting to see through the training process how she really engaged, because she was comfortable with a Windows tool that would help her interact with the code and the visualization was more her style rather than —She wasn't used to all the scanning and reading millions of lines of code to try to figure things out, so she ended up actually being the product owner internally and our champion after about a year. She really engaged and took over.
Reg: Excellent.
Roger: And helped push that forward.
Reg: Well that's really neat. Now looking at that and at the future of the mainframe from the perspective of working with these organizations, maybe I can get some thoughts from each of you about where the mainframe ecosystem is going in terms of the code, the applications, the people and how you are going to play into moving forward. Let's start with you, John.
John: Well, I think it was interesting listening to some of the sessions today, like the keynote. They were saying that 90% of folks who have mainframes see that as the future for their organization, so obviously it is not going away anytime soon. I think though that the speed of development is accelerating, and we need tools to make things more efficient. That's what we want to help folks do and help them move forward in their organizations and their technologies.
Reg: And so just continuing to get higher business value and relevance.
John: Absolutely, yes.
Reg: And Roger especially since we are here at SHARE, you have had a chance to see how all this stuff fits together. Any thoughts you have on where it's going?
Roger: Yes, I think that DevOps is obviously key and we are hearing it everywhere in a lot of different presentations. The way that you integrate your development system and make people more efficient in their day-to-day activities is getting the mainframe to the point of the speed of the off mainframe kinds of systems. As they talked earlier, CIO's many times might make decisions to build in distributed systems just because they believe that it's faster (and their experience is that it is faster). So as we integrate more of these automated tools into mainframe processes, we begin to see mainframe organizations become even more relevant. They're already relevant, although people don't understand that perhaps because they are in the back doing all the transaction processing. But they become more relevant to all the mobile and web interfaces — and all those things that companies are really building — that people don't even know are connected to the mainframe, so giving them the opportunity to speed the analysis so that they can build more functionality faster is really the goal.
Reg: Cool. Okay, well in the last couple of seconds I'll just get some closing thoughts. I'll start with you, Roger, any additional thoughts you would like to finish up with?
Roger: Sure, I think your point about bringing along another generation of mainframers is really important. My thought about that is I’ve actually got a graduate student who is beginning to work for me. She had a choice of tracks and she decided to move into COBOL. As she did that, her reasoning was that there is a lot more available space there. There is opportunity, and I think a lot of the young folks need to understand that there is opportunity. With tools like CM evolveIT providing a Windows interface and the ability to really interact in a way they're comfortable with, it brings that new generation in.
Reg: Cool, thanks Roger. John, I'll give you the last word.
John: I was just going to point out that as the digital economy goes forward and there is just more and more code being created, it is increasingly important to have automation and tools like CM evolveIT that help with that automation. People just can't possibly keep up with it. So that's why I look forward to helping with that aspect.
Reg: Excellent. Well thank you both very much. This has been really interesting and informative. I really appreciate you taking the time to have this conversation.
John: Thank you, Reg.
Roger: Thanks.