The Linux Foundation Projects
Skip to main content
Blog | I Am A Mainframer

I am a Mainframer: Mark Neft

By | February 17, 2022

In this episode of the “I Am a Mainframer” podcast, Steven Dickens sits down with Mark Neft, CTO, Platform Modernization at EPAM Systems. During their conversation, Mark shares his unique “home remodeling” approach that helps clients figure out what they already have in place in terms of infrastructure. He goes on to talk about the tools and capabilities he’s built to put roadmaps in place that will get them where they want to go with their mainframe.

I am a Mainframer: Mark Neft

Listen Now!



Steven Dickens: Hello and welcome, my name’s Steven Dickens and I’m the host of the “I am a Mainframer” podcast brought to you by the Linux Foundation’s collaborative project, the Open Mainframe Project. I’ve got today a fantastic guest. I’ve got Mark Neft. Hey Mark, welcome to the show.

Mark Neft: Thank you. Thank you.

Steven Dickens: So Mark, let’s dive straight in here. Let’s get our listeners orientated. If you can give us a little bit around your background, what you do for EPAM Systems and really just get the listeners orientated then we’ll dive in from there.

Mark Neft: Yeah. I’m Mark Neft, I’m CTO of Platform Modernization. I work with clients to help them remodel the house while they live in it. So helping clients figure out what they have, use the source code, using their infrastructure, to understand the facts and help them build roadmaps into where they want to go and how to get there while they’re continuing to use it and enhance it from that perspective. So I’ve built a series of tools and other capabilities to understand what’s around the mainframe and become self-sufficient very quickly.

Steven Dickens: And how long have you been with the mainframe platform, Mark? The show’s called “I am a Mainframer” so let’s get that out of the way straight away.

Mark Neft: Well, funny enough, I didn’t start on mainframes. I started on Linux and Unix back in the 80s. So I’ve been doing mainframes since the late 80s, I don’t know 40 years.

Steven Dickens: That counts. That’s enough time to turn up on a podcast and claim you’re a mainframer I think. Just want to take you back to something you mentioned, renovating the house while you live in it. I think the conventional wisdom is rip the house down and start again and build a new house. Just let’s play with that analogy for a moment. Why do you believe it’s the right thing to do to renovate it while you live in it? And I’m not saying it’s not by the way, obviously I’m not, but I’m keen to get your perspective.

Mark Neft: Well, most organizations can’t afford to stop their business and go build a new house and move it. There’s a lot of risk. And what we find is a lot of organizations oversimplify how easy it is to replace what they have and they end up in the worst situation where they build a new system, they get 80% of the functionality moved. Now they have two systems, one that’s supporting 20% of the business that costs the same amount of money, and another one now running in the cloud or wherever that’s supporting 80% of the business. And it costs the same, and it costs a pretty penny to run as well.

Mark Neft: So now you have two systems you have to maintain and deal with all the regulatory instead of one system from that perspective. So that’s what we see a lot of times, is that they oversimplify. And tearing down a house and rebuilding it when you don’t realize, do you want a two story? Do you want a ranch? You want a three bedroom, four bedroom. If you don’t understand that you’re going to end up with Frankenstein very quickly.

Steven Dickens: And it’s interesting you mentioned that 80/20. We often hear that sort of percentage, is that what you are seeing actually in reality? That it’s easy to import the first 80% to something else to replatform onto the cloud or to do something else, but that last 20% is the hard yards and that’s where the project failures happen.

Mark Neft: 80, maybe it’s 90/10, but the last 10 to 20% are the killers. Because a lot of times it’s not the current state and it’s not the future state. It’s that transitional state that everybody underestimates because they lose funding, people get impatient, they want to go faster and so on. There’s a lot of reasons, but the risk is all in that transitional state. When you’re not done with what you have and you’re not ready you to move everything to the new state, you have to be running on all engines and all cylinders when you’re in that transitional state.

Mark Neft: And that’s why we remodel the house when you’re living it, because you focus on plumbing and electrical, you make sure those are going to support when you go. And then you start remodeling the bedrooms and the bathrooms. And if you live in the North East, you do the kitchen in the summer. You understand what pieces to do when, instead of trying to move to a new house, you ever try build a new house and move? That’s a pain in the butt. You get comfortable with what you have.

Steven Dickens: So when you are engaging with clients and they’re looking at this kind of transition ahead of them, they’re looking at what they’re being told by the cloud providers and system integrators of this is a short, fast programmatic shift that we’ve done hundreds of times. What are you saying to those clients who are looking at that and evaluating that journey? What’s the sort of talk track of your experience that you are able to convey?

