Breaking The Cycle Of Legacy IT Investment

CEOs and CFOs are often blind to the consequences of failing to modernize aging systems, says former US Air Force CIO William T. Lord.

Internet Of Things: 8 Cost-Cutting Ideas For Government

(Click image for larger view and slideshow.)

Each year, public and private sector organizations devote around 70% of their average IT budget to legacy software maintenance. This adds up to billions lost annually, stifled innovation, and IT departments under continuing pressure to "keep the lights on" instead of tackling new challenges and improving existing processes. High operating expenses make it nearly impossible for most organizations and government agencies to invest in new technology, leaving them further behind the curve each year.

Organizations left with less than a third of their IT budget to pursue new initiatives face a Catch-22: The significant risk of a botched software modernization project is enough to keep the government and private companies from attempting to overhaul their legacy systems.

Just look at the Air Force. Since shutting down its notorious Enterprise Combat Support System initiative (an attempt to upgrade part of USAF's dated logistics applications), the Air Force continues to maintain almost 20,000 legacy applications with no appetite to try another modernization project. Putting off system upgrades, however, only inflates the expenses posed by legacy programs' operational inefficiencies and security holes.

While it's often said that this year's IT investment becomes next year's maintenance expense, it's important to note that most legacy applications and the languages on which they are built are not just years, but decades, old. Even today, 70% of business transactions are processed in COBOL, a language designed in 1959 and patched in 2002.

Consider this: COBOL powers the overwhelming majority of modern business transactions, yet it was last updated just months after Windows XP was initially released. As the dated Microsoft operating system enters its last weeks of extended support -- at 12 years old -- COBOL is still being maintained at age 55.

(Photo: Leonardo Rizzi via Flickr)

The cost of applications written in ancient languages like COBOL and Assembler grow exponentially over time as the pool of students learning them and professionals versed in them shrinks. Only a quarter of colleges still teach COBOL, which creates a massive disparity between the expertise firms require and that which is available. Organizations using these aging applications are faced with the choice to either aggressively pursue a diminishing availability of talent as older workers retire, or invest in programs to train new workers in these languages. Either choice comes with a large investment in time and money attached to it.

COBOL and Assembler aren't the only languages feeding the vicious cycle of legacy IT spending; more languages will become obsolete over time. In light of the high-profile hacking incidents surrounding Target and Neiman Marcus, it is especially pertinent to note that dated systems are most vulnerable to these kinds of intrusions. The presence of "dead code" within an application makes it significantly easier for a third party to quietly implant malicious code within an organization's IT environment. Given that these attacks happen over time makes them more difficult to detect and can cost a business millions, if not billions, in damages.

The solution is obviously to modernize, but doing so can be difficult. While CIOs and CTOs are often aware of the significant challenges posed by the presence of legacy applications, CEOs and CFOs are often blind to the consequences of failure to modernize. This disconnect leads many organizations to waste money on contracts that fail to address the problem at hand. For businesses and government agencies planning to update their legacy software, here are two key considerations to keep in mind:

Take it slow. The dual forces of limited IT investment budgets and the need for business continuity throughout a technology overhaul means that any transition from legacy applications to more modern equivalents must be a gradual, phased one.

Get the right hands on deck. Due to the staggered nature of such a transition, it is imperative for organizations to ensure that they have the proper support for their legacy applications during the transition. This includes looping in subject matter experts who know which business rules within an application need to be modified or maintained in order to guarantee its functionality going forward.

While the cost of maintaining legacy software can be a hidden parasite draining the lifeblood of the IT department, it can be eradicated through a careful and thoughtful modernization project. Whereas the high costs of legacy application upkeep deprives the IT department of resources, the time and funds saved from a systems upgrade can be used to promote faster, more aggressive innovation throughout an organization.

Find out how a government program is putting cloud computing on the fast track to better security. Also in the Cloud Security issue of InformationWeek Government: Defense CIO Teri Takai on why FedRAMP helps everyone.

Retired Lieutenant General William T. Lord is the former CIO of the U.S. Air Force. He currently serves as a board member to EvolveWare, an IT solutions firm that develops tools which automate and modernize legacy IT infrastructure. View Full Bio

The 70% maintenance cost is a little misleading. It is better represented as the total cost of owning a software system. For any large software deployment, 70% or more of the total cost of the software is represented by maintenance costs. Think of it like buying a car. Once you have the car, in order to keep it running, you still need to put in fuel, buy new tires, etc. Over years or even decades the cost to maintain your car approaches or surpasses the initial cost to purchase it. For example, if you spend $50 per week on gas, over a decade you are approaching a 50/50 split based only on fuel costs ($26,000). Buying a completely new car might marginally improve your weekly outlay if -- and its a big if -- the car is more fuel efficient. Still, buying the new car means you're now putting gas (or hydrogen, or electricity) in a different car, not that you've removed the need for fuel. You can change the model by buying a new care every year, but that just adds to the acquisition cost, it doesn't really lower the maintenance costs. Software is the same. Replace it when the frame rusts, or the engine falls out, or there is a significantly better technology available; not because you're spending money on gas.

The author reasoning is flawed regarding COBOL being legacy software. The age of software does not automatically mean it is outdated (i.e., legacy software). Microsoft Word is over 30 years old. Does this mean it is outdate and not useful. Certainly not! The software has been routinely updated and improved and most businesses rely on it every day. This is true with COBOL. COBOL today is as powerful and robust as any other language. It is fully supported in Microsoft .NET. In fact, where other languages can only be considered 3rd generation languages COBOL has advance beyond this label. 4th Generation languages such a SQL adopted many of the attributes of COBOL such as writing code in plain English and not having end line punctuation. No other language matches the simplicity and the self-documenting nature of SQL or the COBOL language. Every time I introduce the COBOL language to programmers who were trained in other languages they often remark how simple and straight forward it is compared to the language they are currently using. Some have even stated that the colleges are doing a disservice to the industry not teaching COBOL. Some have said the many people drop out of programming because of the complexity of the languages they are teaching. The real problem is our education system. Our education system needs to develop curriculum that matches the needs of the industry.

Clearly Mr Lord is out of touch with the current state of the COBOL language. A little time and research would have shown COBOL is alive and evolving on an annual basis as venords and standr committees continue to add new features and functionality.

Modernization is the world I live in every day, with customers both in the large government and corporate arenas. This article is right on, as is your point above. The only people really interested in keeping legacy systems in place are the ones either controlling or tied to them skillwise- or making money off them as a vendor.

I believe that the "update" that was being spoken of in the article was the 2002 Standard for the language. There is another release of the standard pending and should be finalized this year. So we will have COBOL 2014. COBOL as a language is evolving just as English as a language is evolving. Perhaps, as it is so old, we should abandon English for a new language - like Esperanto (Well that's old compared to English like Java is old compared to COBOL). Or how about Ebonics. That's a relatively new language - we can abandon English for that.

Different programming languages to tell computers what to do are like different spoken languages. Just becaue a language definition is old doesn't mean it's dead or not doing it's job. The points of the article make it clear that COBOL is doing the job. And it's doing it well. I create NEW COBOL code all the time, in modern systems not just legacy. There is COBOL behind web sites. COBOL running on PC's. COBOL running on mid range and mainframe systems. Even COBOL that runs on Linux, Unix and even OS/X.

It all gets turned into machine instructions. There's nothing "Wrong" with these systems that needs to be fixed. A rewrite and replacement is really a costly - very costly mistake. Rehosting might be more appropriate as the hardware at lower levels becomes more capable and I have helped many companies rehost their COBOL applications on other platforms. The business logic is sound. The programs are secure and bug free. Don't let the fact that the language is "old" scare you. There's nothing to be afraid of. COBOL is very much like English.

Gen. Lord makes some great observations here on how hard and how costly it can be to modernize legacy systems. The amount of time and investment that it would take to overhaul some of the government's massive old systems -- and the difficulty of counting on Congressional funding -- would deter even the most determined CIO. That "70% of business transactions are still processed in COBOL, a language designed in 1959 and patched in 2002" staggers the imagination.

Politics is problematic in enterprises, it must be worse in any GOV agency. We just did a survey on application consolidation, and 89% said they dealt with "user concern over consolidation, ranging from uneasiness to open resistance." No one wants to give up their secret-sauce application, it feels too much like ceding power.

Plus, users seem to view these efforts as arbitrary, and they may be right as 45% said there is no process for choosing which apps to cut — someone just makes a decision about what stays and what goes. (report is here.)

Do you have guidelines for how to overcome the political / perceived capriciousness problem?