 |
|||
|
|||
|
Your 10-year-old Chevy may not look like much, but you rely on it to get you to work everyday. And with a kid going off to college next year, you're not inclined to pick up a new-car loan now. Well, somewhere between regular oil changes and the junkyard lies the key to keeping that car on the road. CIOs find themselves with a similar challenge as they manage a growing population of aging yet critical computer systems in an economic climate where resources are limited. They're scrambling to address the growing "legacy crisis" that is tying up their IT resources and limiting growth.
A good way to begin is by careful evaluation of the overall IT portfolio to determine which core systems should be replaced and which can be successfully modernized. Because system replacement carries high risk in terms of expense and work disruption, it's best to develop a forward-looking plan that avoids wholesale replacement. A successful sustainment and modernization program can keep systems current with changing business and technology requirements while saving time, money, and IT staff resources. One mark of the legacy crisis is the immense and growing amount of old code. Ian Sommerville, professor of software engineering at Lancaster University in England, estimates that 250 billion lines of source code are now being maintained. And the number is increasing all the time. Software becomes legacy when it begins to resist modification and evolution. When the knowledge embodied in legacy systems constitutes a significant corporate asset, the systems can't simply be discarded—they must be replaced. But replacing legacy systems places a huge burden on IT departments and prevents them from developing new applications and capabilities. IT can ease this burden by increasing the efficiencies of maintenance processes and eliminating redundant applications. Even these activities, though, have practical limitations. The cost of discovering and implementing new efficiencies will eventually exceed the cost of leaving existing inadequacies in place. When processes can no longer be cost-effectively optimized, the only way forward is to rethink basic approaches. CIOs responsible for legacy systems are well-advised to adopt and communicate a strategy for sustaining and modernizing legacy systems. (Some best practices for leveraging software investments are also discussed in High-Octane Software) The life cycle of a typical information system includes maintenance, modernization, and replacement activities. Adding sustainment to the mix can prolong a system's life.
A typical strategy is to replace the system in the direst need. The CIO often reassigns developers released following the deployment of a new system to replace the problematic legacy system. This strategy has several flaws, however. First, it's optimistic to assume that deploying the new system will free up resources to devote to replacing the failing legacy system. For example, what resources will be available if the new system doesn't completely replace the capabilities of the legacy system? And what resources must be retained to maintain the new system? Second, the difficulty of replacing the failing legacy system must not be underestimated. Legacy systems, by definition, resist change. Many have grown very large over many years and contain business knowledge that may not exist in any other form inside the company. The replacement system must capture and implement this business knowledge. Even when replacement efforts succeed, they often fall short of duplicating the capabilities of the original system. Users must frequently wait for a second or third release to fully restore the capabilities of the legacy system. CIOs must also support systems that aren't being immediately replaced. They often siphon off money from the maintenance budget to pay for expensive replacement efforts. But even the newest systems require continued investment to duplicate all the capabilities of the legacy system. As a result, the neglected systems continue to deteriorate and become obsolete. Transitioning development staff from one replacement effort to another is a grossly inefficient use of IT staffs. First, the developers must come up to speed on the operational domain of the new system. This requires an investment of money and time. Second, domain expertise for the system just completed is lost. And third, attrition rises higher than usual, as developers already considering a job change are more likely to move around during this upheaval.
The bigger question that CIOs face is this: What will prevent the new system from suffering the same fate as the system it replaced? The solution is to avoid creating new legacy systems and to modernize the existing legacy systems. But how?
Preventing systems from slowly becoming legacy systems requires active sustainment. The goal, in terms of the information-system life cycle, is to prevent the project from "flat-lining" and consequently requiring a replacement effort. Sustainment is qualitatively different from maintenance in that the maintainability and evolvability of the code must be retained even as modification requests are satisfied. Sustainment means taking the time to repair defects correctly and not simply patching the code. It may also require technology refresh and architectural evolution—for example, upgrading from "green screens" to a Web-based interface or adopting a distributed architecture.
To avoid obsolescence, the sustainment budget must exceed that used for simple maintenance and let the IT team keep pace with changing technology and evolving business needs. The system must also evolve in a way that maintains its architectural integrity or adapts the architecture to new requirements. The potential for success in system sustainment can be greatly improved, of course, by building systems from the ground up with sustainability in mind.
Risk-management practices continuously assess what can go wrong, determine what risks are important, and implement strategies to deal with risks before they emerge as problems. Such assessments are an integral part of the spiral development process.
A precondition for minimizing the modernization risk is a portfolio analysis that evaluates each system and determines an appropriate evolution strategy. The analysis measures the technical quality and business value for a set of systems, and then evaluates the set against the measures. Business value measures the number and criticalness of the business goals supported and the degree to which these goals represent core competencies of the business—a task that must be accomplished in conjunction with the CIO's business counterparts. The technical-quality measures might include availability, evolvability, maintainability, performance, security, usability, and other system qualities. The Software Engineering Institute at Carnegie Mellon University recently developed measures for maintainability and evolvability. Also, tools from companies such as Klockwork Inc. can measure aspects of these qualities. Klockwork tools work primarily with C++ and Java.
Legacy systems are evaluated against these measures and positioned on a portfolio-analysis grid, such as the one shown in the chart. The quadrant in which each system appears suggests an appropriate evolutionary strategy:
Also consider the real organizational or resource issues that can significantly increase the risk to a modernization effort. Typically these include available staff, cost, politics, schedule, technical skills required, training of the development staff, training personnel to use the modernized system, and user acceptance of the modernized system.
After performing the portfolio analysis and identifying modernization issues, the CIO can select and prioritize candidate systems and develop an overall modernization strategy. The portfolio analysis should be re-evaluated annually or as dictated by business changes.
Increased and simultaneous investment in multiple core systems isn't without risks. However, it acknowledges that certain information systems are inseparable from and must evolve along with the business. Sustainment lends itself to lower risks by avoiding the wholesale replacement of systems, minimizing both the disruption of services and irritation of users.
There are obstacles, however. CIOs may have difficulty securing the funds necessary to sustain systems at required levels. Without adequate funds, you may need to eliminate one or more nonessential systems to sustain the rest. Ideally this situation can be avoided by not letting systems degrade to the point where modernization costs exceed replacement costs, leaving replacement as the only reasonable option. Resources can then go into sustainment and modernization projects that retain the existing investment in these systems.
Staff issues can arise, and CIOs may have concerns about software developers who feel stuck in the same job. However, if the systems are upgraded with changing technology, rather than minimally maintained, the developers will be continually challenged to grow along with the system. Some developers will be motivated to learn new skills and become change leaders. Others will feel more comfortable sustaining the older technologies. As the technology base evolves, these developers will eventually follow.
It may also be useful to hire consultants who specialize in technologies that are being incorporated but are poorly understood by the development team. Consultants shouldn't become permanent fixtures. Instead, assign an individual from your organization to work with and learn from the consultant so your department can sustain the system organically after the consultant leaves (see The Incredible Shrinking Legacy Workforce).
Software sustainment is designed for the company's long-term health, not for any short-term effect. As the Greek war historian Thucydides wisely said, "The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it." While sustainment may be costly and unpleasant, a lack of sustainment carries a higher penalty.
Robert Seacord is a senior member of the technical staff at the Software Engineering Institute at Carnegie-Mellon University and co-author of Modernizing Legacy Systems: Software Technologies, Engineering Processes, and Business Practices (Addison-Wesley, 2003).
The U.S. Air Force has used the Aviation Resource Management System since at least 1983 to track air-crew members' flight data. This is a critical capability for commanders who need to determine in a matter of minutes a pilot's total career flight hours or what aircraft the pilot is qualified to fly. Because of the criticalness of the system, the Air Force has invested in the sustainment and continual evolution of the system. ARMS was originally developed for and operated in the Unisys mainframe environment. A modernization effort was completed in June 1997 to deploy ARMS on HP/UX with an Oracle relational database management system. Other, more recent efforts include the deployment of an encryption capability in April 2002 and an enhanced graphical user interface in May 2003. The software currently uses a GUI and standard menus that let USAF operational resource-management personnel interact with the system. With centrally located servers, users have real-time access to information. The software continues to be actively sustained. Current efforts include implementing a browser-based interface and adapting the architecture toward the Air Force standard for greater interoperability with other existing and planned systems. The sustainment budget for ARMS is roughly $3.2 million a year, which includes sustainment, enhancements to the application, hardware purchases, and modernization. However, the USAF says this investment is well-justified as ARMS supports a total of 2,800 operational users, who in turn support more than 66,000 air-crew members. The Standard Systems Group at Maxwell Air Force Base Gunter Annex in Montgomery, Ala., performs the ARMS sustainment work. SSG, an element of the Electronic Systems Center at Hanscom AFB, Mass., provides and supports secure combat-support information systems and networks for the Air Force and Defense Department components. SSG systems are used at virtually every Air Force operating base'both in garrison and deployed'with more than 200,000 users and 3 million transactions daily. "SSG is committed to sustaining the ARMS program to support the war fighter and moving it forward as our customer directs," says Frank Weber, SSG executive director. "This program is an invaluable tool for ops commanders." —Robert Seacord Sidebar: Case Study: Sustaining A Software System At the Fraunhofer Center-Maryland software-engineering research facility, we use application development, feedback, and learning techniques to improve software-development technologies for our clients, which include the Department of Defense, NASA, Boeing, DaimlerChrysler, Motorola, Nokia, and local software companies in Maryland. One of the facility's primary assets is the Visual Query Interface software system, used to visualize data.
A couple of years ago, it became clear that the VQI system couldn't take any more change. The effort of adding functionality to the then-3-year-old system consistently exceeded expectations. A quick analysis revealed that most of the VQI modules were highly coupled to each other. Also, no one dared touch several chunks of "half-dead" code because of the risk of introducing errors, and code was placed in modules where it didn't belong.
We also changed our process to better sustain the software. We needed to protect our software investment and explicitly ensure that changes were implemented correctly; otherwise we ran the risk of ending up where we started: with unsustainable code.
Our organization comprises about 15 full-time people, but we have high developer turnover because we frequently use temporary programmers. Developers are typically assigned a feature-oriented task for which they design and implement a solution. We have found that the implementation often deviates from our plans, causing the software to decay quickly. We needed a way to match the planned architecture and implementation so we could detect violations and correct them.
Our solution was to actively sustain the software. We did this by following these steps:
1. Define and document the architecture.
2. Make sure the developers understand the architecture.
3. Implement a process to evaluate the implementation without reviewing all the code.
Our evaluation approach is based on architectural guidelines, components, and their connectors. By applying the process as part of the regular development effort, we can ensure that the software is architecturally sound.
—Mikael Lindvall is a scientist at the Fraunhofer Center for Experimental Software Engineering Maryland and a member of the SEI sustainment project headed by Robert Seacord.
With careful portfolio evaluation and a long-term sustainability plan, CIOs can thwart the seemingly inevitable march toward system obsolescence and replacement. Here's how to begin that process: FIRST MONTH: Get your house in order
SECOND MONTH: Allocate resources
THIRD MONTH: Establish metrics
| |||
