Rewriting Apps Works, But It Takes Detailed Business and Technical Knowledge
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.
Switch From Cobol To COM System Paid Off
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.
Keep An Open Mind, Adapt, And Upgrade
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.
Enjoy The Journey
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!
One Step Ahead
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.
Heavy Lifting Ahead Of Time Paid Off In ERP Move
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.
Donate Legacy Systems
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.
Do you have legacy issues? Let us know here.
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.
Stephen J. Levine, M.D.
Computer-Medical Liaison, Oklahoma Blood Institute
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.
Adrian Walsh
Business Development Director, First Active plc
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.
Dan Moore
Director of Administrative Computing, Southeastern Oklahoma State University
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.
Christian Eidsmoe
Software Development Team Leader, Safeco Financial Institution Solutions
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.
Joshua Grove
Computer Science Instructor/Systems Administrator, Northern Garrett High School
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.
Don Sauve
Programmer/Analyst, Wagstaff Inc.
I feel that the only good solution would be to donate these legacy systems to schools, charities, and other nonprofit organizations.
Michael E. Tibbs Jr.
VAR and IT/IS Consultant, Managed Computer Systems of Indianapolis
Lowes seeking Information Security Analyst II in North Wilkesboro, NC
United Nations Foundation seeking Systems Administrator in Washington, DC
World Book seeking Java Technical Lead in Chicago, IL
Advanced Workstations in Education seeking Software Developer in Chester, PA
Silicon Labs seeking Automotive Market Segment Director in Austin, TX
For more great jobs, career-related news, features and services, please visit our Career Center.
Best Practices for Migrating from Lotus Notes to Microsoft Exchange and SharePoint
Many organizations are migrating from IBM Lotus Notes to Microsoft Exchange and SharePoint for a number of reasons: Microsoft’s rich and varied features, the business value of becoming a Microsoft partner and the high availability of IT staff trained on Microsoft technology. But these migrations aren’t easy – they’re long, complex and expensive. Careful planning and execution are a must.
In the new technical brief, “Best Practices for Migrating from Lotus Notes to Microsoft Exchange and SharePoint,” see how Quest Software has the tools you need for a successful, cost-effective and on-schedule migration. And once the migration is finished, learn how Quest solutions partner with native Microsoft tools to ensure high performance and reliability. Read the technical brief today.

NOTE: Offer valid for U.S., U.S. possessions, & Canada only