 |
|
|
|
 Is
Legacy a Monster or an old friend? Are older systems beasts that suck
up time and money, or productive elements of your company? InformationWeek
readers had a variety of opinions in reponse to Bob Evans' column,
"The Monster In The Basement". Many of
you agreed that the Legacy Monster needs to be slain, while others
disagreed, saying that Legacy
is a well-fed, useful member of the company. Some of you shared your
ideas on solutions to the Legacy
issue, and some vendors checked
into tell us what they're offering to combat the problem.
As promised, our most-interesting entries will receive a copy of the latest InformationWeek report on real-time business. To send your thoughts on the Legacy Monster, go to informationweek.com/932/form.htm.
Also, in case you missed them last week....
|
|
|
BEST OF...
WEEK OF
APRIL 7, 2003
|
|
Horse Sense
I look at Legacy less like a monster and more like the horse pulling the delivery wagon. It could be replaced with a less-expensive alternative, but one isn't available.
When horses were replaced in the last century, some were replaced immediately with new trucks, while others were replaced later with used trucks. For some, this happened not when the truck would make the owner more money, but only when the used truck became a less-expensive alternative.
In this century, replacing the old horse called Legacy is different. Used business software isn't available, only new software. Some are small, others are big, but all solutions may be more expensive than some can afford. So Legacy will be around until it doesn't meet basic business needs--only then will new software be considered. If the year 2000 didn't kill Legacy, what can?
A question to business leaders could be: If you're not replacing your legacy systems now, what events in the future would cause you to replace them?
Scott Hess
Programmer Analyst II, Clark County, Nev.
Refocus On The Basics
Monsters are in the eyes of the beholders. There's no free lunch in application development, no silver bullets, just the next budget-eating application.
Why does this happen? Poor business direction, poor requirements, lack of solid methodology, perhaps no vision.
In our attempts to move to cheaper, more cost-efficient platforms, we now struggle with security, configuration, and compatibility problems. Deployment and versioning issues are always present, and quality has taken a hit.
When you find yourself struggling in the ballgame, you need to step back and refocus on the basics. What really makes an organization successful? Its use of methodology. In the race to develop cheaper, faster, better-looking applications, we as an industry have lost focus. It's time to return to the basics.
Al Olson
Powerful Mainframe
Without our mainframe, we wouldn't be here. What I've seen is that people know what operating system people like.
In other words, the PC started another branch or method of processing information that was more fun and looked prettier--and most people, if interested, could get one. So in this environment, the technology flourished as it should.
However, many of the lessons learned from the mainframe, such as nightly backups, security, and redundancy, were neglected because of all the fun we were having, and many got "burned." Hence, it took longer for the PC to mature than most thought, leaving the mainframe to make a rebound and come to the rescue of many organizations.
Nowadays, managers and executives alike are wary in many cases not to jump on the proverbial bandwagon of technology too soon.
The mainframe may seem like a dinosaur, but in this case it's a dinosaur that's not extinct. That's power.
Stephen Kneipp
Mainframe CICS Programmer, Howard Computers
Wag The Dog
More than a decade ago, I worked at a big mainframe shop that supported GM Truck and Bus. One of the things that was a big drag on productivity and innovation was the constantly shifting infrastructure back at the data-processing center. Just when a person mastered one job-control system, file-version control system, or file-processing application, the guys back in Plano would "shake the bag" to save a few cents on operations costs.
Text-based menus and commands take a good six to nine months to master. Changing support systems every six to 12 months wastes the maintenance programmer's time. So much thought and energy goes into mastering the new tools, improvements that might otherwise happen to the system being maintained go out the window. Previously routine tasks take extra time and effort for many months before mastery of the infrastructure catches up to original levels.
When the tail is constantly wagging the dog, you get one sick puppy.
Alex Nestor
Webmaster, University of Texas at Dallas
Do you have legacy issues? Let us know here.
|
|
|
|
