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.

IoT
IoT
Cloud
Commentary
4/15/2016
08:06 AM
Steve Trautman
Steve Trautman
Commentary
50%
50%

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
Comments
Newest First  |  Oldest First  |  Threaded View
Page 1 / 2   >   >>
Shantaram
50%
50%
Shantaram,
User Rank: Moderator
4/22/2017 | 4:17:22 AM
Re: 192.168.0.1
Exactly! It's really interesting solution, thanks
SteveTrautman
50%
50%
SteveTrautman,
User Rank: Apprentice
4/20/2016 | 3:44:38 PM
Re: It's mainframe apps and languages that are aging out...
Thanks for the great comments TerryB.  You are spot on in that schools are not going to solve this problem and the millenials coming up need some help seeing how working in this way is good for their careers. We all benefit from a little "selfish motivation" when it comes to stepping up to a task. 

One of the reasons the solution i'm proposing works is because we start by demystifying the idea of working on the mainframes.  If we tell our next gen colleagues that they're going to "learn mainframes" that is much harder to imagine than breaking the work down into discreet tasks that start with "troubleshoot, analyze, design, build and test."  Then they're learning  "81 tasks and skills" that collectively make up what it means to "learn mainframes." It is finite and do-able rather than overwhelming.  Anyone can chip away at a list!

We also give them tools to extract the secret sauce of their very experienced colleagues so they are at no one person's mercy when it comes to being "taught."  With a few common sense ideas we can make the whole idea palatable, practical and even fun!

 

 
TerryB
50%
50%
TerryB,
User Rank: Ninja
4/20/2016 | 1:44:38 PM
Re: It's mainframe apps and languages that are aging out...
@Steve, I'm just glad to see people like you actually have ideas. Not something many people are talking about.

Two major problems in this area:

1) Schools are not teaching any of these skills anymore. The IT landscape has gotten so scattered, I'm not sure what they are teaching these days that actually helps get a job later.

2) New IT people want to be the next Zuckenberg, they no longer view it as a safe technical low profile career. They want to be in on the next Uber. Anyone using a mainframe does not fall into that class of business.

But if you can overcome that hurdle, get a new IT person to commit to a business which isn't sexy by nature, I see no reason they wouldn't absorb these skills. I went to Comp Sci major in school because there were jobs, I had no idea what IT work out in real life looked like. Or cared for that matter, just wanted to make a good living. I have to believe many people still feel the same way.

I think you are definitely on correct track identifying what these key skills are they need to learn besides just the programming languages themselves. And much of that depends on just what these young people learned how to do in college. I wrote (partial) compilers and operating systems in college, along with classes where you write code implementing algorithms like Traveling Salesman and binary sort. I don't know what kids today are even being taught. HTML? Java? Javascript? CSS? Cloud?  None of those does much good in mainframe world. I'm not even sure how much relational database training they get anymore in this increasingly unstructured data world.

You have tackled a real issue here, thank you for trying.
ANON1250092266115
50%
50%
ANON1250092266115,
User Rank: Apprentice
4/19/2016 | 9:53:58 PM
Re: It's mainframe apps and languages that are aging out...
A key attribute us mainframers have is a mindset, amend an expectation, that both systems of hardware and software, and applications, too, can be built such that problems can be solved on their first occurrence. It involves keeping traces, logs, etc and footprints of logic paths, etc. Yes I wrote, " First Fault Problem Solving", a book explaining the mindset, etc. Some non mainframe systems have this attribute, and some systems are growing into it. But new programmers have to be taught this. They often favor do-overs, which are so impractical in so many ways.
ANON1250092266115
50%
50%
ANON1250092266115,
User Rank: Apprentice
4/19/2016 | 9:53:55 PM
Re: It's mainframe apps and languages that are aging out...
A key attribute us mainframer shave is a mindset, amend an expectation, that both systems of hardware and software, and applications, too, can be built such that problems can be solved on their first occurrence. It involves keeping traces, logs, etc and footprints of logic paths, etc. Yes I wrote, " First Fault Problem Solving", a book explaining the mindset, etc. Some non mainframe systems have this attribute, and some systems are growing into it. But new programmers have to be taught this. They often favor do-overs, which are so impractical in so many ways.
RobertM903
50%
50%
RobertM903,
User Rank: Apprentice
4/19/2016 | 12:41:58 PM
Mainframe Talent
Not all of that legacy talent has one foot out the door to retirement.  I've got 9 years to go at least.  Know COBOL, Fortran, Assembler, AND PL/I.  I could lead one of those teams.
SteveTrautman
50%
50%
SteveTrautman,
User Rank: Apprentice
4/19/2016 | 10:46:20 AM
Re: It's mainframe apps and languages that are aging out...
Thanks for the comments guys. I wonder what you think about the ideas around bringing the next generation into the fold to support mainframe over the long term?
Ron_Hodges
50%
50%
Ron_Hodges,
User Rank: Moderator
4/18/2016 | 3:52:28 PM
Re: It's mainframe apps and languages that are aging out...
I think the reason they ran Watson on Linux on P-750 hardware was to show that this (Linux on POWER) was a serious platform, especially in the HPC space.