Mark Neft: My experience is small things are easy to do. Take a step back, the mainframe where it’s very good is lots of little applications that are hitting a common in a shared everything environment. That shared everything is really hard to pull apart. So don’t underestimate. I’m working with a client, they got 40 million lines of code and 8,000 databases, and it’s all tightly cohesive. So yeah, we find these little islands of five databases in 20 programs. They’re easy to pull off. But when you have a database that’s being hit by 37 different COBOL programs that are part of seven different application sub-systems, where do you start?

Steven Dickens: So talk me through that renovation task. Where do you start? How do you get going? Just really sort of frame for me, if you don’t mind the pun, Mark.

Mark Neft: No, I don’t mind. So when you look at renovating, you can get immediate value day one because you can implement a microservices architecture in COBOL that can co-exist with monolithic. So now all of a sudden, all your enhancements and your changes are done in a functional paradigm, and those interfaces are protected and you can design them so they can change, so that if you change a function, you don’t break the ecosystem.

Mark Neft: And what’s pretty cool with the architecture that we do is these interfaces, if somebody’s using an older version it’ll phone home and say, “Hey, this guy’s using an old version.” We’re deprecating it, we’re not going to bend him. We’re going to tell you what module is calling us that’s using the wrong interface, so that the code is protected and it’s we’re future proofing it so that we can change it with backward compatibility, without breaking the ecosystem. And it can coexist with your monolithic. So you get immediate value and you get agility relatively quickly.

Steven Dickens: You’re talking about what I think is object orientated, sort of code module methodologies. You’re talking about microservices. Are you basically there saying regardless of the underlying language, those best practices still can be applied in a main frame environment?

Mark Neft: Yeah. I’m not a big fan of object orient but I use functional programming. So think of it as an old functional programming. I’m a math guy so I think of things in functions in LEGO blocks. And these become LEGO blocks that you can glue together to build new business processes, but they’re designed to be independent of each other.

Steven Dickens: So this is modern programming methodologies applied to a COBOL system. I think what I hear you saying is don’t think that COBOL can’t take you there. It very definitely can. Would that be a fair summary?

Mark Neft: That’s a fair summary.

Steven Dickens: Yeah. Okay. So once you talk on these decision makers through that methodology, talk me through, if you don’t mind, just a little bit about the project, so the classic five to seven year migration off the mainframe, what does the renovation look like when it’s still living in the house to continue to stretch this analogy? What does that renovation timeframe look like and what are the major tasks?

Mark Neft: A lot of it has to do with data cleanup and creating landing zones and funding zones so that you fund to a point of stabilization, so that if you don’t get any more funding or you can’t do any more work, the organization is better off than it was before but you’re not in an unstable. So it’s very important to fund to a zone. Where I look at this is the mainframe becoming an application server. It provides data. It does the business processing. The UI, UX is being serviced by whatever, Angular, React, Unify, whatever you want to do for UI, decoupling that and creating that service entry points so that the mainframe is really an app server and a database server that can support multiple workloads working hand in hand. And that’s where I look at it evolving and working with clients to make that happen.

Steven Dickens: I think that’s really interesting the way you describe it there, fund to a point where the platform’s better. I’m going to continue to stretch our analogy about house renovation. You can go do the kitchen, get the kitchen done, and you haven’t touched the plumbing. You’ve maybe not touched the roof, or you’ve not touched the windows and you haven’t done the upstairs bathroom, but at least the kitchen’s better than when you started. You’ve not undertaken knock it all down and start again, and then you can go back to those other rooms and renovate forward. Is that the right way to think about it as you think about funding to a particular point.

Mark Neft: It is. You could preserve capital. And the other thing is just think about if you have a family of four, do you really want to take that disruption of tearing down the house, going and living in an apartment, the kids are disrupted from the neighbors. All of that is impacting the family while you’re trying to rebuild and figure out what you want, where you’ve done the kitchen now we can sit back and say, “Okay, the kids are going to become teenagers. What do we want to do? How do we want to redo their bedrooms?” We can take the learnings from the first renovation and apply to the next sets.

Steven Dickens: So talk me through some of the, and you probably can’t mention customer names, but just talk me through some of those projects where you’ve taken customers on this journey, what the before state looked like and what the successful end state looked like.

Mark Neft: Yeah. The before state is a lot of spaghetti, it’s a lot of urban legend and nobody understands how it works. Going through the process, we not only create logical maps of how the code and the business are aligned, we’re also creating business process flows of swim lanes and sequenced diagrams so that the code becomes segmented and aligned to the different business groups that are participating. So there’s clear demarcation of who owns what data, separations of duty between… Think about a bank, you could have loans, you could have retail banking, you could have credit cards. Those systems all work together, but they’re separate. The data, the money laundering and all those pieces are pluggable into the architect.

