These Are the Mainframe’s Good Old Days: Mark Schettenhelm on IT Social Hour
Mark Schettenhelm, principal product manager at BMC, explains how mindsets on the platform are changing and why the mainframe is currently basking in a "golden age"
Click here to listen to the audio-only version.
The following transcript has been edited for clarity:
Andy Wig:
Hello everyone and welcome to another edition of IT Social Hour. I’m Andy Wig, senior editor at Tech Channel. And today we’re addressing a question that keeps coming up if you pay attention to the mainframe ecosystem, and that is why do people keep talking about moving off the mainframe? Mark Schettenhelm of BMC has given a lot of thought to this question, which he covers in the TechChannel article, “The Nines Don’t Lie—but They’re Not Telling The Whole Truth.” So go check that out if you want a little bit more context. But Mark is our guest today for IT Social Hour, and we’re going to get into that question. So Mark, why don’t you tell us a little bit about what you do at BMC?
Mark Schettenhelm:
Sure. I’m a principal product manager working in the mainframe space with our DevEx products, specifically Code Pipeline, which is our SCM tool that also does build and deploy. But over the years I worked with the former Compuware tools, so the File-AID, Abend-AID, all that. So I definitely have decades of mainframe development experience.
Wig:
All right. You’re a tried and true veteran mainframer, it sounds like. So good person to get into this. You’ve seen the evolution of the platform and maybe let’s just start off with that question. I mean, why do we keep hearing people talk about moving off the mainframe? And I know you’ve said before it’s not the platform that’s tje problem, so maybe that’s a good place to start, but high level, what’s going on?
Schettenhelm:
Big question. Yeah, this has been going on for decades. I remember back in the ’90s it was we can get off the mainframe and that’s how we’re going to solve Y2K, because we won’t have a mainframe. And then after we got through Y2K it was, oh, we’ve got some other thing we’re going to now move off. And it’s been decades and decades and some things have moved off, but I think people look at it and say the mainframe is one big number because you have one big box and not a whole bunch of little distributed boxes. So it seems like a very big expense and they don’t count in what it does.
That’s a big part. And I also think it’s attitudes, and you want to get into what is it that’s really driving the frustration with the mainframe. And mainframers are very complex, the people, because they brag about how many nines they have in uptime and how fabulous and how secure it is—it’s the most fabulous platform and they’re absolutely right. The platform is modern and can do all those things. The problem comes when the organization wants to do something new and you get this great thing, we’re going to take over the market with this great idea and we’re going to jump in and do it. And they go to the distributed teams and they’re like, “Yes, we’re going to do this. ” And they go to the mainframe team and what do they say Andy? They say, “Well, it will take me time. I have to think about it.” And they’re really afraid to change anything because they hold so precious their reliability and they think if they change anything it will affect the reliability, And they stop progress.
Wig:
Does that mean embracing risk more or maybe that’s not the right word you’re going for, but what does that mean?
Schettenhelm:
I wouldn’t say embrace, but I have comfort—be comfortable with risk. And I think one of the things I said in the article is that the number of nines you have doesn’t matter if the application really doesn’t do anything or serve anyone. And so they keep saying, if you keep saying, “I can’t change it and that way I’ll preserve it. ” You’re not preserving the application, you’re not preserving the mainframe platform, you’re really on a path to extinction because things have to change. They change all the time. That’s why I joined this profession, because I love it that every six months it’s totally different. And it changes all the time. I find that exciting.
So yeah, you have to, I don’t know about embrace the risk but get comfortable with it and realize it is risky, but there are ways you can go in and control that risk and that’s using more modern practices.
Wig:
I think the dynamics in IT department, I mean, it sounds interesting. You’ve got the distributed side of things and then you’ve got the mainframers and they’re kind of at two different paces it sounds like maybe. And the mainframers are kind of going like, “Whoa, whoa, whoa, hold on. ” So what does the rest of the department, what do they think when the mainframers are being like, “Oh, put on the brakes.” How do those conversations go? What’s that dynamic like?
Schettenhelm:
Well, I’m not invited to all those conversations, but the way I picture it is, yeah, it is a case of we’ve got this exciting thing and instead of taking that and going, “Hmm, wow, it’s a big ask. Let me think about it.” The mainframers quite often are lead with no and then it becomes, how can I get this for the organization because the organization needs it, and you end up working around the mainframe and the more you work around them, then it’s like, why do we even have this mainframe? So it becomes that it’s a dynamic of no. Now, why do they say no? Part of it is identified with risk. The other part is lack of application knowledge, which could be a whole other—I won’t get into all that because that’s another topic, another podcast, but lack of application knowledge they just don’t know. And these things are complex applications. They’re very complex.
So they are rightfully afraid of making a change to them, but that’s your job. Innovation should be your job, and they are afraid to touch it. They don’t understand it. They might be embarrassed to admit they don’t know it. They don’t want people to know they really don’t know their applications. They may not have the testing facilities in place to go and test these things because they were starved for so long with we’re not doing anything for the mainframe because we’re moving off, a lot of the just that whole ability to innovate has been atrophied. So they don’t really think about innovating on the mainframe and exposing things through APIs and new technologies because they were put into a corner of, “We’re going to get rid of you so we’re not doing anything.” Now we’re in a good position of we are doing things and they’re being asked to do them and yet they haven’t innovated in a long time.
So when you don’t innovate, you don’t have pipelines to go and make sure that your code changes are tested automatically, the testing infrastructure, knowledge of your application and then the tools to do that. So that whole infrastructure isn’t there and the knowledge isn’t there and that appetite for risk isn’t there.
Wig:
It’s interesting that I feel like the education effort that’s been happening around this topic, in the past I thought of it’s mainly aimed at people that don’t appreciate the mainframe, non-mainframers, the CIO comes in and he’s got a bias against the mainframe and people are trying to have him see the light. But then I’m also hearing you also need to educate mainframers too as to the potential of their platform. Am I understanding things right there?
Schettenhelm:
Yeah, you are. I mean, that’s a great insight, Andy, because so often we feel that we must educate those who don’t know the mainframe and how wonderful it is. And what we lead with are we’re 99.999, you know five 9s, six 9s of uptime and we’re really secure. We lead with that, which is the platform and all that. We don’t talk about how we can be innovative. We don’t talk about how you can run AI on the mainframe and all the pipelines and all these things. We don’t talk about how a developer could go from working in the distributed realm and move to the mainframe and keep a lot of their same tooling. We don’t talk about how modern our practices are and our applications and how we can fit in. We don’t talk about that. We only talk about how good the platform is. And so they might be open to it and they go, “Wow, that’s great.” And then they go, “Then do something.” And then it becomes, “Oh, it’s really hard.
It’s complex. It’s the mainframe you don’t understand.” And then it’s like ahh, dealing, with these people.
Wig:
And it feels like a conversation, like it feels like it’s a hot topic right now, but it seems like what I’m hearing is it’s been a hot topic for—I mean, this isn’t just about the present day, right? I mean, people have been having this conversation for how long?
Schettenhelm:
Decades.
Wig:
Decades?
This is something that’s been going on, the roots of it were back in the ’90s when the really we got to get off the mainframe really picking up in like ’95 and then picked up pace again after 2000. It comes and goes. It’s old, but I’ve seen in the last year or so, maybe even longer, but you know what? The mainframe’s staying. This whole getting off, it’s saying workloads could go. I think that’s changed and they’re dedicated to the mainframe and so now they’re looking at it and it’s now a time of, okay, now how can we do it? Now they’re looking at us, now we have to do things, what can we do? And so it’s also the new tools. I mean, let me just say I may sound like a downer, but I’ve never been more optimistic about the mainframe. These are the good old days.
This is the golden era because you now have people realize we’re not getting off the mainframe. This is good. It can be modern. And some organizations I work with are taking all the modern approaches and using AI, have automated pipelines. They’re doing all those things and having great success. And others are working as if it were the 80s. And where you find the roots of the let’s move it off the mainframe are in those organizations where they haven’t modernized.
Wig:
The people that are acting like it’s still the 80s, what do you think? Does that just go back to that mindset of just kind of that old fashioned kind of almost being pigeonholed into this thing that’s just there and that people want to get rid of?
Schettenhelm:
All right, you opened the door to another psychological insight, but yeah, I think some of that goes way back to the people who worked on the mainframe in the 60s, 70s, and I saw it in the 80s when I started. Not everybody knew computers. We did and they didn’t. And so we had an attitude of we know it and they don’t and it’s really hard. And so we kind of kept that knowledge to ourselves.
And we made it some people profited off of telling people, like if a department said, “Hey, can you do this? ” They go, “No, no it’s too complex. It’s the mainframe. You don’t understand.” And they got off away with that for a long time because you could just say it’s a computer thing with the mainframe you don’t understand. People go, “Okay.” But then when we got into the 90s and later, people started taking computer classes and knew it. And so you would deal with people that had some knowledge and you couldn’t use that anymore. And so then it got very difficult to pull one over on them and people would start calling you out on it. And so the mainframers, I think some of them still believe in the more complex my application is, the harder it is that’s good for me, where I take the opposite approach of my application should be easy to work with, and good, I reward developers who find it easier to work with than those who tell me how terrible it is and it’s impossible to change and it will take me a month to make that change.
And I would rather have someone who would say, “Yeah, it’s a little complex. It’ll be there. We’ll have to accept some testing, but let’s do it.” So it’s an old attitude that hasn’t quite died off.
Wig:
I suppose that’s one way to ensure some job security is to make—
Schettenhelm:
That’s exactly what it was, 100%. It was job security. A lot of that’s gone just because those people have retired, but it was job security and I think that’s the root of the mainframe and also the way when you develop with cards, it gets into a waterfall type aspect and mainframe, everything was big in the mainframe, big projects, there’s nothing small, there’s nothing agile. And I have to say that those attitudes are changing. I don’t see as much of that and so I’m very hopeful again that the mainframe is poised to really have a rebirth and really, really start to have application practices catch up to the modern platform that it is.
Wig:
Is it just a matter of taking some time? I mean, like some of these AI and automation tools haven’t been around for too long, right? I mean, is that part of it or is this—
Schettenhelm:
Yeah. So if I look past over the past decade, the mainframe was … Well, post Y2K, the mainframe kind of slept, and distributed teams were doing DevOps and Agile and really speeding up. Around 2008, people in the mainframe world started to go, “Huh, what’s going on over there?” And they were dismissive of distributors. Those are just PCs and toys. And so around that time, 2008 into the teams, it got to be, “Wait a minute, we’ve been asleep and they’ve done all this. ” And then we had a period of, “Wow, all the things we said we should do, they’re doing it and have implemented.” Automated testing, code coverage, those were just standard. Those were just—in distributed development teams that would just be normal, but when you look to the mainframe, they never did it because, “Oh, that just sounds like it’d be trouble.” So those practices, I started really around 2015, 2016, really pushing DevOps and using the APIs and Jenkins to align pipelines. That really, really invigorated the mainframe, and the organizations that picked up on those things and started to implement agile development on the mainframe really prospered.
And I think we’re getting to another big bump on that with AI, because AI with the explains can really open up these complex applications to someone new to work with them, and they’ll have confidence to pick them up and do things AI assistance can help you create things like APIs, create test data, test cases. So those that are very proficient with using coding assistants and analysis tools will really start being much faster, just like we had a similar thing before with those that were using the green screen ISPF and those that used Eclipse. Those that used Eclipse could be much faster because of multi-screens and the amount of tools. We see that again with VS code and I think with AI, those developers that use all those tools for the mainframe will vastly outpace a crusty mainframer that sticks with their green screen.
Wig:
Yeah. I mean, just like, I don’t know, a carpenter with power tools is going to be a little bit faster than the guy with the hammer and the band saw or whatever.
Schettenhelm:
Right. They may be able to take that nail, put it there and bam, bash it in and be great. They’re not going to beat a nail gun
Wig:
Yeah, your nail gun. Sometimes you have to put your pride aside and just like use the tools that are available
Schettenhelm:
And they are and the things with AI, it’s going to really make a difference, but it will take some time to ramp up to that and that’s my fear and that’s why I like doing podcasts like this to spread the word that if you are stuck in the 80s or 90s, you’ve got a long way to go to catch up, but this is a good time to catch up, and you can probably skip over some of those other steps you did before and jump right into AI, Agile development practices, set up your pipelines and just start using the tools that are available and it’s a miracle. I mean the things—I talk about what AI can do and developers just have no idea. They’re like, “Wait, it can do that?” I’m like, “Yeah, it can read that and come up with test cases, and better test cases than you because it isn’t just going to do the happy path.”
Wig:
Do these developers get excited or nervous when they see this then? Do they get nervous for their jobs or excited about—
Schettenhelm:
Andy, the word for that is nervous-ited.
Wig:
Okay, that’s a new one for me. All right, nervous-ited.
Schettenhelm:
Yeah, right. They should be. I like to say if I’m not a little nervous, if I don’t feel I’m a little over my head, I’m not doing it right. And I think really good developers should be that way. These things, they’re going to be nervous, but it’s tinged with excitement. And a critical part of this is in managing that. They won’t do it unless management gives them permission to, and I don’t want to say fail, but to be slower. This is a crucial time because if you have a developer that wants to spend time learning AI and coding assistance and working with it, it might slow them down for a few weeks, and that’s okay. It’s an investment. Managers have to realize they have to invest in their developers and invest with these practices because otherwise I’m just going to stick with what I know.
I’ve got that, no one’s complaining. I’m still working on my green screen, I’m really fast, I’m comfortable with it. If I take some time to learn how to work in VS code to set up some REST APIs and web app notifications, they might think I’m just doing some crazy fun little task and it’s not doing stuff for the company and they’ll yell at me, and I will be slower and they may not like it. And so I think developers are afraid to try some of this because maybe someone yelled at them in the past because they tried something new and some managers have to realize that and give them the permission to do it and say, “We’re going to do this. This is going to be better. You’re going to be slower.” That’s okay.
Schettenhelm:
Ai might generate stuff that is bad code. You know what? I’ve seen developers do bad code. That’s why we have code reviews. But try it and keep trying it and you try it this month, okay, try it next month and it might be better. We have to get into that mode that I think mainframers have lost of experimenting and be excited. And we had that in the 80s and 90s some developers it’s never left them, but others just thought that innovation’s gone and I’m dedicated to keeping status quo, everything there can’t go down, and I think that’d be a very boring way to have a career.
Wig:
Yeah, maybe hope nobody even notices you until you just kind of ride it out until you’re done and move on. Yeah.
Schettenhelm:
And they may feel that’s career security, but I don’t think so. I don’t think that’s job security at all. I think I would reward those who are trying, and it might take them a little extra time, but they might hit on things that make a difference for the whole organization.
Wig:
And so you didn’t go down that path of being someone who’s resistant to this change and just wants to hold onto your green screen. I’m just curious how you ended up going this direction and not the other direction. Maybe there’s some, I don’t know, events that influence you or maybe it’s just kind of the way you are. Why are you not the crusty old grayframer?
Schettenhelm:
Yeah, I am a grayframer, but I’m not that crusty. So I think like I said, when I first started programming like in college and it was like exciting to do it. I was just excited by coding and what I could do and make that machine do. And I was always excited by that ability. Stability, yes, applications have to be stable, the applications, the platform, but our practices is if I was just been excited by what’s new. So I think that’s just personality. And then maybe I’ve had good management along the way that’s rewarded that and said, “Go ahead, try those things. This one worked, that one didn’t.” I think it’s kept me in this career all these coming up on 45 years is just having that excitement. So I think it starts with personality, it starts with having a good environment. I do.
Wig:
Were you ever intrigued by the possibilities of distributed computing or whatever shiny new object is out there? Did you ever be like, “All right, I got to get into that. I got to get off the mainframe myself and get into some of this new stuff.” Or you were just dedicated to the platform the whole time it sounds like.
Schettenhelm:
I think part of it was I was working for a lot of it with Compuware, which was a mainframe company. So I was mainframe and didn’t have as many choices, but I think I was part of that crowd that thought of the distributed as those were just toys and this is the mainframe. This is serious because we’re running all the banks and the airlines and the governments. This is serious.
And so I was never really tempted because I always thought I had a good mainframe career and the mainframe was always exciting and there was always new tools that we could use. So that’s kept it exciting. And that brings up a point when, I like talking to students that are in the programs or recent graduates and talk to them about mainframe careers and I said what makes the mainframe exciting is that these are the things that really run the world with all the applications and people use the mainframe all the time and never even realize it. And it’s so important and you can really be that missionary to go in and spread these new exciting practices to the mainframe. Again, I think this is a pivotal, great time to be on the mainframe.
Wig:
So good time to be a youngster just coming out of school maybe mainframe might be a good direction to go?
Schettenhelm:
I think so. I think so. I think why you could look at it two ways. You could say, “Well, the mainframe’s going to die and that if you talk to people that haven’t really changed and didn’t do anything, you get that story.” And in some organizations they are committed to getting out the mainframe and maybe it makes sense for them, maybe it doesn’t. Decisions should never be made based on application practices. It should be a really hard discussion abou—for them for new graduates, I would say yes, you can have a great career and we need you. We need that person. I may have looked at it and said, “Well, we’ve been doing that for 10, 20 years and there’s some reason why and we do it.” We sometimes need people to say, “But why? Why are we doing it that way? Why ?” And then it’s usually when those discussions are held, it’s, “Let’s try it again today.” And so I think new people—and I think that’s really helped the mainframe, all the people who’ve come in who haven’t had the classical mainframe background who moved to the mainframe are the best thing for it, because they ask why.
Wig:
Okay. A couple more questions here for you. I’m curious, getting down to the real fundamentals, which is if I’m a person who doesn’t make my living on the mainframe, I don’t have allegiance to a particular platform, why should I care that the mainframe sticks around, that everybody doesn’t move off the mainframe? Let Like fundamentally or intrinsically, why do we need the mainframe to stick around beyond the fact that we work in this industry?
Schettenhelm:
I think the decision has to be made. It’s a dollar and cents thing. It isn’t, I love the mainframe, it’s great because I love it. I have to say I don’t have a particular love for the mainframe that it’s better. I think it’s really good for some things and not as good for other things. Just like today if you have to ship something, you could ship it with a boat, you can ship it by a train, you could put it on a truck, you could put it on a plane. The plane might be more modern, but do we do everything on the plane? No. We go by what makes sense based on the time it would take for this thing to be shipped and the cost and the location. We have all these factors and that decides what we ship.
And I think if we look at our applications and what we need for the organization, we need to do the same, what is the best usage? Now the mainframe has an advantage in that it’s already been there so tracks have already been laid. So it’s already there, and that probably gives it an edge in a lot of things. It’s a lot easier and cheaper to modernize that application, open it up with rest APIs to do the right testing for scrapping it and starting with something new. Getting rid of a mainframe application that’s working well is like firing an employee that’s been there for 20, 30 years that has all that knowledge, and booting them out. You have no idea what’s in there. So most often it makes sense to keep that application going but modernize it, make it easier to work with and easier so that when they do have that conversation about something that’s going to help the organization and they’re all excited about it and they come to the mainframer, they go, “Yeah, we could do that” and be part of theTeam.
Wig:
Is the mainframe kind of a, is it a victim of its own success in that has been around for so long, running these applications for so long that people kind of don’t see it as this innovation place and just kind of take it for granted?
Schettenhelm:
Yes, that’s a good insight. I think so. I think it goes back to 1964 and for all the historical references, my degree was in history. This computer thing was just a minor. But the IBM mainframe, the 360 was innovative because before that you get a new mainframe, you had to get all new applications. They just didn’t port. Well, starting in that, something that you wrote for the 360 could almost pretty much run today. And so that meant that those applications could go, which meant the explosive growth of the mainframe, because if I’m investing in it, it’s going to stay. And so the applications could stay, and that leads to tech debt. And I think we are a victim of it because we do our jobs so well. We’re running so often that no one really realizes that every time you go and check your bank balance, when you go in and you buy something online and it hits your credit card, that all these things hit a mainframe and we don’t know.
We did such a great job of it, of making it be invisible, that it’s invisible, and people don’t realize it. And that’s again, when I talk to students, I say, “Well, let’s go through your day. Here’s all the times you’ve used the mainframe.” And they had no idea. Most people have no idea how important it is. And so that gets back to discussions of let’s get rid of it. They don’t really realize it. I think mainframers need to sell themselves better, but uptime alone isn’t it? It’s that it is a modern platform, can run all these things and you can do modern development on it.
Wig:
All right. Well, what you were touching on there leads in really well to my last question I had in mind for you, which is just you were getting at it a little bit, but just imagining a world without the mainframe, say whatever, however many years from now, not that it will ever happen, but imagining that world hypothetically, what are you picturing? Are we doing all right as a society or is everything falling apart?
Schettenhelm:
A mainframer, I should say it would be disaster. No, because at the end of the day, it’s all ones and zeros and the IBM Z, it fits in on a rack and it’s just in the room and you can’t pick it out from all the others. So that’s not really different. I think it’s a matter of having the right platform, the right applications for what you need to do. For high volume things that need security, mainframe’s the way to go. Just like today, we ship things by boat, we ship things by rail, we ship things by truck. Those are still … We didn’t get rid of ships. We didn’t get rid of trains. There’s still a purpose for all those where they fit. And I think the mainframe is like that. It will continue into the future because there’s certain things that it really does well and we have an investment in those applications.
Why get rid of them when they’re doing it so well? So no, I don’t envision a world without the mainframe. And if it wasn’t technically running on the mainframe platform, there’s still applications running on computers. And really I’m into development, happens to be mainframe, but I’m into development and that we have to think of ourselves that way rather than the platform we happen to work on.
Wig:
And you continue to try to develop that platform and bring forward these modern features and layers and applications and keeping them moving. So that’s probably a great place to wrap this up. I really appreciate you coming on IT social hour, Mark.
Schettenhelm:
Oh, thank you Andy. I love talking about this. So yeah, thanks. Thanks for having me on.
Wig:
Yeah. Just an honor to have those decades of insight here and it’s really just so many angles of the topic. It’s really fascinating to discuss. So yeah, this has been a lot of fun. So again, you can find Mark’s writing on techchannel.com. He wrote that article, “The Nines Don’t Lie—They’re Not Telling the Whole Truth.” You can find that as well as additional content by Mark on TechChannel. And if you want to make sure you don’t miss anything, you can sign up for our newsletter and you can do that by going to techchannel.com/subscribe. All right, that’ll do it. Thanks everyone. Bye.