Saying Farewell to Ol' Faithful

By Sue Bushell
May 5, 2005

Article URL: http://www.cio.com.au/index.php/id;1206751897;fp;16;fpid;0

There's so much risk and expense associated with replacing a legacy system that it usually takes serious problems to force the issue, but the longer CIOs wait to make that decision, the more difficult it will be for their organizations to make the transition smoothly.

Love them or loathe them, legacy systems just seem to hang around like - depending on how much grief they are giving you - either that arthritic yet much loved and ever faithful old dog or an extremely unpleasant and persistent smell.

"Today, many organizations rely heavily on critical back-end applications that reside on legacy systems," says Jim Rhyne, distinguished engineer and lead architect, eServer Tools Technology and Enterprise Transformation at IBM. "Even after 35 years legacy systems are still the technology foundation of the majority of the world's largest companies. In fact, legacy systems have been called the modern-day equivalent of buried treasure: Hidden in back rooms and locked behind proprietary code is a wealth of information that could be used to support e-business strategies."

However, while some legacy systems seem to have been blessed with the secret of immortality, even the most conservative IT organization eventually reaches the point where it can no longer deny that select ancient systems are on their last legs and must be redesigned and replaced. And since software systems do not wear out, and since many legacy systems can appear to be operating like sterling workhorses while actually running like dogs, that realization can sometimes hit well after the point where the transition might be made easily and relatively risk-free.

"For decades, various IT gurus have predicted the demise of the mainframe and the need to rewrite - or 'replatform' - core applications," notes Ken Orr, fellow, Cutter Business Technology Council.

"Years later, many, if not most, of these applications continue to perform their required function 24x7x365. This lulled many organizations into the position that it was simply impossible to rewrite many mission-critical applications and that the best one could do was make minor changes around the edges of these applications. Moreover, many of those who know the most about these applications are approaching retirement, so they are reluctant to take on the task of rewriting code and prefer simply to continue applying life support," Orr says.

In the world of the ageing workforce, many highly knowledgeable employees use their knowledge as the ultimate form of job security, which is no small thing in this world of uncertainty, Orr says. Against a backdrop of casual work and mounting job insecurity, who can blame them for wanting to leverage the maxim about knowledge being power? After all, take away their legacy systems and plenty of organizations would flounder.

Yet even the most backward IT organization recognizes that some systems eventually must be redesigned and replaced, Orr says. It is just that it cannot be done overnight, the transition can cost a small fortune, and it can be extremely difficult to recognize the risks upfront.

The fact is, legacy systems are brittle, inflexible and impenetrable, and they are still around in their multitudes. And they spell R-I-S-K - presenting risks to the organizations that keep them, particularly by way of strategic business risks associated with their expense and inflexibility, but also risks to those attempting to modernize them. Their modernization is a problematic and uncertain process that many organizations will undertake at some stage during their lifetime.

The dilemma is compounded by the phenomenal cost of replacing a legacy system, or migrating off such a system, which can run into millions of dollars. Unsurprisingly, many companies try to change their legacy systems incrementally to spread the cost. Knowing they must provide customers and employees with access to data stored in legacy systems via the Internet, but recognizing legacy systems are not "Internet compatible", leaves many IT organizations facing the question of extending their legacy system or scrapping it in favour of a whole new system.

"Legacy information systems are a phenomenon experienced by virtually every enterprise. These systems, which may have been present in the organization for as long as 30 or 40 years, are stable, but inflexible, and made brittle by years of ad hoc maintenance and enhancements," note David Warrell and Kenneth J Stevens from the University of New South Wales's Security, E-Business, Assurance Research Group, in a paper called Towards an Understanding of Risk Management in Legacy Information Systems Modernizations.

"This brittleness and inflexibility makes legacy systems difficult and expensive to maintain. It has been reported that, on average, 60 to 80 percent of IT budgets are spent on maintaining legacy applications and the mainframe systems they run on . . . Previous studies put the figure at between 50 and 70 percent . . . suggesting that the expense of maintaining these systems is growing as they continue to age," the authors note.

