Read the Original Article at http://www.informationweek.com/news/showArticle.jhtml?articleID=8700014
Rewriting Apps Works, But It Takes Detailed Business and Technical Knowledge
Five years ago, we managed to port all of our remaining legacy systems from our Data General MV's to IBM RS/6000 servers or Windows NT. The legacy application that went on Windows NT basically ported nicely from DG Cobol to AccuCobol with minimal coding changes. This gave us the breathing time to develop the skill sets to redo the applications, including transfer them to an Oracle environment or replace them with more current software. The legacy applications on the RS/6000 are in software that will relate to Oracle databases, so that the C-ISAM files can gradually be replaced by Oracle tables.
Remember, the biggest problem in moving from legacy to state of the art is the application-level logic, which can be very business-specific and even institution-specific, due to a number of factors, including unique aspects of the environment in which the institution resides. Rewriting legacy applications to utilize current platforms takes a detailed knowledge of, and experience, with the business as well as a knowledge of programming on the platform, particularly when the business, such as many in health care, requires its own level of technical expertise.
Stephen J. Levine, M.D.
Computer-Medical Liaison, Oklahoma Blood Institute
Switch From Cobol To COM System Paid Off
I work with a large national bank in Ireland. They have a 15-year-old, Cobol-based back-end system. It's hugely expensive to maintain and painfully slow to develop new products on.
Four years ago we installed a Teller Solution from FPSVoyager.com. They built the solution using their CBD Workbench (Component Based Development) and created a real-time pipe into our back-end system as well as supporting peripheral systems.
The project was a great success, and because everything that needs changing and maintaining is outside our back-end system, it's been a comparatively inexpensive system to run (less then 15%). We also have utilized their toolkit for other channels and completed an online account-access project in less then three months.
Business Development Director, First Active plc
Keep An Open Mind, Adapt, And Upgrade
I manage one of the "monsters in the basement" and I have no plans to replace it anytime soon. My monster is well-trained and going somewhere. We've upgraded the server hardware many times and have been able to integrate new concepts and technology on the box without having to start from scratch.
Telling a company to throw away 20 years of development efforts when its legacy solution is doing exactly what it was designed to do may be premature.
This is what we have done to keep up with technology:
I guess we're lucky that we're running on a stable platform that affords us these opportunities.
Any system that is managed well will work great today, or 10 years from today. The key is to keep an open mind and adapt to new technology opportunities.
Director of Administrative Computing, Southeastern Oklahoma State University
Enjoy The Journey
We're stuck with a legacy application built ASAP in 1993 (only 10 years old; that's not a very old legacy app from what I hear and read) that is mainly RPG on an IBM iSeries system. It keeps the business running, but as your article states, it sucks up most of the budget/time/effort in the department and constrains creativity.
I've been a paid professional software/systems developer for 17 years and I'm educated and certified. Here are my thoughts:
The root cause of our situation: Management didn't want to or couldn't make the investment required to create the return (functionality/robustness/flexibility) that it needed. Lesson: You can't have three people develop a system in three months in a vacuum because you've promised a date to a customer just to get the business, then expect that system to be agile (the latest overused management buzzword), robust, flexible, extensible, interoperable, low-maintenance, etc. There is no IBM business genie! Remember the oldest data-processing axiom: garbage in, garbage out.
What's needed is:
Most of all, enjoy! Life is a journey, not a destination!
Software Development Team Leader, Safeco Financial Institution Solutions
One Step Ahead
I spend most of my day teaching the world's future workers (high school, grades nine to 12) to use computers to the best of their ability. The rest of my day is spent maintaining a system of approximately 250 units, contained within four labs and 50-plus classrooms.
Until about a year ago, my primary concern was fighting "the monster," as you put it, head on. This meant getting the best equipment that our budget would allow. And like all other industries, our funds are less and our needs are more.
I was reading Code Of The Samurai: A Modern Translation Of The Bushido Shoshinshu Of Taira Shigesuke, translated by Thomas Cleary, during my last summer break, when I came across an interesting passage.
In the section "Horsemanship," there's a story about a warrior named Kakuganji. As the story goes: "A long time ago there was a warrior named Kakuganji, who worked for the establishment of the Murakami clan in Shin province; he was the commander of about three hundred horsemen, skilled archers among them. It was his practice to choose for his mounts horses that ordinary people generally rejected for bad coats. Instead of having his warriors practice on the training ground, he would lead them into the fields outside the castle, fifty or even a hundred horsemen at a time, Kakuganji himself in the lead. They would gallop this way and that over the plains, now seeming to fall off only to make a flying mount, now seeming mounted only to make a flying dismount, maneuvering so freely that they became famous as expert riders. Because of this, in those days even the Takeda clan of Kai province was wary of an opponent as redoubtable as Kakuganji of Shin province. This was very much to Kakuganji's credit."
Now I understand that we are not in feudal Japan, but the story spoke volumes to me. I returned to school at the end of the break with a new idea: It's not the best computers that keep the business running but the way in which we use them.
I resolved to slowly upgrade older units. I may not be able to get the biggest toys, but I'll have enough toys to keep everyone happy. I also have made strides to train our staff and students on the most effective use of the technology that we have available. Because ultimately, a sports car is no fun if you can't drive a clutch.
I guess you could say that I fight the monster by slowly staying one step ahead of it and by keeping my people capable of using it, as opposed to fearing it. This may not work for all business, and I understand that, but for us it seems to be working.
Computer Science Instructor/Systems Administrator, Northern Garrett High School
Heavy Lifting Ahead Of Time Paid Off In ERP Move
We replaced our legacy Manufacturing Resource Planning (MRP II) system with a new ERP system more than three years ago. We took all the business data that our different departments identified as being even possibly needed for future use, and archived copies of that from the old proprietary database into our Oracle database. Then we wrote applications in our new ERP system to view this archived data, so, to our users, the legacy data is still all intact and is viewed much like the current, active ERP system data.
A great deal of effort was involved in identifying data to archive, interviewing departments, writing extract programs, and finally writing the new applications to view this archived data. We now, however, have only our current ERP system, with a common interface for all users and all data.
Programmer/Analyst, Wagstaff Inc.
Donate Legacy Systems
I feel that the only good solution would be to donate these legacy systems to schools, charities, and other nonprofit organizations.
This would give you a tasty little tax write-off, while improving your corporate image (something everyone could use given the horrible public view of corporate America in these troubling times of downsizing, scandals, and poor stock performances). Then, use the tax savings to offset the cost of improvements, and you'll get a quick and significant return on investment.
Michael E. Tibbs Jr.
VAR and IT/IS Consultant, Managed Computer Systems of Indianapolis