Mark Neft: So then we’ve pulled it apart instead of everything shared. Everything’s still shared but there’s demarcations and there’s managed interfaces between the data and they can now evolve independently of each other. So the journey allows things to become independent. It also allows us with this approach to take advantage more of Linux on systems ZED and the ZED OS. So that now we can optimize for cost as part of the architecture where we can utilize ZED engines. We can take the high availability of DB2 and z/OS.

Mark Neft: Funny enough, you could get a higher availability when you use zLinux going against a sysplex from that perspective than staying within the… But so there’s some advantages architecturally by using the back plane and the different operating systems that are available to be able to get a robust, highly available solution that never has to go down. We’ve had clients that we needed to be able to demonstrate that we could upgrade it and change it at peak without losing any data. So being able to do those, being able to change the hardware without losing any data is part of the advantages of the platform.

Steven Dickens: I can imagine the enterprise architect community, they’re sold on everything that should be on the public cloud, they’re sold on modern languages, they want Ruby on Rails, they want Python. They want to throw the baby out with the bath water and go everything new. You come in with this pragmatic conversation and I’m playing almost devil’s advocate here whilst [disagreeing 00:13:34] with you. So this is an interesting dynamic. I’m having to done the cap of these enterprise optics. How does that conversation go? Let people in the room for a moment, how does the microcosm of that discussion go? Are they open-minded, are they closed minded? How’s that going?

Mark Neft: They’re very difficult. And they become interesting. And a lot of times people are afraid of what they don’t know. And these are guys that grew up, these are young architects. They have great insight to what can be done. They have great use cases of what can be built new in the cloud. The challenge is you have 20 million, 50 million accounts in this platform and you can’t move them, snap your fingers and they’re moved. You have to build that evolution.

Mark Neft: And you can’t take years to go build a new house and then move it. Because if you go build a new house, by the time you build it, some of the things you’ve implemented will be outdated already. Because it’s going to take you one to two to five years to build that new house. And if you’re designing it based on today’s needs, you’re going to be five years behind everybody else by the time that house is finished. [crosstalk 00:14:53]. Good.

Steven Dickens: So you’ve done a fantastic job of painting that out for me Mark, where does EPAM solution sit in? What’s your role in that discussion? Where does your company fit in?

Mark Neft: We help clients do the full digital transformation. So we will help them move things off the mainframe. We’ll help them rebuild, working with some retail banks right now and helping them modernize their pole ball and helping them do the design for change. We have engineers that are excellent and major cloud vendors, they know how to do the Java. It’s not about one or the other, it’s the coexistence in how to build that harmony between the right platforms for the right processes. Because some of the things that we find, and everybody wants to go to real time, but if you’re ever working in banking, you need an ended day process. You have to close the bank and reconcile the bank every night.

Mark Neft: So a real time process is interesting, but that’s not how the business works. It has to have a end day. It has to have these certain checkpoints that validate that you’re not overdrawn, you’re not this or certain legal requirements that the mainframe can handle high volumes of high data. Yes, you can do it in the cloud, but you got to rebuild all there. It’s there today. Let’s just enable it to change it and expand it versus trying to move it off of something.

Steven Dickens: And that’s where EPAM comes in. That’s where you guys fit in. You help people through on that journey?

Mark Neft: Yes.

Steven Dickens: I’m assuming that you interact with the Open Mainframe Project through the COBOL Working Group. Would that be a fair assumption?

Mark Neft: It is. It’s one piece of the puzzle.

Steven Dickens: And where else are you working with the community? What’s your interaction with the Open Mainframe Project?

Mark Neft: We’re doing a lot of work with Zoey. So being able to use Zoe to do all the automation under the covers so that you can use an eclipse based interface or visual studio to do all your DevOps and your development. Now I can take people who understand Visual Studios and maybe Visual Basic or C Sharp. Within two weeks, I can make them comfortable to maintain COBOL programs. Because they understand the IDE and the tooling and the mainframe itself it’s a server of somewhere out there, who cares where it’s.

Steven Dickens: So what’s been your experience with Zoey.

Mark Neft: It’s been great. We’ve been able to automate it and we’ve been able to script and be to do everything on the mainframe without actually having to connect to the mainframe, without having to use a green screen. We don’t use green screens at all. We use scripting and we submit everything through CLI, command-line interface. We do a lot of Python. We do Parson and Python and all that. And we use Zoey to facilitate that.

Steven Dickens: Is that helping in that conversation with the enterprise architect? When you say, “Look, we’re not asking you to become a COBOL experience and sit at a green screen,” does that help break down that barrier, Mark?

