The New Year is upon us -- along with the urge to make resolutions. Not for me, of course. I gave up the trying to improve myself a few years ago. This time I'm going to make resolutions for the IT industry. Besides, it gives me a chance to complain.
IT executive management
"We resolve to understand the true costs of offshore outsourcing."
On the surface, offshore outsourcing sounds like a good deal for the unabashedly avaricious who can save a lot of money. Companies with purer motives like to use consultants to manage the ebb and flow of project staffing while keeping the number of employees constant. But a deeper look often belies the purported savings. Here are some of the hidden problems and costs in offshore outsourcing:
- Dubious software quality: This can cause production problems that need to be fixed by higher paid staff.
- Training and re-training: When operations consultants are rotated to another client within a year the result is often a gap in training.
- Employee fear, uncertainty and doubt (FUD).
- Outsourcing usually involves a mix of consulting companies, each with their own objectives will sometimes conflict with yours.
I'm sure most offshore companies are honest and reputable. But even so, just be sure to write a very tight contract.
Independent Software Vendors (ISV)
"We resolve to come up with fair software pricing structures."
Back in an antediluvian age software vendors had an evil idea: The notion that a faster processor executes more instructions, thus using more software. Since then, ISVs incorporating this logic into their sales strategies continue to post higher earnings as their customers upgrade their hardware without the expense of enhancing, and in some cases fixing, their software.
That might have made sense when the mainframe was the only game in town. But now we have Windows and Unix aggressively marketed as "cheaper" platforms. In the meantime, people who support big iron are stuck with inexpensive hardware they can't afford to upgrade because the software costs too much. Something has to give -- and soon.
While we debate the total cost of ownership (TCO) of competing platforms, the bald fact of the matter is the smaller machines win because the software is cheaper and doesn't present a barrier to hardware upgrades. Perhaps this is what they mean by the buzzword, "nimble." So when they roll that last mainframe out the door you can be sure it was the ISV's that killed the goose that laid the golden egg.
IBM
"We resolve to pay attention to what our customers are actually saying."
IBM has come a long way from the closed, dictatorial company it was in the 1980's. But, now that IBM is much more responsive to the market, perhaps the pendulum has swung too far the other way. As a CICS systems programmer I know first hand how hard IBM has pushed the software into the 21st century and I congratulate them for it. However, all the web based enablement in the world isn't going to help me resolve record level sharing (RLS) locks, get me more ECSA or prevent the next Sysplex wide slowdown.
Maybe this year IBM can consolidate its position and go back and improve what the mainframe already does very well. I think CICS/TS 3.2 is a good example. The CICS/TS 3.2 developers took time to go back to make improvements in the unglamorous world of VSAM. I'm sure other people reading this column have more than a few suggestions for IBM.
Systems programmers
"We resolve to get out more."
Systems programmers, particularly old grouches such as me, tend to cocoon themselves in ivory towers. The view is nice and the height allows us to view mere mortals from above. It also gives us the solitude we need to contemplate deep technical issues and weigh involved workload dispatching algorithms.
We started building our towers back when we ran the computers and were allowed to work things at our own pace. Now the pace is set by the Internet, our business users and, by extension, our customers. We also have to deal with code hurriedly developed by overworked, harried application programmers too busy to do much more than throw this weeks' code release into production. But systems programmers need to help tackle these problems. It's also a chance for us to demystify the mainframe and share our point of view.
This is going to be a great year if everyone would just follow my sage-like advice. Somehow I don't think that will happen, though. Instead, I'll try to make this year better than the last with more of what I like about my job and less of what I can do without.
ABOUT THE AUTHOR: For 24 years, Robert Crawford has worked off and on as a CICS systems programmer. He is experienced in debugging and tuning applications and has written in COBOL, Assembler and C++ using VSAM, DLI and DB2.
