openmainframe

In today’s episode of the “I Am A Mainframer” podcast, Steven Dickens sits down with Steve Hassett. Steve is the COO of GT Software.  Steve tells Steven about his journey with the mainframe, his thoughts about the mainframe, and it’s future.

Steven Dickens: Hello and welcome. I’m Steven Dickens and welcome to the I am a Mainframer podcast from the Open Mainframe Project. I have the pleasure today of being joined by the COO of GT software, Steve Hassett. Welcome to the show, Steve.

Steve Hassett: Thanks Steven. Thanks for having me.

Steven Dickens: Yeah, always a pleasure. Steve, just for our listeners, can you just give us a brief introduction to your role and kind of where you fit in the GT Software team and  just sort of get us orientated so we can get started?

Steve Hassett: Yeah, sure.

Steve Hassett: So if you’re not familiar with the GT software, we are a 35 plus year old software company based in Atlanta, Georgia. Our focus from day one has been on tools for mainframe software developers. Initially, that was for BMS screen mapping and help screens on the old green screen terminals.

Steve Hassett: Today our focus is really laser focused on mainframe integration, so making it easy to integrate those legacy applications through APIs to web, mobile, and other applications. Within GT I’m chief operating officer and I’m responsible for all the day to day operations, sales, marketing, technology.

Steven Dickens: That’s a good, great place to start, Steve. If you can give us a little perspective of Steve Hassett, the person, you know, I’ve obviously got your profile up in front of me here, but just give me a view of kind of where you’re based out of and a little bit of your personal journey and that will sort of give some color commentary to our listeners here.

Steve Hassett: Yeah, it, you know, it’s funny that everything comes around.

Steve Hassett: So, I started my career after college. I went to Rensselaer Polytechnic Institute in upstate New York and my first job was a mainframe software developer and that was a back in the day, and then I went back to business school at the University of Virginia. Did some work in M&A in finance and worked for a number of different companies and some consulting.

Steve Hassett: Then in 2000 founded an early SaaS web mobile software company. Sold that in 2004 and have been running businesses for a number of different software companies after that. And today I’m running the GT Software business and have been here for about two and a half years. So, I went from a COBOL to SaaS and now sort of helping COBOL integrate with SaaS. It all comes around.

Steven Dickens: So a journey, for sure Steve by the sound of it.

Steve Hassett: A logical journey.

Steven Dickens: Yeah, make it certainly a journey we’ve seen a lot more of in the industry right now and particularly in the mainframe space as people try and sort of embark on that journey to sort of open APIs, restful APIs, sort of connecting backend system of records if you will, to those front end systems of engagement.

Steven Dickens: So, maybe just talk me through kind of what GT Software are doing in that space. Just give me a flavor if you will, of kind of where you’re intersecting with that type of dynamic and how you’re helping your clients kind of move that game forward.

Steve Hassett: Yeah, so we have a tool called Ivory Service Architect and it’s the easiest way, we believe, by far the easiest way, to create REST and SOAP APIs that connect to legacy mainframe applications, so that you can create an API that’s exposed to the world so that you can create these newer cutting edge applications and do all your development around the mainframe. So, we’d like to think of it, and to borrow a term that IDC uses, which is to help create the connected mainframe. So, what that means is you keep that core system of record, but you do all your new innovation around the outside as opposed to trying to do the very heavy lifting of rewriting those legacy applications.

Steven Dickens: Hmm. And what are you seeing when you’re engaging out with those clients who are on that journey? Obviously a lot of our listeners are sort of at the intersection of open source and mainframe. How are you seeing that sort of RESTful API, SOAP API, kind of engage with those agile sort of DevOps-savvy, Cloud native, type players?

Steve Hassett: Well, we help in that quite a bit. Because what we enable the mainframe development teams to do is to adopt a more agile methodology when developing APIs and do it on an iterative basis.

Steve Hassett: So, it’s not a six month waterfall project where the end of it, you get an API. But it’s actually something you can build on and iterate on a daily basis and that helps them. It’s interesting, the big thing that I see and I hear every day is when I tell somebody what I do, they kind of give me a funny look and then … why would you be developing things for mainframes? And what they don’t realize is they interact with them every day and that if they’re working for a bank, they’ve got billions of lines of COBOL code and globally trillions of dollars of transactions flowing through those COBOL systems. And it’s imperative to develop the integration.

Steven Dickens: So, I mean it’s interesting, the title of the podcast is I’m a Mainframer and it’s interesting to talk about the reaction you get when you mentioned that you are a mainframer as you meet people. Can you sort of give us a little flavor of your personal journey and how you’ve sort of come to self-describe yourself as a mainframer? Just to give some … I suppose personal commentary that will help sort of frame the overall message for people.