Check this out: http://www.zdnet.com/article/what-makes-ibms-watson-run/
TerryB
50%
50%
TerryB,
User Rank: Ninja
4/18/2016 | 3:44:27 PM
Re: It's mainframe apps and languages that are aging out...
I get where you are coming from @Ron, can't say I disagree with anything you said. No question the parts are better in IBM servers than cheap commodity hardware. My point on that was those cheap commodity server arrays are designed expecting failure of individual servers, that rarely kills the application serving. So in that regard, I'm not sure if "uptime" is any different than mainframe type systems with better parts. But it's sure harder to write robust, secure applications on these server arrays than it was on mainframes, people are proving that just about everyday.

My point on Linux was it was not created for servers, it was created to compete with Windows. That's awesome it performs that well when on servers.

IBM mainframes were never really UNIX servers, that space belonged to the HP and Sun's of the world back in the day. So I'm guessing Linux on mainframes is IBM's way of competing with cheap server arrays. The POWER systems running AIX were mostly targeted at HP and Sun standalone servers. But I'm mostly guessing, I'm not really sure I know the use case in UNIX versus LINUX anymore, as far as servers go. But I'm guessing it's all about the the available apps.

I knew Watson ran on POWER servers but thought it was AIX. I'm not really sure I understand why they chose to run on Linux instead of AIX? I know they are running many POWER servers for Watson, not just virtualizing a bunch of Linux machines from the same hardware. Maybe this was design to keep cost down for people they want to sell Watson to? Or was it to make Watson somewhat independent of pure IBM hardware and UNIX licensing? Very interesting.

 
Ron_Hodges
100%
0%
Ron_Hodges,
User Rank: Moderator
4/18/2016 | 2:56:46 PM
Re: It's mainframe apps and languages that are aging out...
I respectfully disagree with your fundamental premise, i.e., that the reliability of the mainframe has to do with just the OS.  Commodity hardware may have some of the redundant components now but still lacks a wide range of RAS features that characterize higher end RISC and mainframe platforms.  Basically, the stuff is cheap, in terms of both features and construction.

Be that as it may, it is also inaccurate to describe Linux as as workstation/single-user system.   This would be news to the high end applications running on Linux on both Intel and RISC platforms -- including IBM's Watson.  Statistics show that Linux availability on RISC and mainframe platforms approaches that of AIX and Z/OS. 

I would agree that when you are dealing with core, mission-critical systems of record, more rigor is required than light-weight systems of engagement.  But that is a process question as much or more than it is a technology question.

 
Page 1 / 2   >   >>
Commentary
Why It's Nice to Know What Can Go Wrong with AI
James M. Connolly, Editorial Director, InformationWeek and Network Computing,  11/11/2019
Slideshows
Top-Paying U.S. Cities for Data Scientists and Data Analysts
Cynthia Harvey, Freelance Journalist, InformationWeek,  11/5/2019
Slideshows
10 Strategic Technology Trends for 2020
Jessica Davis, Senior Editor, Enterprise Apps,  11/1/2019
White Papers
Register for InformationWeek Newsletters
State of the Cloud
State of the Cloud
Cloud has drastically changed how IT organizations consume and deploy services in the digital age. This research report will delve into public, private and hybrid cloud adoption trends, with a special focus on infrastructure as a service and its role in the enterprise. Find out the challenges organizations are experiencing, and the technologies and strategies they are using to manage and mitigate those challenges today.
Video
Current Issue
Getting Started With Emerging Technologies
Looking to help your enterprise IT team ease the stress of putting new/emerging technologies such as AI, machine learning and IoT to work for their organizations? There are a few ways to get off on the right foot. In this report we share some expert advice on how to approach some of these seemingly daunting tech challenges.
Slideshows
Flash Poll