Yet there is a discouraging lack of maturity surrounding legacy management within most organizations. A Financial Executives Research Foundation (FERF) research project published in the US last September found legacy management was a key issue for 63 percent of the companies surveyed, with companies with less than $100 million in revenues the least likely to view it as a key issue. But the researchers found while 71 percent of participants have established an application portfolio, these were regularly updated and maintained by only 40 percent - indicating that for most companies, updating the legacy portfolio is connected to other initiatives and is not yet a consistent management process.

"Legacy management is not about managing costs, but primarily about managing service delivery and value," the report noted. "Legacy management is still an immature process for most organizations. Although many of the study participants have the components of a legacy management practice (management's attention, application portfolio, and assessment criteria) we still don't consider many of these companies as having an appropriately mature legacy management practice. For most of the companies surveyed, legacy management remains an irregular or ad hoc process."

Ready or Not

William Walton Sr, a consultant with Cutter Consortium and the US-based The Beta Group, says some companies are finally forced to the realization that they must perform legacy migration or renewal only when "hit over the head" by circumstances, such as a vendor deciding to withdraw support.

When that does not happen, organizations are likely to consider risk elements, particularly concerning technology and support issues, around the maintaining of legacy systems in the context of regular application upgrades. "In these instances they are more importantly looking at business risk when the applications are no longer able to support the process in a positive way. We're starting to see more organizations starting to do that kind of regular assessment of their applications," Walton says.

The difficulty is that for many organizations, the true size and scope of such risks remains relatively opaque.

In their paper, Warrell and Stevens note that organizations can take a number of different approaches to modernizing a legacy information system, ranging from a "simple updating" of the existing system to its wholesale replacement. However, they find little has been written about the problems and risks that relate specifically to these different legacy information system modernization approaches.

"Understanding these risks would seem important for project managers when managing modernization projects and also for decision makers when deciding which approach is most appropriate for a particular project," they write. Their 2003 paper outlined the initial stages of a research project to identify, understand and assess the risks involved in both the modernization process itself and the ongoing use of the modernized system across these various types of legacy system modernization. That work was never completed, Stevens says. What did become clear was that whether risk management was used to manage the risks of the modernization project was more a function of organizational comfort with risk management than of the perceived project risks.

"If someone doing the project was used to using risk management, then they used risk management in their project," he says. "So the key finding is that risk management practices had very little to do with the risk of the legacy system per se but rather how comfortable the person was in doing risk management approaches, and the extent to which the various stakeholders suggested that risk management might be something that they needed to look at that," Stevens told CIO.

By understanding the role that risk plays in the legacy system modernization process, legacy system stakeholders' awareness of risk can be enhanced. As a result, top management can take risk into account when deciding which legacy information system modernization approach is the most appropriate, and project managers can adapt their risk management approach to the risk profile of the selected approach. This should ultimately lead to more successful legacy system modernization projects, the authors say.

Finding a Sponsor

For Mark Barrett, Australian Broadcasting Corporation (ABC) manager of corporate IT projects, finding a corporate sponsor was the vital first step in the organization's legacy migration and a key to minimizing risks. "The technology group in the ABC took ownership of it because as a system that covered all business areas, the default arrangement here is that a common system tends to be owned by the technology group," Barrett says.

The ABC is in the process of decommissioning four VAX systems from the former Digital Equipment Corporation (DEC) after close to 20 years of mission-critical service, in favour of commodity Intel machines, due to dwindling support and rising maintenance costs, a desire to leverage more modern mail and messaging services and a host of interoperability issues. Barrett says minimizing the risks involved in migrating users off the older e-mail and messaging environments revolved around ensuring the ABC had a clear migration plan and in avoiding a big bang approach. Users were migrated in groups to ensure an adequate level of support was available at all times.

The ABC also provided comprehensive documentation and user guides, and gave focused support to each group during the transition. Barrett says detailed planning, and getting agreement on the environment, features and how the project was going to create value, were all crucial to the success of the project to date.

"We also had to understand our architecture and make decisions about how we were going to deploy the new system architecturally to ensure that we had the capacity to support the number of mailboxes that we had and the general way that we wanted to administer it, for instance from a technical point of view," he says.

