This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
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. Adrian Walsh
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:
Add multiple Web servers to dispense real-time information for intranet and Internet users (Apache, Perl, Java--no IIS).
Add graphical terminal emulation capability, so point-and-click users can still talk to the mainframe.
Generate HTML-based E-mail reports that can be sent directly to a user's in-box (there's no interface to learn except the one they already know).
Add additional nodes for real-time data redundancy and disaster tolerance off-site.
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:
Commitment to an investment by management--without this, do not continue.
Ownership assigned specifically by upper management and a high degree of time investment from the business people who need the IS solution.
Skilled BSAs that can find and precisely define and communicate the essence of the necessary processes in concise written requirements, preferably using a software-development methodology like Rational Unified Process.
A group of experienced developers who are not embroiled in a platform/language war (IBM iSeries versus Microsoft versus Linux, RPG versus Java, etc.) to build it.
If you switch platforms/languages, don't make the mistake of using your current experienced staff of "legacy developers" that has kept the monster well fed to only keep feeding it while the new system is developed. These people have a ton of business knowledge and many times are more familiar with the pitfalls and areas where efficiency and synergy can be had than the business people are. Don't blame them for the legacy monster--they kept your company running within the framework they were given. (In our case, the company has made a ton of money from the legacy system and bought a competitor of the same size for cash, and has always been a "shining-star" unit to corporate.) In our case, the two architects of the legacy beast left after only a year and a half, and the manager who requested it and approved it bailed after it became apparent (seven years) that it was holding the company back and was sadly lacking from the start.
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
The State of IT & Cybersecurity Operations 2020Download this report from InformationWeek, in partnership with Dark Reading, to learn more about how today's IT operations teams work with cybersecurity operations, what technologies they are using, and how they communicate and share responsibility--or create risk by failing to do so. Get it now!