However, before jumping into panic mode, we must first consider the question of precisely which skills we mean before we can provide a coherent statement on the nature of the crisis.
 | ||||
|
| | ||
|
Perspective Plugging the main- frame brain drain  With mainframe talent retiring faster than it's being replaced, BMC's Bill Miller sees a scary juncture ahead. |
| ||
|
|
||||
|
|
||||
There is a world of difference between the skills required to maintain a legacy system and those required to manage the legacy application itself. For example, mainframe systems administrators responsible for job schedules, systems security and operating system upgrades, have different skills from the application developers creating the company's business logic in traditional programming languages such as COBOL, PL/I and FORTRAN.
Some of these skills are essential to ensure business continuity. Others are less so, depending on IT's strategy. Separating the job functions out is essential to understanding the skills needs within your organization. When you consider that these are the people responsible for maintaining and operating an estimated 75 percent of business transactions that legacy applications represent, confusing them will be to your peril.
Much of the concern at the heart of the mainframe skills dilemma is in regard to the age of the work force. The popular view is that many of the staff with appropriate skills will soon be retiring, taking with them not only systems expertise but also much of the business knowledge they acquired through years spent molding information technology to the changing contours of the corporation.
This certainly is an issue, with the average age of federal government IT workers just shy of 50, and a recent survey across mainframe programmers in the U.S. finding the average age to be between 42 and 49. However, given that most of these workers still have a decade or more of regular employment ahead of them, the concern should be less on replacing their technical skills and more on leveraging the business knowledge that they possess.
Organizations must act now to map out their application portfolios in order to achieve a greater awareness of how significant any loss of knowledge might be when staff members leave. Separating strategic business knowledge from commodity IT skills is a vital step in creating the appropriate skills initiatives.
Another legitimate area of concern is whether enterprises will be able to recruit and retain the talented staff required to bridge the gap between the legacy world and the newer worlds of Web services, Java and .Net.
Both business and academic worlds acknowledge that teaching a specific skill or language in isolation is no longer a priority. The requirement is for interoperability. There is a blurring of boundaries now. Contemporary platforms are putting increasing pressure on the mainframe, and the mainframe world itself is embracing Linux, Java and Web services, constantly eroding the divide between the old and the new.
Today's IT professionals typically do not aspire to linear career paths aligned around a single piece of technology, but rather relish the chance to swap roles more frequently. In order to retain skilled workers, organizations can use this to their advantage as they introduce pockets of legacy technology on a project-by-project basis, building the services and business components required of an agile IT infrastructure.
With the retirement of key legacy workers still some way off, there is time for IT organizations to ensure a smooth transition of skills. But this only will occur by working to attract new recruits with the right mix of technical and business skills and ensuring that existing staff have every opportunity to impart their knowledge of the legacy systems and the business processes they encapsulate.
Biography
Mike Gilbert serves as vice president of marketing and director of product strategy at Micro Focus. Gilbert led the team that built the first Object-Oriented COBOL compiler.
See more CNET content tagged:
mainframe, skill, COBOL, Web service, age
- by mainframe_sysprog October 31, 2008 1:25 AM PDT
- The fact that someone suggests that converting COBOL code to some other language will solve the 'mainframe problem', shows how little he understands mainframes.
<br />
<br />1) in most mainframe shops, the bulk of the mainframe workload is in transaction systems such as CICS and IMS. These systems are by design: multi-user, multi-tasking, multi-processor utilizers...out of the box. They can also be configured(out of the box) to be multi-address space, and to be multi-machine(read advanced clustered technology(mainframe term=parallel sysplex) out of the box.
<br />
<br />This is not something that could be SIMPLY translated. Especially the parallel sysplex piece, since equivalent technology has not been commercially available yet, on midrange/minis to share memory between separate machines(not processors).
<br />Even now, I've seen current lectures online from naive professors, that think we SHOULD develop 'transaction systems' to take advantage of multiple processors unaware that the technology of transaction systems has been around for 40 years.
<br />
<br />2) People need to understand COBOL's strength before they even suggest translating it.
<br /> COBOL's great strength is it's propensity of self-documenting, especially helpful for those who aren't the original programmer, doing follow up maintenance.
<br />Imagine if you will a program, that has a line of code that says:
<br />SUBTRACT LIABILITIES FROM ASSETS GIVING NETWORTH
<br />vs...
<br />n= a - l
<br />which line do you think will be easier for a future programmer to understand a 1000 line programs logic. <br />This is why alot of COBOL code is still around after 20, 30, 40 years+... and is a language that your children and grandchildren could maintain.
<br />Of course, some people will think that <fill in the blank> new language will be the 'natural' replacement for COBOL... FINE, maybe it will... but my question is... what makes it a better replacement than other 'natural' replacements that have died on the vine as replacement languages, such as PASCAL, FORTRAN, etc <br />
<br />Sure, all the languages that have been designated as 'COBOL killers' are usually easier for someone coming out of school to write, out of the box, but they are, in many cases not the best languages to maintain... especially in a team environment.
<br /> <br />3) converting programs costs money, most specificly labor costs... and most corporations are loath to spend more than they need to. Most business types would ask"What business value are you adding with this?" Too many corporate types are more concerned with the profitability of the next quarter than how well/how poorly their company is positioned for staffing 5/10/15 years down the line. Even now, there are companys that are engaging in layoffs of mainframe personnel, even though they don't have any plans on reducing their mainframe workload or having adequate personnel to maintain their systems. <br />
<br />4) Mainframe technology is much more sophisticated and nuanced than what is atypically on midrange/mini systems:
<br /> ILM(information life cycle management) = DFHSM.... which has been around on the mainframes for 20+ years.
<br /> VMWARE/ZEN(hipervisors) = z/VM, which has been around for 20+ years.
<br /> Storage management = DFSMS...which has been around 20+ years.
<br /> cluster computing = sysplex computing, which has been around for 20+ years, midrange and mini's have not duplicated parallel sysplex(10+ years), yet.
<br /> performance computing is still in it's infancy in midrange/mini systems... mainframes now have goal mode performance... ie...you tell the system what performance you want your transaction to have
<br /> 'I want transaction ABCD to have 1 second response time' and the OS will do what it kind to make that 1 second to the best of it's ability. <br />
<br />This is not to say that midrange/mini's won't catch up on some of these things, but people should not underestimate the value mainframes provide. Transfering a mainframe app that has DFHSM doing lifecycle management on it's disk drive data to a platform, that doesn't do ILM and you will soon be paying more and more for disk drives,down the road. <br />
<br />5) In anticipation of the implied COBOL skill shortage and the risk of a platform migration...IBM has put several modernization strategies in place.
<br /> a) front end mainframe systems with LINUX images,using interconnected virtual switch(data transfers via IP, at memory speed)technology,on cost effective specialty engines.
<br /> b) availability to use more 'modern' languages, in their CICS regions. most notably, JAVA(using cost effective speciality engines) and REXX, coupled with full internet capability, including WEB 2.0. <br />
<br />The problem with this, is that in many cases the system programmer for the systems in question will need multiple platform or multi-language skills. fair enough, it is easy enough to have/add these skills to a person's technical repertoire, but what manager and HR person, would look forward to recruiting replacements with greater and greater skillsets.
- Like this Reply to this comment
-
(19 Comments)