Making Mainframes Cool Again - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

08:06 AM
Steve Trautman
Steve Trautman

Making Mainframes Cool Again

Mainframe systems are still the backbone of much of today's IT infrastructure. Yet, finding IT talent to maintain these systems, and the COBOL and Fortran languages that support them, is becoming increasingly difficult. Knowledge transfer expert Steve Trautman, founder of The Steve Trautman Co., offers real-world advice on how IT leaders can cultivate the talent needed to run these crucial systems.

COBOL Leads Us Back To The Future
COBOL Leads Us Back To The Future
(Click image for larger view and slideshow.)

IT executives are starting to say something out loud that everyone has known for a long time: Despite decades of IT transformation, mainframe systems are still the backbone of much of today's IT infrastructure. One obvious reason is that, in many cases, they work fine. Replacing all that horsepower could cost tens or hundreds of millions of dollars, let alone the cost of disruption to the business.

The trouble is that all of the people who know how to maintain these systems -- while preparing to bolt on next-gen apps -- are aging out of the workforce, and there are no Millennials eagerly lining up to take their spots. Mainframes require knowledge of COBOL and Fortran, languages that are not considered particularly sexy these days. It's not hard to see why no one wants to learn these languages. Mainframe is dead. Long live the cloud. Right?

If CIOs don't change the narrative right away, the challenge of keeping up with the legacy applications running on mainframes is going to soon be untenable. Hiring back retirees won't work much longer. Then what will you do?

The author of this post is one of the experts participating in the Leadership Summit at Interop Las Vegas, May 2-6. Register now!


Here's a solution. If you're the CIO, I want you to handpick six to ten hotshots who are up-and-coming leaders in your organization. These are people who have the technical skills as well as the potential to be influencers among their peers.

Ideally, they'd enjoy working with each other, so you can shape them into a well-oiled machine and enable them to have fun while doing something you think is important. Think A-team in the making. You're going to grow yourself a solution to this problem.

Pull these people into a room, buy them lunch, look them in the eye, and then give them this message:

"I've hand-selected you to do something for me that is going to help you shape the future of IT at our company. It may sound wacky at first, but hear me out. Our mainframe systems are the backbone of more than half of our technical capacity, and the brain trust that keeps them relevant and stable is fast leaving our company. This puts our business at risk. I want you to take a lead on the solution. I want you to work as a team to learn the history, value, and unique role of these foundational systems so that we can springboard off of that capacity into a future that continues to shape the course of our company.

"Yes, I'm asking you to become experts in our legacy systems, but do not be afraid. This is the opposite of you being banished to the basement to work on the mainframe. Instead, you are going to be building a skill set that is truly unique in your generation. You'll learn more about how our business actually works from this experience than you can get anywhere else. You'll set yourself up to be a thoughtful and trusted advisor to our line-of-business executives and to me. For the rest of your career, you will leverage this foundation as you help plot a way forward."

Let your team know that if your organization doesn't get this right, it risks disruptions to its revenue stream, potentially in the tens or hundreds of millions of dollars.

Since this is so critical, commit to your team members that you will give them the very best resources available to make this plan work quickly. Make it clear that the organization has already waited too long, and every hour counts.

Easy to say, right? So, how do you get there?

(Image: HultonArchive/iStockphoto)

(Image: HultonArchive/iStockphoto)

Here are two key steps you can take to make this work. The guidance below is based on a knowledge transfer process we've developed in my consulting practice, The Steve Trautman Co. I'll be sharing more of my work during the Leadership Summit at Interop in Las Vegas, May 2-6. (Editor's note: Interop is produced by UBM, InformationWeek's parent company.)

The first step is to create what we call a Knowledge Silo Matrix, which breaks the systems down into areas of expertise, and maps what is already being done by existing experts. Your team members need to know who is already doing this work the right way, so they can learn from the appropriate experts with a focus on the highest risk, highest priority knowledge. You and your teams will use this matrix to divide and conquer. Everyone doesn't need to learn everything, but everything needs to be known by someone so you have sufficient capacity going forward.

The second step involves deconstructing the work in each knowledge silo using what we call Skill Development Plans. In this process, you and your team will list out every single task, and all of the "secret sauce" that your current experts have. These plans will allow each member of your handpicked team to drive their own learning, rather than waiting to be taught. Each person's role will be to learn enough about mainframes to ensure they are maintained and ready for anything new your organization wants to throw at them.

Let your team know that, as soon as they collaborate to build this knowledge transfer machine, you'll be able to cycle others through the role so they can take over and allow the original team members to move on to new assignments with this foundation.

Make sure your handpicked team members know that they are the pioneers, and you'll have others follow behind them, so you never have this talent shortfall again.

As part of this process, they'll get special training in Talent Risk Management and Knowledge Transfer that will help them advance in their careers, whether they want to continue along the path of technical expertise, or work their way along a management track. In this way, you're helping them to be unique among their peers.

Carve out between 25% and 50% of each team member's time to focus on this initiative, so that they can continue some of their current projects. Based on our experience, it will take a year or so to fully get this system in place, but you'll be able to make the risks clear and prioritized by the end of your first quarter by using this process. That way, your team will know it's on the right track fairly quickly.

Along the way, meet regularly with your team to check in and ensure they have all the support they need.

