If Ain't Broke, Don't Fix It
"Legacy application monsters" is one term.
Another term is "that which is working."
I'm not sure I understand what you're talking about. Of course, we have legacy systems, but we cannot get rid of them. We still use them, and they are functional. Yes, we have to pay maintenance fees every year, but updates and support are necessary. Even some of our older applications that aren't supported are still functional and more than adequate.
Why spend money and resources to be up to date when you gain no real benefits? We are a midsize company and cannot spend just to keep up with the Joneses. These applications are not tying us down, and we do review and upgrade where necessary.
I know the trade publications are all pushing real-time business, B-to-B, E-commerce, and so on, but the reality--at least for companies our size--is that these are unrealistic. If it's working and getting the job done effectively, why change? This is why many companies are still using older operating systems. Check polls and you will see that many companies are in the same boat.
Network Administrator, HFI
Slaying The Monster Is Just The Beginning
It isn't hard to slay this monster if we don't mind getting the job done. We can increase how much money we're spending on future developments. If we're successful and those future developments become "that which is working," they will be the monsters we will need to destroy. This is all fun for the IS staff, but then we have the hard part.
Persuading the business that it doesn't need "that which is working," but instead needs "that which we will have fun making," will keep us busy, make us feel important, but doesn't work yet."
IT Professional, University of Colorado
Business Before Technology
I wish the Secret CIO's contention that "Technology comes last, not first" ("Information Alone Isn't Business Intelligence," Oct. 21, p. 108) was the mantra for the re-evaluation of technology deployments that everyone seems to be talking about. I preach to my clients that the business must come first.
Consultant, Mill Wheel Consulting, Portsmouth, N.H.
Outsourcing Is Killing Legacy
Legacy systems aren't the monster you claim. In fact, they're needed to keep parts of our business running 24-by-365. For example, we've got OpenVMS systems (both VAX and Alpha) that haven't been rebooted since we loaded the mandatory Y2K patches in the fall of 1999. (As an aside, very critical systems are clustered, which means that individual nodes can be taken down for maintenance and/or upgrades while the current transaction load is being handled by remaining nodes.)
Meanwhile, the vendors of newer Unix and Oracle-based systems recommend a reboot once a month just to keep the internals clean. This might be all right for a retail Web site, but it's no good for critical systems used in law enforcement, banking, telephony, power generation, etc.
The biggest problem with some legacy systems occurs when code maintenance is outsourced to companies staffed with younger people who are only trained to work on the newer technology. These systems tend to die a slow death while legacy systems not outsourced are alive and well.
Programmer/Analyst, Bell Canada
I've heard the term "legacy application" defined as any piece of software that actually works. I don't see why it's bad to spend 80% of your operating budget on the systems that are actually delivering the information services that enable your company to function.
Actually, it would make sense for 100% of the operating budget to be spent on operations. We put new development and infrastructure improvements under a different budget heading.
Do you have legacy issues? Let us know here.
Learn From Past Mistakes
What worries me is that the old stuff works. What makes you think that the new stuff won't cost more to produce and also work very well besides?
From what I've seen, the younger programmers who disdain the old stuff seem to be repeating the mistakes we learned to avoid long ago. Whoever heard of memory buffer overflow being able to execute code out of the allocated area on legacy systems? This is the source of most of the damaging viruses in recent history. We learned to avoid this stuff in the '60s. And the code worked so well, they're still using it!
James T. Budelman
One Size Doesn't Fit All
Calling legacy applications a "foul and dangerous monster" is provocative, but not entirely accurate. In the financial-services industry, the other name CTOs use for legacy is "the stuff that works."
It isn't a question of legacy versus cutting edge. The question financial-services firms and, more specifically for our client base, investment-management firms are asking is where can they wring out savings (operational, technology) and risk (investment, operational, compliance, vendor). The pertinent, if somewhat overused, goal is straight-through processing.
We believe the appropriate approach is to evaluate existing systems and operations in context of each firm's business drivers, and then create a strategy to solve the prioritized gaps with a "right-sized" systems-architecture strategy. That strategy may include replacing legacy applications with either new systems or service providers, or it may target incremental improvements.
There's no single answer that is right for every organization.
The studies deriding the spending on maintaining legacy applications confuse cause and effect. The effect of spending a larger percent to support "the stuff that works" is caused by reduced overall budgets. A cost-benefit analysis should support a strategic or tactical operations- or systems-improvement project, and it would account for any legacy maintenance savings in conjunction with a five-year projection of new license, subscription, maintenance, hardware, support, and implementation costs.
Managing Director, InvestTech Systems Consulting
Ease Of Administration
I have a very different perspective on what you term the "legacy monster." While the Wintel world has made great strides in reliability during the last few years, it's still a fact that no Windows system can touch some of the "legacy" systems for reliability and administrators per user. In fact, the improvement in the connectivity and usability of the AS/400-iSeries "legacy" platform far outweighs any reliability gains that Windows has made over the same period.
Consider this example: In a recent job, I had one customer who had more than 2,000 high-density (call-center) users accessing an enterprise application via a single large AS/400. Would you like to venture a guess as to how many administrators it took to cover all 2,000-plus enterprise users? One full time, and one part time. Seriously. That should give pause to anyone who has ever had to plan the budget for an IT department.
My point is that those who lament legacy systems most likely fall into one of two categories:
In either case, for every example you could give me of a "legacy" AS/400 chewing up more than its share of IT resources, I could find you 20 cases that demonstrate exactly the opposite.
I have more of a question. What exactly is a legacy system?
We have some very talented people working on new systems that allow us to look at our business data in new ways. But once these systems go into production, guess what they are? Yup, legacy stuff. We have some long-lived systems that are very good, and we have some new "innovations" that are crap. The inverse is also true. My job requires that I make all the systems work together in a manner that allows us to do our business. I do not get paid to think up glib word play.
Senior Systems Programmer, Idaho Transportation Department
There's more to the problem than meets the eye for many industry segments now than before. Recent legislation, such as HIPAA and the Sarbanes-Oxley and Gramm-Leach-Bliley acts require certain industry segments to maintain information (and consistent accessibility to the information) for extended periods of time. So the question now becomes one of the need for successful migration of legacy data into newer systems.
The focus needs to shift from proactive rather than reactive migration, making the move away from legacy systems and applications less painful and more readily achievable. There seems to be less consideration being given to emulation as an answer to this problem now, simply because it extends the need for individuals who are familiar with the legacy applications brought forward with the data. More and more, businesses are looking for solutions that include the ability to successfully convert/migrate the information in a non-application-dependent form.
Additionally, organizations are finally looking at their business practices, especially records and information management, and beginning to ensure that records-retention policies are in place to maintain access to information pertinent to their operations for appropriate time frames. Some of these are dictated by laws, regulations, or statutes; others are just good business practices.
Given the disasters related to failure to maintain sufficient records over the past two years (Enron, Tyco, Arthur Andersen, WorldCom, etc.) and the disastrous effects of not managing E-mail in the financial-services sector (Goldman Sachs, Morgan Stanley, Salomon Smith Barney, Deutsche Bank, etc.) along with the bad light cast on the FBI and CIA for not being able to gain access to information before the Sept. 11, 2001, attack (legacy systems and inability to access data within different offices of the same agency) I hope the focus is no longer on "slaying legacy monsters" but rather on capturing and proactively migrating legacy information.
Senior Records Administrator
Legacy Is No Monster
We have no legacy monster to slay. Our organization's legacy applications on CICS and DB2 have the most uptime, fewest bugs, and lowest costs of our total base of applications. The Microsoft-based applications are far and away the most burdensome in both manpower and money.
Technical Services Supervisor, Louisiana Department of Social Services