"...there are two other significant factors that can impede our progress. The first is the lack of interest among the millennium generation to work on older technologies and the second is the fact that within three years, 30 percent of our legacy application experts will be eligible for retirement."
Impede progress? By not wanting to "work on older technologies"? Um. Yeah. That's exactly the point - we non-gray-hairs want to work on something other than green screen! That *is* progress. Time for the execs to pay up for some modern systems and tools!
You're not gonna convince me that when "30% of our legacy app experts" retire, we *ought* to be just endlessly perpetuating systems as-is. *That* is the failure of CIOs to continuously reinvest in their infrastructure and systems. *That* is why we had a massive last-minute Y2K effort. We have become a culture of "reaping the benefits" and no longer want to put in the investment. I say this both in IT and the culture at large. We want the payout. We want to "feed at the trough". Someone has to pay for it.
Top five issues your IT staff wants to address but is afraid to tell you
Summary
If you’re an IT manager or CIO, you may want to gather the troops before you begin the Web 2.0 modernization process as even the best laid plans can go awry says Nexaweb Technologies Jeremy Chone.
Topics
Commentary--The proliferation of enterprise Web 2.0 has created new and different demands on the IT staff that requires knowledge of traditional legacy skills such as COBOL, C and proprietary applications as well as more modern technologies. To maximize existing investments and embrace enterprise Web 2.0, IT is turning to application modernization technologies. However, if you’re an IT manager or CIO, you may want to gather the troops before you begin the modernization process as even the best laid plans can go awry. Following are the top five issues that your IT staff wants you to know before you begin…but is afraid to tell you.
1. There is no history of the code. It’s no secret that applications have evolved over the years as a result of vendor upgrades and customizations. As the applications continued to morph, tracking the changes and who was responsible for them fell off the list of priorities making unraveling the underlying code a bit challenging as enterprise Web 2.0 technologies are introduced.
2. We don’t know exactly how many applications we have or how they all work together. Applications make their way into organizations through procurement overrides, departmental purchases, trials, upgrades and, of course, open source. This treasure trove of technology makes an aerial view of the infrastructure nearly impossible to create and inhibits the ability to easily introduce new technologies because a lot of time and money is being allocated to maintaining redundant and/or bad code.
3. We’re actively seeking a new job. While it’s no secret that the average IT turnover rate is 22 percent*, there are two other significant factors that can impede our progress. The first is the lack of interest among the millennium generation to work on older technologies and the second is the fact that within three years, 30 percent of our legacy application experts will be eligible for retirement.
4. You can’t prove the ROI. Faster, stronger, cheaper are marketing terms. Show us what we’re likely to gain from the project in terms of skills, company cost savings and time savings using before and after metrics that are created and validated by a third party.
5. You need to share your vision. We know you engage in long term planning that anticipates what the next three, five or eight years will bring and we’d like to weigh in on the strategy because we have front-line knowledge that may affect your business and IT decisions.
While most IT organizations could likely add to this list, the real challenge--and a critical first step--for IT leaders is to address all issues at the onset of a new project so that realistic goals can be set and achieved.
biograpy
Jeremy Chone is chief technology officer for Nexaweb Technologies.
Talkback Most Recent of 20 Talkback(s)
-
techboy_z21st Aug 2008 -
But prove the ROI
But you shouldn't simply invest in "updated" software because its newer and better. You should be able to quantify how much this updated software is going to save/gain you compared to an estimated cost to implement/maintain.
For example, why replace an ASN 400 system that meets your needs with a Microsoft Server system that is more complicated?
Feldon21st Aug 2008 -
Change is not progress
Before I start, an important question: Do you buy a new car
every year? If the answer is yes, then there's no point
continuing this conversation.
Progress implies change, but the converse is not true.
Before upgrading anything, you need to understand what is
meant by "better" when you say that a "better" system is
available for purchase. Generally this means - will the new
system save money or even make money? How soon will it
pay back its purchase price? How soon will it pay back the
install/upgrade price?
larwe22nd Aug 2008 -
No...but...
...remember the "dog years" analogy. Tech compared to cars is like human vs. dog years. So...no, I don't buy a new car every year. But some of the systems companies still try to maintain/enhance are like driving your Model T Ford as your main car (vs. a once-a-year parade showing
techboy_z22nd Aug 2008 -
"If it ain't broke, don't fix it."
And especially don't replace it at huge expense.
How do you beat that argument?
And your success should not be: We can get rid of all these older people and continue with a much smaller staff of cheaper people.
Implicitly or explicitly, that means buying a standard package. And then the company pays a fortune to consultants tio regain lost functionality. Because the more experienced staff is already lost.
The executive who created this disaster has long since received a large bonus and been promoted for all the money he gained.
Anton Philidor22nd Aug 2008 -
I beat it like this...
"And especially don't replace it at huge expense.
How do you beat that argument?"
1) As those people get rarer, their cost goes way up.
2) Those old tools were not and still are not user friendly; by nature they are less productive to work with, compared to modern dev tools - IDEs with better user interfaces, debuggers, etc.
So, yes, there is some initial cost to rebuild a system, but over time, the availability of human resources saves money, and the increased productivity also saves money.techboy_z22nd Aug 2008 -
"... some initial cost to rebuild a system..."
So you replace the older software, presumably while retaining the more experienced/expensive staff, and promise that, over time, attrition and better performance and easier development will make money.
When time is measured in bonuses or surpluses/deficits, a large initial outlay is looked at askance. And the compensation must not only be quick, it must be definite. Otherwise, easier to do nothing except shave small amounts off contracts.
I read of a committee effort which produced a way to operate the existing system more efficiently (meaning fewer people) and to reorganize the way IT was accomplished. Both saved money, and the report was received with gratitude.
The people were laid off and the streamlining shelved. There was some difficulty actually accomplishing the plan that made the layoffs possible because it required some initial expenditure, but eventually a small portion of the IT savings were grudgingly freed up for IT.
More briefly, what you're discussing has far more to do with organizations than with software.Anton Philidor22nd Aug 2008 -
"If it breaks, can I fix it?"
So what's the other option? Run a system until it has run itself into the ground and can no longer be fixed? A smart CIO doesn't let the institutional knowledge go out the door with the staff.
I've seen more IT projects fail because the IT staff was afraid of being made irrelevant due to an upgrade. Will a COBOL programmer three years from retirement really get actively involved in upgrading a system knowing that the successful completion of the project will put his career in jeopardy so late in the game, even if it's in the company's best interest? Of course not!
So why should a company keep an "if it ain't broke, don't fix it" attitude? All that leads to is needless dependency on people being overpaid simply because their skill set is rare. Additionally, the company probably won't hire two COBOL programmers, so when this person gets sick, or gets hit by a bus, the company is screwed.
On top of all that, when you wait too long to upgrade systems, the upgrade path is either convoluted (e.g., upgrading through multiple software versions), or it simply can't be accomplished at all. In other words, the longer you wait, the harder and more expensive the upgrade will be. Every system will become obsolete, and "it ain't broke" is just not a compelling reason, because all that really means is "it ain't broke yet."
RationalGuy22nd Aug 2008 -
RE: Top five issues your IT staff wants to address but is afraid to tell you
"There is no history of the code"
The only thing worse than "no history" is having a history of the code without any real documentation of what the code is supposed to do. I have seen too many COBOL programs with decades of change notes at the top of the code, while there is absolutely no explanation of the reason for having the program at all.
JoeCotton21st Aug 2008 -
There is no history of the code
I mean, why should I care what changes were made to a CICS program in 1989?JoeCotton21st Aug 2008 -
History is needed...
History is needed... to understand the code before migrating the legacy application; you know, to rewrite them or just update them. Legacy apps have dark corners with code that nobody knows WHY was written. History MAY be invaluable.
Regards,
MV
MV_z22nd Aug 2008 -
You will need them.
Believe me. If you are working as a Software Developper and work on the very big and long lived product (1,000,000 LoC+). there will DEFINITELY be time when you say "what the **** was these crappy pile of ******** coded for?".You will definitely need to know why it has been done so that you won't mess any features up.
Dealing21st Aug 2008 -
RE: Top five issues your IT staff wants to address but is afraid to tell yo
We are actively seeking a new job all the time, because the moment there's a budget bump, you throw us all away like used Kleenex (R). We've all learned that trick. You need our knowledge, then you fail to see the value of institutional memory and jettison us with a "too bad, loser."
Then hiring managers want to know why we've had more than one job in the last 10 years.
Don't blame this on age, or "millennial" laziness. Don't tell me about retiring engineers. The reason they're gone is they got tossed out when they turned 40.
No, actually, the problem is more holistic than all of this. It's that you can't engineer a snowstorm, and that's what the last 50 years of IT has been: Flakes and wind and and promises of no more school. We in the industry have failed our calling.
We rely on size and complexity to somehow bring order to something human-sized and less complex. We believe financial metrics will provide some insight when all it does is allow us to make things more complex than ever, and less understandable.
This isn't among the top five issues. We all know there's something wrong. Not many are willing to ask the question "what if everything we're doing doesn't work?" So far, I've seen little evidence that, avionics, automobile engine management and entertainment aside, computers have done any more than raise expectations beyond the ability of human brains to span the result.
I am not a luddite, but I do know that paper is a technology too.
neimon22nd Aug 2008 -
And the top answer is: your short-sightedness is killing you (and us)
So-called leaders of companies have driven us insane with decisions that only consider the quarterly bonus, not the health and well-being of the company as a whole. And then people are SURPRISED when turnover is so high, productivity is impacted, and working relationships are strained.
I still deal with managers everyday who expect or demand loyalty from subordinates, but who have no concept of loyalty or honor in return. "You should be glad just to have a job" is the prevailing mentality. And they blindly put the secrets of the company into the hands of people upon they have heaped fear and abuse. Then they wonder why things "go wrong" and everybody is pointing the finger at everybody else.
I had a boss who told it like it is: "You are essentially an independent contractor, no matter what it says on your paycheck. Every day, you must prove your worth to the company. Every day, YOU must make the determination if the business relationship is right for YOU, because the company is doing exactly that from their point of view. The company is not your father, your friend, or your partner."
terry flores22nd Aug 2008 -
Where's the reference?
You said "22 percent*" ... are actively seeking employment....
If the * refers to a source, what is it?
IMHOYAAAH22nd Aug 2008
Talkback - Tell Us What You Think
The best of ZDNet, delivered
ZDNet Newsletters
Get the best of ZDNet delivered straight to your inbox
Facebook Activity