If you follow these guidelines, you will make your legacy systems sexy again. You'll build a team that understands the business from the ground up and so can be better advisors to you as you migrate to next-generation technology in a thoughtful, pragmatic way. You'll be solving an intractable problem and creating a system so the problem does not recur.

If you don't make this bold move to reduce your talent risks, what are your other options?

Tell us what you think in the comments section below. Can this approach work in your organization? How mainframe-dependent are you? What methods have you used to make mainframe computing appealing to your Millennial tech workers?

For more than two decades, Steve Trautman has provided executives at blue-chip companies with the simplest, quickest, and most relevant solutions for knowledge transfer and talent risk management. Developed by Steve in the early 1990s, when he worked at Microsoft, his ... View Full Bio
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
<<   <   Page 2 / 2
User Rank: Ninja
4/18/2016 | 1:05:24 PM
Re: It's mainframe apps and languages that are aging out...
@Ron, I'm trying to decipher what you mean by "iron clad reliability of the mainframe"? Most of that reliability had to do with the o/s, not the hardware itself.

I think you are talking about the duplicate/fault tolerant hardware that started with mainframes. But most systems now are dual power supply, RAID disk arrays, dual NICs that are teamed, etc. So, in my mind, reliability is much more about the resilience of the o/s itself, which of course follows thru to applications running on it.

Linux is certainly more trustworthy than Windows but still a workstation/single user based system. That was it's purpose, we already had UNIX for servers. But no way it is as robust (and secure) as mainframe o/s or even i5os that runs on IBM midrange POWER systems. For that matter, even the POWER servers running AIX (UNIX) are better, it is a true server o/s.

What happens is people go to reengineer these apps to run on the Linux/Win servers and end up using these cobbled together "frameworks" to get the job done, which normally have more (security) holes than swiss cheese. That stuff brings in the DevOps stuff, where you are updating code with HTTP PUT and DELETE, and then you wonder how hackers are modifying your stuff.

You just don't have those problems with traditional mainframe infrastructures, it takes an insider with a LOT of business know-how to even know what to do. And many of those shops still divide the application guys from actually making changes to production system, usually have very formal change mgmt systems in place.

User Rank: Moderator
4/18/2016 | 8:59:39 AM
It's mainframe apps and languages that are aging out...
Actually, the mainframe itself has been evolving.  Take a look at LinuxOne, the new mainframe offering from IBM.  One row of those could replace an entire data center of Intel commodity boxes, with much greater security and availability, and they run Linux natively. 

The trick is to port or re-engineer those legacy apps into something that will run on Linux.  Then you can still have the iron-clad reliability of the mainframe.
User Rank: Apprentice
4/18/2016 | 5:50:38 AM
New Generations not Interested in Mainframe
New Generations are absolutely not interested in mainframe due to words of mouth that there is lack of growth in Mainframe, very less opportunities in mainframe and also that Mainframe is going for slow death.

Many of the few years experienced in Mainframe are also trying to move out of mainframe.
User Rank: Ninja
4/15/2016 | 1:23:49 PM
Midrange also
Same issue for the IBM i5 (formally AS400) market. This platform is based on mainframe principles and has only a native text based 5250 interface. It natively runs COBOL, RPG and C, although it has a JVM (for Java), native Apache HTTP server and can run newer IBM stuff like Websphere and EGL.

Although still the finest business server in world, it is lumped into the "legacy" category because many businesses haven't touched their applications in years. Then add in fact many developers from the older RPG generation never bothered to update their skill sets, so they are incapable of doing the modern stuff the i5 can do. That then just leads business mgmt to believe the i5 is the problem, so they toss it and buy new ERP running on Win or cloud. I've seen that so many times, it's sad.

I'll be facing this issue soon. I single handedly do development/support on our i5 and have about 9 years left before retirement. I only see two scenarios: 1) Bring in younger person from someplece with i5 experience a couple of years before I'm done and get them up to speed to takeover. 2) Align the company with IT service firm with i5 experience and move the actual technical skill out of house. In that scenario some kind of generic IT person (or super business user) would coordinate bringing in the tech skills when needed.

But one comment on your point about fading COBOL and FORTRAN skills: If you are a competent developer writing Java, Extjs, jQuery, etc, learning COBOL and FORTRAN should be no brainer. It's a lot harder to go from non OOP to OOP than it is from OOP to non OOP. Heck, just compare the syntax involved in newer languages ({,[,etc) than COBOL. You should be able to learn that on the fly. JCL (or CL on i5) can be different for modern developers but should not be big deal either.

What I think would be more difficult is the ability to maintain a mainframe on the system side of things. But you should be able to outsource that tech support fairly easily.
<<   <   Page 2 / 2
Why 2021 May Turn Out to be a Great Year for Tech Startups
John Edwards, Technology Journalist & Author,  2/24/2021
How GIS Data Can Help Fix Vaccine Distribution
Jessica Davis, Senior Editor, Enterprise Apps,  2/17/2021
11 Ways DevOps Is Evolving
Lisa Morgan, Freelance Writer,  2/18/2021
White Papers
Register for InformationWeek Newsletters
The State of Cloud Computing - Fall 2020
The State of Cloud Computing - Fall 2020
Download this report to compare how cloud usage and spending patterns have changed in 2020, and how respondents think they'll evolve over the next two years.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you.
Flash Poll