Mark Neft: It does a lot. Showing them the tools that are available in the price point of these tools of being zero, compared to some of the tools that they’re spending a lot of money on, it gives them instant savings.

Steven Dickens: And does Zoey surprise them that there’s open source on the mainframe? Because I think it surprises people when I talk about it, is that your experience?

Mark Neft: It is. And there’s also a lot of hesitation between the mainframe operations group and Zoey. We find is because they’re afraid to give up control.

Steven Dickens: Do you think-

Mark Neft: Everything’s magical behind the covers before.

Steven Dickens: Do you think that’s improving with the conformance program and some of the support options that are now available for Zoey, it’s matured to the point where it’s supportable code and something you can call the vendors and get support on? Is that helping do you think?

Mark Neft: I think it’s helping. And I think with a younger group of people coming in who are expecting these things, organizations are having to deal with it. Onesies and twosies they’ll quash them but when large number of people are looking for, “Hey, I can get this everywhere else. I’m going to move off the platform if I can’t do this.” They need to be able to demonstrate from an operations perspective, otherwise they’ll have zero survivorship. Because if they stay to green screens and lock the mainframe down at the development level, people will find a way to get off because they won’t be able to do anything.

Steven Dickens: I think that’s a really interesting perspective. It’s less about Zoey the technology, it’s Zoey the perception that that creates of the platform. I think that’s an interesting dynamic.

Mark Neft: Yeah. It opens it up so that you don’t know whether you’re [inaudible 00:20:05]. The mainframe, the only thing you realize is that it doesn’t use forward slashes or backward slashes for directories, it uses dots. But the only thing you’ve noticed.

Steven Dickens: Yeah. And that’s not a big barrier for all the rest of the benefits that you get for the platform, right?

Mark Neft: Yes. That’s the worst thing you have to worry about on training then everything else is easy.

Steven Dickens: So you mentioned when we’re doing the introduction that you’ve been with the platform coming up on 40 years now, Mark, what advice would you give to your younger self? You’ve built a career, you’re now the CTO of this organization, EPAM Systems. You get the opportunity to go back to your younger self, 22 years old when you’re finishing college, what would you say to yourself? What nuggets of wisdom would you have from the journey that you’d like to impart onto to the younger Mark?

Mark Neft: Trust the science and trust the math. It will work out. And don’t forget the basics that you learned in computer science, right? Watch how it evolves and continue to learn. I did learn a long time ago. Languages are important to tell the computer what to do, if you use them properly, you can get them to dance, you can get your systems to dance.

Steven Dickens: So Mark, what career advice would you give yourself? So you’ve got the opportunity, as we say, here to go back to the 22 year old self, what career advice, we’ve got a lot of younger listeners on the show, what would you be saying to those listeners?

Mark Neft: To the listeners today, study history of computers, understand where and how things have evolved. History has a tendency to repeat itself. Understand why DCE, CORBA, some of these bleeding edge things that were out there 30 years ago, where have they gone and why do we not see them today? The mainframe has been able to withstand all the other onsets, and it is a true to being able a powerhouse of high volume, large data and a consolidated footprint and highly secure. It’s important to understand history and why have things… What technologies have failed and we no longer see and which ones are coming through and how do they compare to things that were out there 30 years ago?

Steven Dickens: I think that’s really great advice. The other question I ask all of our guests here, Mark, is, we’ve just gone down memory lane and we’ve just backwards in time. You now get the chance to go forwards in time and look to the future. Where do you see the platform five years from now?

Mark Neft: I see it going more towards the open systems. I see a ZED OS and ZED Linux becoming more in harmony with each other. And going back to Joe Temple and some of his old papers and fit for purpose, understand what kind of processing you’re doing where, put the right kind of processing on the right type of platform, understand the big picture and what it is you’re trying to accomplish.

Steven Dickens: I think that’s fantastic advice. I think that’s fantastic advice. And I agree with you that’s where I see the platform going forward. Mark, well, this has been a fantastic conversation. I didn’t think we’d spend as much time pulling apart that house as we did, but I think it was a good metaphor for the conversation and a good analogy. So thank you very much for the time on the call today.

Mark Neft: Thank you. And you have a good day.

Steven Dickens: Fantastic. You’ve been listening to Steven Dickens. I’m the host of the I’m a Mainframer podcast. We’ve had Mark Neft, the CTO of EPAM Systems. If you like what you hear today, please click and subscribe. It really helps the algorithm. Give us five star rating, and ideally share this with your friends. You’ve been listening to the I’m a Mainframer podcast, and we’ll speak to you soon. Thanks very much.