Steve Hassett: Again, having started my career as a COBOL programmer and come full circle through SaaS and now to GT Software, the thing that attracted me to the company was the recognition of how hard it is to modernize legacy systems and how hard it is to integrate legacy systems without having the right tools in place. You know, and for me that was the number one thing that attracted me to this business in wanting to join the team and help steer the company in the future.

Steven Dickens: Okay.

Steven Dickens: And I suppose I’m trying to get underneath that. What do you see as those big challenges? Is it a perception challenge? Is it a technical challenge? Is it a commercial challenge? When you’re seeing that dynamic, the reason why GT Software exists, is it a combination of those factors? Or is it, as I say, a perception commercial or technical reason that you see is holding customers back most?

Steve Hassett: Yeah. That’s a great question because it’s something that I’ve encapsulated into what I call the five stages of mainframe grief.

Steven Dickens: So we pivoted to a grief counseling podcast, Steve, is that what you’re trying to tell me?

Steve Hassett: We have. Grief counseling for mainframers. And actually it’s for companies.

Steve Hassett: So the first stage is at a corporate level and It’s denial. They know they need digital transformation and so they’re going to try to rewrite the legacy applications or hand code integrations to try to modernize. And that doesn’t go very well and is not very fast.

Steve Hassett: So stage two is anger. And at this stage you’ve got the board driving the CEO and the CIO and the leadership team to modernize their applications and it’s not going well and it’s not going as fast as they expected. So they say, let’s rip it out, start over and move off the mainframe. And well that doesn’t go well either. And so in year five of the five year plan or the three year plan, they haven’t really gotten off the mainframe and they realize they can’t get off the mainframe.

Steve Hassett: They go into stage three, which is bargaining. And they think, well they can try to do it themselves and accelerate progress on their own and that doesn’t really work. And then the board realizes that they can’t get off the mainframe. And so they search for another alternative. And they go through a period of grief where someone says, how come we can’t modernize as quickly as we thought? And as a friend of mine who’s a software architect said it’s crazy to think that you can replace 40 years of legacy code in five years. And that’s a discouraging period for the organization.

Steve Hassett: And finally they come to the stage of acceptance and they realize that what they need to do is let the mainframe do what the mainframe does and build around those core systems and build RESTful and SOAP APIs around those core systems. And we are seeing that in every one of our customers, new and old, that they’ve gone through this process where they thought they were going to get off the mainframe and the board got engaged and wanted them to get off and it wasn’t possible. So, they’re searching for something new.

Steven Dickens: So I, I think I can, as I look at your Linkedin profile here, Steve, I think chief grief counseling officers is probably a better title than the one you’ve got written.

Steve Hassett: It requires some level of sensitivity.

Steven Dickens: Some level of sense. Very politically correct.

Steve Hassett: Yeah.

Steven Dickens: So now that’s an interest.

Steve Hassett: Really, the flip side of that is, we have our customers turning to us and saying, how can we better make the case for the mainframe? But they still have this pressure. And so, we try to work with them and help them develop those arguments which begin with what everybody knows: There’s nothing more reliable and scalable and faster than a mainframe. And it’s not just about the box, but it’s about the 50 years of applications you’ve built on that box that are designed for your business and your regulatory environment and there aren’t off the shelf applications that you can just plug in.

Steven Dickens: It’s interesting you hear so much about … It’s not so much as you would describe around this sort of 50 years of code. For me, I’d describe it as 50 years of business logic that’s been written into code that then executes on the platform. And I think that’s what … from certainly my interactions with clients, they tend to get ignored. If these were just COBOL programs, then it would be an easier migration. But what they are is a codification of the business logic. And in a lot of organizations you find that that business logic’s not understood, let alone the code that’s understood

Steve Hassett: Exactly. When I say 50 years of code, you’re absolutely right. It’s 50 years of business logic and the people that develop that logic are long retired. And it’s impossible to try to, nearly impossible, to try to figure out what the underlying behaviors you’re trying to get out of your systems are, which is why it’s a superior approach to try to just preserve that and build around the outside.

Steven Dickens: It’s a renovate rather than rip and replace is what you’re saying.

Steve Hassett: Exactly.

Steve Hassett: So if you move into or if you buy a new house or if you buy an old house and you have to decide what to do first, the last thing you want to do is upgrade the electrical and the plumbing. You’d rather figure out how to make that work as it is and then build a new kitchen. And in the mainframe world, we help enterprises invest in the kitchen rather than the plumbing.

Steven Dickens: Yeah, that’s a great way to describe it. Make the house look nice and a better place to live in rather than focus on the wiring and the plumbing that nobody actually gets to see.