The ABC approach is consistent with advice from Cutter's Orr, who advises clients that before planning any migration they should develop an overall enterprise architecture.

"The enterprise architecture is a basic set of plans and metadata that describes all the critical business processes, applications, databases and technologies that an organization has, or will employ. Legacy migration must be considered just a part of this general framework. Start immediately," he says. "Develop an inventory of all your applications. Don't get caught in the trap of defining things as legacy versus non-legacy. Everything that is running is legacy!"

Orr also urges organizations to identify all the critical applications and their vulnerabilities, noting the average large organization's IT inventory often has thousands of applications, but typically a much smaller percentage - roughly 20 percent - are truly critical to the business. "Organizations must be clear about exactly which systems are critical and their real status. IT management should be responsible for conducting - or having another organization conduct - an application 'health check'."

Time to Move On

Like the ABC, and also after 20 years of mainframe computing, the Seven Network had reduced TCO and enhanced flexibility as major drivers when it last year switched off the last mainframe used to control its network television system.

Project manager David Checkley says the Seven Network Television System application had not outlived its usefulness, and was in fact a key component of Seven's IT systems. However, towards the end of the outsourcing agreement that had hosted and managed this system, Checkley says Seven decided to migrate the application from the outsourced mainframe to an in-house Unix platform in order to lower costs and to position the company to be able to quickly address future broadcasting requirements.

"We maintained an inventory of the components of the application, which were all migrated. There was never any thought of legacy or non-legacy. Either the application was necessary for the company's requirements or not. Once that decision was made we just got on with the job of migration," he says.

Checkley says the Seven Network built on a small team for the migration and subsequent in-house support. "Seven migrated its Network Television System in eight months," he says. "Because we were insourcing, part of the planning was to ensure new staff came on board early, in order to have sufficient knowledge of the application before they were required to support it."

Repetitive test migrations, as well as checking the integrity of the migration, gave Seven accurate migration timings as well as the confidence that things would work in the production implementation, he says.

No Time for Downtime

When performing system, application or data migrations, IT managers often realize very quickly that bridging the gap between the old and new is going to present some challenges. And in this day and age, system outages are unacceptable, says Tim Rathbun, executive vice president, marketing and product management for GoldenGate Software.

"For example, one of our customers urgently needed to upgrade to an Oracle-based supply chain system. They are a $1.2 billion consumer health-care business. After running the numbers, they realized that if there was an outage and their production capability went offline, they would lose about $47,000 a minute."

The key, Rathbun says, is to manage the cutover in a way that minimizes or, even better, eliminates downtime. He says organizations must keep production databases completely accessible during the migration. This allows production systems to continue to run, ensuring that there is no loss in business opportunity and resulting revenue, regardless of the size or number of databases to be migrated. He says a contingency plan should be an integral part of any migration.

"Should you encounter any issues, it is absolutely essential that you have the ability to immediately revert back to the old system to enable your business to continue to function," he says. "However, it is absolutely essential that both databases are synchronized bi-directionally in real time. If this is not the case, even if your migration tools enable you to revert back to the old system in a timely manner, the data processed against the new database will not be reflected in the old database."

Rathbun says this resulting inconsistency could prove costly, with inaccurate data conceivably preventing a successful fallback to the old system.

An organization's best chance of minimizing legacy migration risks is in avoiding risks like these.

More Reading

Web Sites
DoD Legacy System Migration Guidelines

www.sei.cmu.edu/publications/documents/99.reports/99tn013/99tn013chap02.html

Using lessons learned from previous re-engineering work, the guidelines presented here can provide a starting point for ensuring that migration projects attain their goals.

Enterprise Framework for the Disciplined Evolution of Legacy Systems

www.sei.cmu.edu/publications/documents/97.reports/97tr007/97tr007abstract.html

This report describes an enterprise framework that characterizes the global environment in which system evolution takes place and provides insight into the activities, processes, and work products that shape the disciplined evolution of legacy systems.

Incremental Modernization for Legacy Systems

