years ago using outdated

techniques,yet it continues to do
usefil work.Migrating and
updating this baggagefiom our

nontechnical challenges, ranging KEITH BENNETT, University of Durham

fiomjustzfiing the expense to
dealing with contractors Legacy systems may be defined infor- day when some 40-year-old software
mally as “large software systems that ~ will still be in operation.
to usingprograrn-understanding we don’t know how to cope with but A typical legacy system might be
that are vital to our organization.” written in assembly or an early version
and vimalization techniques. Many are old: Soon we will reach the 1 of a third-generation language (such as

IEEE SOFTWARE 07407459/94/$04 W 0 1994 IEEE 19

Coral, Fortran-66, or Cobol). It was and single, very large global data struc- for alterations cannot be sustained.
probably developed using state-of-the- tures. Efficiency was seen as important, Business opportunities are being lost.
art software engineering (or, if devel- so clarity and structure were traded off
oped before 1968, programming) tech- for program speed. Concurrency was NEW ATTENTION
niques. This was the latest technology not well understood, so such features
when it was developed, but successful were designed with ad-hoc methods. T h e issue of legacy systems has
software inevitably evolves: Manny All these techniques make mainte- become recognized only in the last few
Lehman has argued that software must nance and testing very difficult. They years, perhaps because the mainte-
continually change or become increas- also encourage the sort of maintenance nance costs and applications backlog
i n d v less useful in the real have increased. Also, client-server
architectures based on commercial,
off-the-shelf software have shown that
alternatives are cheaper and more flexi-
t-vulvlllg UllUGI bVd11U - ‘dllU pl Ugl all1 ble.
U1 buILWalG Wlll

degrade unless remedial

KtUUll ” understanding becomes a Until recently, researchers have
action is regularly taken.’ REMED AL major maintenance activity. largely ignored the problems of legacy
For the great majority Amnh no Legacy systems a r e also systems, preferring instead to study
of legacy software, such nLllU’” large, typically comprising front-end problems. However, solu-
remedial action has nevei’ ITS STRUCTURE hundreds of thousands of tion strategies are crystallizing, and
been taken. So whatever lines of source code o r industrial case studies are being pub-
structure originally existed ‘ 1‘‘ TEND TO more. Small programs are lished. The articles in this special issue,
has l o n g since disap- DEGRADE. not difficult
.
to. maintain - summarized in the box on the facing
peared. Without current the issue of scale is central in page, present some of these solutions
documentation, mainte- this field a n d c a n n o t be and demonstrate that some progress is
nance is done using the source code avoided. being made in managing legacy systems.
because it is the only reliable source of Technical problems are accompa- Alternatives to discarding the sys-
information about the system. Over nied by management problems. Most t e m o r redeveloping i t a r e being
time, the software becomes very diffi- software engineers would prefer to explored. Much research effort is being
cult to maintain, yet the organization’s work o n new-systems development expended on reverse engineering. This
requests f o r maintenance become instead of maintaining old, obsolescent covers a range of techniques, from
more frequent and more insistent. systems. And the necessary skills may simple control restructuring to design
Moreover, many legacy systems are be in short supply; fewer people now and specification recovery in prepara-
performing crucial work for their orga- have extensive experience with assem- tion for new forward engineering.
nization. Hence the decision on how to bly, for example. Another promising approach is t o
manage them is crucial: If a legacy sys- T h e r e may be user resistance to “freeze” and encapsulate the legacy
tem is running the key billing system, change, as well. Despite weak technical system as a component in a new imple-
it is not sensible to make rash judg- foundations, legacy software may be mentation. T h e functions provided by
ments, because the very future of the very reliable and responsive to cus- the legacy system can then progres-
business may be at stake. Legacy sys- tomer needs (and those customers may sively be taken over by the new soft-
tems may represent years of accumu- be heavy users of undocumented fea- ware until the legacy software becomes
lated experience a n d knowledge. tures). In the short term, a replacement redundant.
Indeed, the software may be the only system may be less reliable and require Ultimately, deciding which solution
place an organization’s business rules its customers to do a lot of relearning to pursue will be based on economics:
exist, so systems analysis must involve and rework. W e must trade off the cost of continu-
examining the software rather than the T h u s there is a dilemma. O n the ing to cope with the legacy system
human processes. one hand, the system is very valuable, against t h e investment needed t o
and simply replacing i t (usually the improve it and the benefit of easier
LEGACY DILEMMA desired solution) may be too expensive subsequent maintenance.
to contemplate because of the huge
T h i r t y o r even 20 years ago, the volumes of online data that must be LOOKING AHEAD
constraints on software design were converted, among other reasons. O n
very different. T h e use of small main the other hand, the system is becoming It is daunting to consider that the
storage meant that programmers had t o o expensive t o maintain and t h e successful software systems being writ-
to save space by using variable aliasing demands of the marketing department ten today are likely to turn into tomor-