Steve Hassett: Right.

Steven Dickens: Which is fair. And having done that in a previous house is very expensive for very little tangible return from an experience of living in the house.

Steve Hassett: Exactly. That’s where it came from. I’ve been through that as well.

Steven Dickens: You share the same scars by the sound of it, Steve.

Steve Hassett: Yeah.

Steven Dickens: Give me your perspective, if you would, of how you see the mainframe market right now. It’s always interesting to engage with the senior leaders of the open mainframe project membership and to sort of get a perspective of where they see the market. If you could give me sort of that market perspective, that would be great.

Steve Hassett:  So what we’ve seen is sort of the low hanging fruit of companies that could move off the mainframe, who don’t have the need for this stability and reliability and were able to buy commercial applications to migrate. Most of those have done that.

Steve Hassett: And now you’re dealing with the more complex organizations and the complex business logic where it’s more difficult.

Steve Hassett: So, for what we do, in terms of transitioning from mainframe to connected mainframe, we see it accelerating. And it’ll give you a couple of examples.

Steve Hassett:  In banking especially, we see two things driving it. One is Open Banking and one is real time payments. And Open Banking is the idea that you have create APIs to allow other companies to connect to your core systems.

Steve Hassett: And as you probably know, it’s the law in the UK. And it’s coming soon to Europe where every bank will be required to securely open up those core systems. And, that’s pretty profound. And it’s a complete change in mindset.

Steve Hassett: So, in the old days when you’d write a check, you give it to the bank or the correspondent would give it to the bank, and they’d batch them up, literally in a batch, and bring them to the Federal Reserve in the U.S. and the Federal Reserve would clear the checks and it would take a week or so, in a batch. And then they went to electronic images, but it was still batch clearing at the Federal Reserve and it took a long time.

Steve Hassett: Now consumers are driving the need and the demand for instant payments. So if you’ve used Venmo or Zelle, you instantly transfer money and it goes instantly out of your account into the new account.

Steve Hassett: And that’s taking over in in many aspects of payments and in a faster way than credit cards. And it means verifying funds exist from the payer and they immediately go to the payee.

Steve Hassett: But what a lot of people are realizing now is that impacts every other system. As you move from batch to real-time, you have to verify balances in real-time. You can’t have any latency so that you have $100 go in and $300 go out because the balances weren’t updated in real-time. You have to check for fraud in real-time. Verify identity. Make sure you’re not transacting with a restricted company, country, or person. And you have to do that all in real-time. And the systems weren’t set up for that but it’s addressable by proper integrations, both inbound and outbound from those core systems. And that’s a huge trend that’s driving our business.

Steven Dickens: And then how do you see the mainframe in that trend? Just maybe give the listeners a perspective of kind of how the mainframes kind of reacting to that trend, if you will, Steve.

Steve Hassett:                    So, what we’re seeing is building new capability, doing things like having the legacy system, it could be COBOL or PL/1 call out to a third party to check to see if a person is a terrorist or on a restricted list. And that’s a pretty hard thing to do. But it’s a critical thing to do.

Steve Hassett: And the other obviously is having systems call in to aggregate accounts and initiate payments from the other end. And what it’s doing is actually solidifying the position of the mainframe because again, you’re building these new capabilities around the outside and bolstering the mainframe with APIs to keep its position as the bank’s core system.

Steve Hassett: And I think it’s very, very beneficial and it helps accelerate the recognition that the rip and replace is not a good strategy. If you’re doing it for modernization there are better and faster ways to accelerate your business transformation.

Steven Dickens: So I think you’ve given us a really good perspective there, Steve. That’s been really interesting to listen to for me and I hope for our listeners.

Steven Dickens: One of the questions I always ask as we start to come towards the end of our time here together with the guests, is if you could look ahead, if you could have that classic crystal ball and look ahead to where you see the market going over a two, three, five, ten year horizon. Where would you see both GT Software and the underlying mainframe over that type of time horizon?

Steve Hassett: That’s a complicated question. There are a couple of things that are worth mentioning within that. One is what we hear from customers. One of the reasons that they’re trying to migrate off the mainframe is, and I think this is really interesting, is the perceived lack of talent in aging population. People aging out of being COBOL developers. And I’ve always thought that economics and supply and demand will fix that. And we’re seeing that happen. In that salaries are rising. Demand is there for the people with the skillset. And so we’re seeing more people go into learning these legacy languages. And in fact a really amazing piece of evidence of that is in Atlanta we have something that’s being developed called the Georgia Fintech Academy and it’s part of the university system of Georgia.

