| Formats | Publications | |
|---|---|---|
|
|
Architectural Evolution of Legacy Systems, Twenty-third International Conference on Computer Software and Applications Conference (COMPSAC), Phoenix, Arizona, pp. 4-12, Oct. 1999 (view Abstract). |
| A Framework for COTS Integration and Extension, Commercial Off-the-shell (COTS) Workshop, Limerick, Ireland, Jun. 2000. | ||
|
Evolving Legacy Systems by Locating System Features using Regression Test Cases, Jun. 2001. | |
As software assets become a greater proportion of an enterprise’s total assets, more attention is being focused on the processes and technology used to build and maintain those assets. Increasingly, software is being viewed as an asset that represents an investment that grows in value rather than a liability whose value depreciates over time. Organizations everywhere are experiencing tremendous pressure to evolve their systems so they can better respond to marketplace needs and rapidly changing technologies. This constant pressure to evolve is driven by escalating customer expectations and the need to respond to new enterprise standards, incorporate new products and system features, improve performance, cope with endless new software releases, and stave off hardware and software obsolescence.
Although these legacy systems must be updated continuously to reflect evolving business practices, repeated modification has a cumulative effect on system complexity, and the rapid evolution of technology quickly renders existing technologies obsolete. Eventually, the existing information systems become too fragile to modify and too important to discard. However, organizations must consider modernizing these legacy systems to remain viable. There are a variety of solutions to legacy system evolution. However, an organization must understand the strengths and weaknesses of each evolution technique to select the solution with the greatest chance for success.
Software maintenance is more difficult than software development because there are fixed code assets that can’t be modified or redesigned. One goal for modern software engineering is to move towards a paradigm of evolutionary systems. The artificial distinction between development and maintenance is replaced by the notion of continuous evolution of legacy systems. To effectively evolve legacy systems in this fast-paced environment, managers require answers to the following types of question:
There
is a tendency for organizations to focus on specific technical issues during
system evolution without considering the broader systems engineering issues, the
increased needs of the customer, the strategic goals and objectives of the
organization, and the business operations of the enterprise. A case in point was
the "year 2000" (Y2K) crisis. This crisis appeared to be a simple,
well-bounded, technical problem, but a comprehensive solution required an
enterprise perspective that accounted for the strategic, organizational, and
business aspects. We therefore must ensure that the evolution of a legacy system
is supported by a unified perspective that involves all stakeholders.
We
initiated our research by considering two perspectives within software
engineering that have been identified by numerous researchers, the problem
domain and the solution domain.
The point of reference for an individual depends upon the domain that one is
involved in. The end-users’ perspective revolves around the problem domain and
the software development team’s perspective revolves around the solution
domain. Users interact with the system and are directly concerned with its
functionality; they always refer to the problem domain. Developers are concerned
with the creation and maintenance of software development life cycle artifacts;
they always refer to the solution domain. A major source of difficulty in
developing, delivering and evolving successful software is the gap that exists
between problem and solution domains, often called the complexity
gap.
Legacy
systems are now commonly written in modern programming languages and there is an
opportunity to apply the concepts of component-based software engineering to
these systems. It is commonly accepted that modularized programs are easier to
maintain than monolithic ones. We therefore seek to refactor and reengineer the
code base of a legacy system to include well-defined components with clear
interfaces. Reengineering can migrate a
legacy system towards an evolvable system in a disciplined manner. However, to
be successful, reengineering requires insights from technical, managerial, and
economical perspectives. Most software maintenance initiatives and approaches to
evolving legacy systems suffer from not being able to effectively reduce the
complexity gap.