Authors' email and home pages

Perdita Stevens' email and home page

Abstract

The reengineering of legacy systems -- by which we mean those that ``significantly resist modification and evolution to meet new and constantly changing business requirements'' -- is widely recognised as one of the most significant challenges facing software engineers. The problem is widespread, affecting all kinds of organisations; serious, as failure to reengineer can hamper an organisation's attempts to remain competitive; and persistent, as there seems no reason to be confident that today's new systems are not also tomorrow's legacy systems. We suspect:

that the main problem is not that the necessary expertise does not exist, but rather, that it is hard for software engineers to become expert;
that the diversity of the problem domain poses problems for conventional methodological approaches;
that an approach via systems reengineering patterns can help.

A systems reengineering pattern is a description of an expert solution to a common systems reengineering problem, including its name, context, and advantages and disadvantages. We are principally concerned with the problem how reengineering should proceed, rather than with what the design of the reengineered artefact should be. The latter problem seems to be adequately addressed by existing techniques (not least, design patterns). A reengineering pattern embodies expertise about how to guide a reengineering project to a successful conclusion. Because this is not only or even principally a technical problem, the context of a reengineering pattern must be much broader than that of a design pattern. It includes business context as well as software context, and may even need to take into account factors such as the budgeting procedures of the organisation or the personalities of the managers whose support is needed. In this position paper we explain this point of view, and briefly describe two candidate systems reengineering patterns which are relevant to object oriented systems.