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
paths aligned around a single piece of technology, but rather
relish the chance to swap roles more frequently."
Oh were that the case. Truth be told, the IT world is so
tempest-tossed with "latestgreatestbestest" syndrome and a dire
lack of sensible, business-oriented, strategic planning, that no
modern IT worker even has the luxury of pursuing a "linear
career path".
I am merely 31. and in my ten-year career have gone back and
forth through a variety of roles and technologies. This was
never my own choice, however; it's always been "market
demands".
The truth is, technology decisions should always be secondary to
business decisions (and I mean real, not imagined "tech-aligned"
ones); those decisions should be focused and long-term; and
only then, rational technology choices based on those.
The long-current fad to chase after "latestgreatestbestest" is fed
mainly by ignorant top-level management and the salesforces
which seduce them. This myopic thinking, however, is standard
in modern American life, so I doubt it will be addressed easily
unless the culture itself changes.
I imagine most of the rank and file would relish the chance to
work on a technological platform in a stable fashion for many
years. The truth is, each and every technology has quirks,
plusses and minuses, and workarounds, and learning all of that
takes energy and time.
In sum, although they don't talk about "internet time" anymore,
the modern, harried IT worker certainly needs to think in
"internet time", like it or not.
desiring breadth of experience and exposure has less to do with
any innate desire to be a jack-of-all-trades, and more the modern
labor insecurity which leads to a fear of being instantly obsoleted
by a change in technology direction by either their employer or
their industry...
Right now, you have to rewrite COBOL programs module-by-module, which is a major pain. This way you could convert a small number of lines at a time, while still being able to compile and run your project.
If your think that people will tolerate COBOL code forever, you have a very sad future business model. You had best get ahead of the curve (which is a future without COBOL), and profit from the transition.
Try selling a record-based i/o library for C#/.NET that reads and writes flat text databases using XML to describe the layout. I'd buy that. But another crummy COBOL compiler for $3000? I already have one of those, and I'm only using it to transition the code to C. (Which also means I don't have to come up with an outrageous $20,000 for a runtime license!)
Good programmer can write contemporary program in Fortran 4 clear and nice.
For what functions/processes/applications?
Help, please be specific!
Talking about the shortage (or surplice) of mainframe skills is a waste of time if you don?t differentiate the specialties.
It takes 6 months to learn how to adequately program business applications in COBOL and 2 years to become proficient. With most COBOL business application programmers not due to retire for another 15 years, there IS no COBOL skills shortage ? unless companies artificially create one by making it an undesirable, low-paid, dead end job.
If companies like IBM and MicroFocus can keep COBOL up to speed as a high-level business language, it may remain the BEST modern business language. It is, for those who haven?t kept up to date, object-oriented and can handle XML and HTML. It?s exactly what is needed to code web services and business processes in a quick, cheap, reliable manner. That cannot be said of the various (semi-)scripting languages that are used by most young PC-trained programmers, such as Ruby, Perl and Python.
But when it comes to mainframes systems, we?re in a whole other ballpark. Programming at the systems level (never in COBOL) take decades to develop IF you have the talent. Those jobs are currently very highly paid (>$100,000) and the average ago is well over 50. With almost no-one (whatever IBM says) learning these skills, we really do have a crisis on our hands.
We could repair the business programmer shortage (if one ever arises) in short order. We can?t repair the systems skills shortage nearly so easily.
Mirel
http://www.accident-injury-compensation.co.uk/
- 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.
- Like this Reply to this comment
-
(19 Comments)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.
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).
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.
2) People need to understand COBOL's strength before they even suggest translating it.
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.
Imagine if you will a program, that has a line of code that says:
SUBTRACT LIABILITIES FROM ASSETS GIVING NETWORTH
vs...
n= a - l
which line do you think will be easier for a future programmer to understand a 1000 line programs logic.
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.
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
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.
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.
4) Mainframe technology is much more sophisticated and nuanced than what is atypically on midrange/mini systems:
ILM(information life cycle management) = DFHSM.... which has been around on the mainframes for 20+ years.
VMWARE/ZEN(hipervisors) = z/VM, which has been around for 20+ years.
Storage management = DFSMS...which has been around 20+ years.
cluster computing = sysplex computing, which has been around for 20+ years, midrange and mini's have not duplicated parallel sysplex(10+ years), yet.
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
'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.
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.
5) In anticipation of the implied COBOL skill shortage and the risk of a platform migration...IBM has put several modernization strategies in place.
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.
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.
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.