www.sei.cmu.edu/publications/documents/01.reports/01tn006.html

This report shows an objective technique for developing an incremental code-migration strategy for large legacy Common Business-Oriented Language (Cobol) systems. Specifically, it describes a case study that involves the modernization of a large Supply System (SS). The system consists of approximately 2 million lines of Cobol code operating in a mainframe environment.

Tactical Strategy Group: The System Transformation Portal

www.systemtransformation.com/index.htm

This portal was designed for business and IT leaders who need to address the systemic transformation of information management from an organizational and architectural standpoint. You can also download the latest Appendix A update to William Ulrich's book Legacy Systems: Transformation Strategies (see below). This new Appendix contains many new tool and vendor listings for performing modernization work on existing systems.

Books

Modernizing Legacy Systems: Software Technologies, Engineering Processes, and Business Practices

By Robert Seacord, Daniel Plakosh, Grace Lewis

Published by Addison Wesley Professional Legacy Systems: Transformation Strategies

By William Ulrich

Published by Prentice Hall PTR

A Legacy of Transition

Replacing your legacy systems is the ideal time to introduce some positive new changes to your enterprise

The risks inherent in legacy data management systems are a problem that California-based Sherwood Partners runs into all the time in dealing with mergers and acquisitions and corporate turnarounds, says co-founder Marty Pichinson. Whether you are trying to merge two disparate sales databases or inventory tracking systems as part of mergers and acquisitions, or whether you are trying to determine if your existing system is robust enough to handle your growth strategy, the considerations are pretty much the same, he says. This is an opportunity for positive change, and it needs to be managed with growth in mind.

In assessing the best approach to make a positive change, Pichinson says, you need to balance four key factors: people, process, cost, future needs and implementation.

People: You need to find the right strategic stakeholders and then make staffing decisions based on your findings. Are the current IT staff right for the job? Do you need to retrain or rehire?

Process: What's working and what's not working? Before you can determine what needs to be changed, you have to assess what is or is not broken and whether the broken information chains need to be repaired or replaced.

Cost: Do a cost analysis that includes an understanding of the infrastructure required and the lasting consequences on growth, staffing, and so on. If you are merging two companies and eliminating duplicate systems, work the sales cost of unneeded hardware into your analysis.

Implementation: How do you implement the new systems without losing continuity? This means determining what's critical, what's not, and developing a timeline and allocating areas of responsibility. Understand that when making this kind of transition, short-term costs may lead to long-term savings, and it may be just as expensive to integrate 1000 seats for a technological solution as it is to implement 2000.

To accomplish all this, Pichinson says, requires first and foremost that the organization elevate the decision above the IT level.

"Strategic decisions need to be made at an executive level in line with long-term goals, and all too often, the IT department looks at these kinds of transition discussions as tactical projects rather than a strategic opportunity for creative change," he says. "At all costs, you want to avoid having your IT staff make a wrong systems choice because it's a devil they know and understand. Remember, this can be the time and opportunity for change.

"Step two, you need to identify the stakeholders within the organization - or organizations if you are merging two companies - who will benefit most from the new system or will have to live with the legacy system. Establish a steering committee of key stakeholders whose success is tied to the outcome of transitioning from legacy systems. Use questionnaires and other means to determine what their needs really are, then build this information into a cost analysis of your current system and new systems you might consider."

The third step Pichinson suggests might be taken with a grain of salt given that his company provides pre- and post-merger integration consulting services. He says at this point it is worth getting a fresh perspective that will open new doors. CIOs can get outside help in gathering the right kind of information from stakeholders, and an outside consultant can help manage and assess the results. "You need that fresh perspective because even the executive stakeholders will be susceptible to becoming mired in the process, not the results, and someone outside the organization that can see the forest as well as the trees can help you find the right path to your goal," he says.

"When dealing with any kind of legacy transition, you need to be prepared to understand the entire scope of the impact of making a change. Are you making a transition to deal with an immediate problem or are you planning for strategic growth? Understanding where you are looking for a return is the first place to start," Pichinson says.

[back to In The News] | top of page