20 JANUARY 1995
ARTICLE SUMMARIES: LEGACY SYSTEMS
4 Planning the Reengineeringof transactions per day. The reengineer-
Legacy Systems, pp. 24-32. ing effort at Catholic University
involved a library system. It was an
As the manager of a small software- interesting case because the software
reengineering company, I am continu- had been developed by a group of
ally confronted with the task of justify- librarians across several organizations bination of natural-language informa-
ing reengineering. The user wants to and involved very specialized technical tion modeling, design recovery, and
know what the benefits are. W h y knowledge. Both of us learned valuable procedural reengineering to gain
reengineer old Cobol or Fortran when lessons about outsourcing in general and knowledge about the system and what
there are so many attractive fourth- off-shore outsourcing in particular that it did. U’e did not change the original
generation and object-oriented Ian- we hope others can benefit from. Off- funcbonality in any way. Our plan was
guages on the m‘irket? That is u h j I shore outsourcing saved our organiza- to reimplement the system in one year,
have chosen to address business issues tions 3 5 percent over local bids, and the while at the same time limiting the
in this article - not because the tech- results were waranteed. project’s capital and resource budget
nical problems of transforming code to $500,000 and getting a payback
and data structlires are not iinportant 4 Structural Documentation: A within a year of project completion.
but because they may be irrelevant if Case Study, pp. 46-54 We met all the objectives (sometimes
you are not able to make a busines Kemy Woiig, Scott R. Tillty, Hmsi ‘4 exceeded them) except the payback
case for solving them. There is iioth- ,t.liillei. nnd ,\/lni;qai-et-Anne D. Storey period, which was six months longer.
ing worse for a technician than to be Structural redocumentation is
working on a solution to some prob- reverse-engineering the architectural 4 ReengineeringUser
lem for yearb, only to discover that the aspects of software to derive the over- Interfaces, pp. 64-73.
problem was incorrectly stated from all gestalt of the subject system and Ettow ,Vferlo, Pierre- Yces G a p e ,
the beginning. I have developed a five- some of its architectural design iiifor- ~enn-Fi-anrvisGimi-d, Kostas
step reengineering planning process, niation. At the University of Victoria, Kontoginnnis, Liiiwie H ~ i i d ~ iPmkasb
i,
starting with an analysis of the legacy we have developed the Rigi environ- I-’nnnngnden, ~ n Renato
d De -2lor-i
system and ending with contract nego- ment, which focuses on the architec- Turning a character-based interface
tiation. The five major steps are pi-qert tural aspects of program uiiderstand- into a graphical one requires signifi-
justification, pin@oIiv aiialysis, cost estima- ing. It supports a method for identie- cant time and resources. We have
tion, cost-benefit analysis, and contmctzng ing, building, and documenting lay- developed a way to partially automate
ered subsystem hierarchies. Critical to this process and give the results of our
4 Realities of Off-Shore Rigi’s usability is its ability to store and own reverse-engineering effort. Our
Reengineering,pp. 35-45. retrieve views - snapshots of reverse- work was part of the IT Macroscope
Guidv Dedene and Jean-Pmre engineering states. These views are project, whose overall objective was to
De Vreese used to transfer information about the produce a comprehensive set of
Many organizations fail to consider abstractions to software engineers. %’e methodologies, tools, and learning
outsourcing when evaluating the feasi- have successfully applied our approach inaterials that aould support organiza-
bility of reengineering. Often local to several real-world software system, tions in better managing their business
hut not until we undertook the chal- processes through information tech-
lenge of redocumenting an SQL/DS nology. Our focus was to define an
system with two million lines of code interface-reengiiieeriiig process that
did we begin to validate our approach. would let developers shift from a char-
acter-based paradigm to one based on
4 Reengineering a Configuration- graphical objects. LVe Mieve our
Management System, pp. 55-63. approach will let the interfdce of a
Olin Bray and iMichael LW.Hess legacy system evolve as new iiiterhce
We reengineered a 30-year-old technologies emerge. This extends the
mainframe-based system, whose life of the system and iinproves its
source code and design documentation overall quality. And the knowledge
were incomplete, into a client-server gained will greatly enhance interface
application. Our strategy was to use maintenance over the years.

