|
Mar 30, 2003 (07:03 PM EST)
Sounding Off About The Legacy Monster
Read the Original Article at InformationWeek
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.
|