Steve Hassett: And when I first heard about it sounded very esoteric I think. How do you teach Fintech? Is that a thing you teach?

Steve Hassett: But what they’ve done is they went out to some of the larger financial companies in Georgia and said, what are your needs? What kind of people do you need? How can we help train them? And you know what the first mandate is? COBOL programmers.

Steve Hassett: So, we’re seeing that demand being met today. And so that’s number one. And so taking the lack of talent out of the equation in terms of a long-term reason to try to migrate. I see that not being a true issue within a couple of years.

Steven Dickens: Hmm. I tend to agree. I think just a free market economy. If college kids can see that it’s in a two to three x to program in COBOL versus it is in Python or Ruby or any of the Node.js or any other modern languages. You’ve got to learn one of these languages. Why would you learn a language where you can earn a third of what you can earn.

Steve Hassett:  Right.

Steven Dickens: We’re all coin operated to a certain extent. I can’t imagine learning COBOL is much different to learn in Python from a sort of length of time to get proficient. So why wouldn’t you go and take the higher paying job to be a COBOL programmer?

Steve Hassett: Right, exactly. Exactly right. And to extend that, part of the reason that folks had moved away is because COBOL programmers, mainframe programmers, administrators, were stuck in a lower trench of pay. And so it wasn’t attractive. But as you said, a language is a language. And what platform it’s running on isn’t all that really material to the satisfaction you get from creating something new and amazing. And as you have more ability to integrate both inbound and outbound to those legacy systems, you can create some new and extraordinary customer experiences. That drives a lot of people.

Steven Dickens: Yeah, I can imagine it would Steve. I can imagine it would. And I’m certainly seeing the same dynamic.

Steven Dickens: So if you see the skills challenge evaporating over a two to three year horizon, what else do you see in store for the platform?

Steve Hassett: Well, I see a huge demand for more interoperability, more connectivity, more APIs. That’s one of the reasons we’re here. And that being driven by not just banking but every business moving to more of a real-time operating methodology. That again solidifies the existing platforms and provides the ability to create new platforms around the outside. And sort of the way I refer to it as is going from a batch of hundreds and thousands to running your jobs as a batch of one. That’s real-time, execute one transaction at a time. And we’re seeing mainframes being adapted for that.

Steven Dickens: So Steve, as we look to wrap up, is there any other sort of parting comments? Anything you’d give maybe to some of our younger listeners as they look to embark on their mainframe career? Or is there any sort of sage advice you’d give as a mainframer of some sort of standing in the industry to them as they maybe potentially look to embark on a career on this platform?

Steve Hassett: Yeah. So this is one thing that I’ve seen that that is a real obstacle for, well not just the new people but the people that have been in the industry for a long time, is that they’re not deeply engaged with the strategy of the rest of the organization or even with the rest of the IT organization.

Steve Hassett: And I’ll give you an example of that. I was in Europe visiting customers last year and I was asking them about something called a PSD2–the Payment Services Directive Two in the EU, which is Open Banking in the UK. And I referred to that earlier as the legislation that requires opening up the systems. And the mainframe people we talked to, they were developing APIs to support this, but they didn’t know the underlying reason for those development initiatives and therefore they weren’t in a position to really prepare for it. And sort of the light bulb went on and they need to understand what the corporate direction is. Why, from an IT perspective, they’re moving in that direction. And then proactively be able to find solutions to help leverage the mainframe to solve those problems. And I think at any stage in your career understanding your company’s objectives and not just narrowly focused on delivering a requirement is critical to rising within an organization.

Steven Dickens:  Yeah. Understanding the impact to the business of what you’re creating and what your role is within the business. I think that’s very sound advice, Steve. I really do.

Steve Hassett: Well thank you.

Steven Dickens: As we look to wrap up, would there be any sort of final comments before we give the listeners back some time and get them back into their day?

Steve Hassett: Other than to repeat what we’ve said, which is excited about the future.

Steven Dickens: Fantastic.

Steve Hassett: And where we’re going to take this.

Steven Dickens: Well Steve, thank you so much for your time. Always appreciate it. Appreciate the support of GT software for the Open Mainframe Project.

Steve Hassett: Yeah. And we’re excited to be part of that and excited to shortly talk more about Zowe and the other things that are associated with the Open Mainframe Project.

Steven Dickens: Fantastic. Well, thank you Steve. My name’s Steven Dickens. I’ve been your host of the I’m a Mainframer podcast, brought to you by the Open Mainframe Project. You can click and subscribe and follow us on various platforms, including iTunes. So please take the time to do that and thank you again for joining us today and check back in the future for more I’m a Mainframer podcasts.

Steven Dickens: So signing off from me. Thank you very much and speak to you soon.