IEEE SOFTWARE 21
 ~~ ~ ~~ ~ -

SIGNPOSTS AND LANDMARKS: A LEGACY SYSTEMS READING LIST

i
Software-engineering literature has SEI-93-SR-5) are available from Dennis ECONOMICSAND BPR. Reengineering
, long been intertwined with both soft- Smith at the SEI. [email protected]. economics is a topic gaining interest.
ware maintenance and reverse-engi- The Joint Logistics Coininander.;, a
neering topics. Reengineering involves CONFERENCES AND PERIODICALS. Conf- DoD agency, has released for review
processes of finding legacy-system arti- erences have long been a primary anti community coniment a second ver-
facts, understanding their interrelation- source of material on reengineering, sion of S o f t ~ ~ r r Keengiiz
-e cering Asscsmeii t
i
i ships, planning system changes, and particularly papers at the International Hmdbook (Tech. Report JLC-HDBK-
implementing those changes. If not Conference on Software Maintenance. SRPLH).This guide documents key
i carefully defined, it could be argued ICSM proceedings from multiple years approaches to reengineering and how
that reengineering includes all of soft- are available from IEEE CS Press a t to evaluate the costs and potential ben-
1 ware development - and therefore all cs.booksQ coinputer.org. The Work- efits for systems. The process recorn-
1 software-engineering references would ing Conference on Reverse Engineer- mended in the handbook includes tech-
apply. ing, first held in 1993, concentrates on nical and economic assessment, and
IEEE Sojiware published themes on the research issues of analyzing and management-decision aspects. It
1
~software maintenance in May 1986 and understanding legacy systems. WCRE describes various cost models - includ-
January 1990, including articles on was the source of papers for the May ing Cocorno, Slim, and Prices - and
~what would now be considered reengi- 1994 reverse-engineering issue of sizing models - including Resize. Call
neering topics. Many of these articles Communicationsofthe ACM. The 1993 STSC at (801) 777-8045.
1 are still very timely and useful. The WCRE proceedings is available from Finally, a literature review would
i 1990 issue included a now often cited IEEE CS Press, as will be the proceed- not be complete without considering
taxonomy (E. Chikofsky and J.H. ings of the second WCRE in July husiness-process reengineering. Today
Cross 11, “Reverse Engineering and 1995. it is hard to find a current issue of
~Design Recovery: A Taxonomy,” pp. Both reengineering and reverse Business Week or Injbrrnation Week t h a t
~ 13-17) that illustrates the relationship engineering are the focus of Reverse does not mention BPR, usually as sim-
among terms like reengineering, Engineering Newsletter, edited by ply “reengineering.” Although there is
~reverse engineering, redocumentation, iMichael Olsem. This newsletter, pro- little direct connection between soft-
and restructuring. This taxonomy and duced by the IEEE CS Technical ware reengineering and BPR, there is a
related papers can be found in a useful Council on Software Engineering’s lot of indirect connection. A joint
~reprint collection, Sofcu)are Reengineer- Committee on Reverse Engineering, is meeting of practitioners and
ing (IEEE CS Press, 1993), edited by published within the TCSE newsletter. researchers from both fields a t the
Robert Arnold. The online editions of Reverse Engineer- Fourth Reengineering Forum in
ing Nmslettw and TCSE newsletter are September revealed many similarities
PROJECT REPORTS. Large consoma- available at info.computer. org. in tools and modeling techniques. A
based projects have begun to release post-conference collection of papers
broad survey papers and document col- from &IS meeting is planned for publi-
cation by IEEE CS Press in 1995.
For background on BPR, see Peter
Keen’s Shaping the Future: Business
Through n Technology
article on its reverse-engineering pro- + A survey entitled “Reengineering rd Busin Press, 1991)
ject that s p n s nearly a dozen universi- Tools Report” published by the US Air and Don Tapscott and Art Caston’s
ties in Canada and the US. The Redo Force’s Software Technology Support P a d i p n Sh& 7 h e Nep Provzisr of
Project, hnded as part of the European Center at Hill Air 1;orce Base in July bzfbrwation 7idwology (AlcCraw-Hill,
Community’s ESPRI’T‘ program, has 1992. Call (801) 777-8045. The same 1093). Mso, Automating 11usiiie.s.s Pruirss
published Redo Cmpmdjzm (Henk van group maintains a reference database on RrrqinetTivg: Bwaking the TQ.11
h y l e n , ed., John Wiley, 1YY3), includ- took that it uses t(J advise US Depm- Bwricr, by Gregory IIansen (Prentice-
ing papers documenting European nient of Defense projects and others and Hall, 1994), provides an in-depth look
work on a wide range of reenginering publishes Croxmdk, a newsletter covering a t one approach using a tool described
topics. k Carnegie Melion University, software-engineeringand reengineering in “Toolsfor Business-Process
the Software Engineering Institute’s topics htr a diverse audience. Keengineering,” (1EfiE Sofru.are, Sept.
year-old project on reengineering is + SofDu?+Mairztemnce !Vms,which 1994, pp. 131-133). It is particularly
developing a best-practices guidebook publishes a comprehensive, well- interesting to conipare the BPR
with the help ofmany representatives indexed reengineering and mainte- approach shown in this book with soft-
of defense agencies and consulting nance-tools survey as the “Software ware-development and -analysis merh-
companies. Interim working papers, Management ‘Technology Reference ods used in software reengineering.
such as “Reengiwering:An Engineer- Guide.” Call (415) 969-5522; -Elliot Cbikojiky, Contributing
ing Problem,” by Peter Feiier f C W / [email protected]. Editor
............ . . . . . . . . . . . . . .
row’s legacy systems. Yet they are Software engineers must not just
never envisaged as legacy systems call themselves professionals; they
when they are built. must act as professionals too. This has
Legacy software is basically the implications for education, training,
result of management inaction rather and ethics.
t h a n t e c h n o 1o gy d e fi c i e n cy - Finally, it is interesting to see that
Lehnian foresau major problems much of today’s software is being con-
l o o m i n g 14 years ago.’ W e m u s t structed with components, often from
l e x n to regard software evolution a\ different vendors and often distributed.
an integral part of the development T h e independent development of new
process, not (as many textbooks do) versions of these components is caus-
an irrelevant adjunct. Reverse eiigi- ing increasing problems in retaining a
iieering and reengineering must coherent complete system. If this is not
become a continuing p a r t of t h e brought under control, through better
process of software development and integra ti on ni e c h a n i sms , the 1e gacy
evolution. What we might call "big- problem will resurface in a new, and
bang” reverse engineering - the high- much worse, form. T h i s is a major
risk, expensive approach common
today - will probably fall from favor.
~ ~
~ ~~

Does Your Software Have Bugs?

You need
Insure++’”2.0 uormerly Insight++)
The most thorough runtime error detection available, period.
Insure++ automatically detects Insure++ finds all bugs related to:
on average 30%more bugs than d memory corruption
other debugers, helping you to dynamic, statidglobal,
produce higher quality software and stacMoca1
faster. d memory leaks
Available for SudSparc, SGI, d memory allocation
DEC, Alpha, IBM RS/6000, new and delete
I-IP9000, SCO, and others. d I/O errors
d pointer errors
d library function calls
mismatched argument8
invalid parameters

Parasoft Co rporation
Phone: (818) 305-0041 FAX: (818) 305-9048 E-mail: [email protected] Web: http:Ilwww.ParaSoft.com

Reader Service Number 5