Chickens and turkeys migrate, but not necessarily in IT
New challenges for reengineering
By Ben Wilson.

Researchers from the University of Edinburgh and the Heriott-Watt University are clear in their definition of legacy systems and the importance of legacy systems reengineering. On a recent web page, they state: "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."

While finding sources that downplay the importance of legacy systems reengineering is hard, it remains nevertheless impossible to find a consensus among these sources on what the best general approach to reengineering should be. Many models have been proposed over time, and these models differ not only in their approach, but often also in the way they define the deliverables of their reengineering templates.

Importantly, the discourse among software engineering experts on the proper approach to "systems reengineering" seems to have reached something of a stalemate in an old debate between two conflicting ideologies. These ideologies butt heads over the main problem of whether it is in the best interests of an organisation if a large mission-critical information system is "migrated" all at once in its entirety, or is migrated piece by piece. Since the question is key to the planning of any reengineering effort, the answer each model gives will be one of its defining characteristics.

Over time, academics and industry experts have introduced a number of names to describe these two approaches. Two of the most popular ones in use today to describe a model's persuasion in this dichotomy are the terms "Chicken Little" and "Cold Turkey."

The rise of Chicken Little
The earliest references to these two terms that can be found date from 1991, and the pioneering DARWIN project from the University of California, Berkeley. The results of the project introduced "Chicken Little" as an approach to iteratively (later this would be called "incrementally") migrate legacy systems. As the DARWIN model was perfected, the incremental nature of the approach was stressed as the model was drawn out in eleven easy-to-remember "steps," each of which started with the word "Incrementally." This approach answers a clear "no" to the all-at-once question. With Chicken Little, "data gateways" are developed and introduced between the legacy system and the target system to maintain data consistency throughout a project.

The project also introduced "Cold Turkey" as an alternative approach. To quote from the study (which is available on-line here:) "Cold Turkey involves rewriting a legacy IS from scratch to produce the target IS using modern software techniques and hardware of the target environment". The main defining characteristic of Cold Turkey is its "big bang" approach to systems switchover.

In the race between the two ideologies, it must be said that the turkey got off to a bad start: The initial DARWIN study starts blasting the Cold Turkey approach on page two of its 56-page report. When the study was published as a book in 1995 by Morgan Kaufmann Publishers, authors Brodie and Stonebraker became more assertive in their attack on Cold Turkey, starting their criticism of the method in their preface: "Ironically, the complexity of today's environments makes Cold Turkey infeasible, yet it also encourages people to consider Cold Turkey. It is so complex to consider how to incrementally migrate a legacy IS that planners often avoid the challenge altogether. They naively hope that Cold Turkey can handle it."

The actual criticism of Cold Turkey seems to be motivated less by a concern over the technical approach, rather than the justified concern with the high risk of failure attributed to large software projects, indeed any large software development project. Specifically, the Cold Turkey "Impediments" from the book: "Business conditions never stand still," "Specifications rarely exist," "Undocumented dependencies frequently exist," "Management of large projects is hard," and "Large projects tend to bloat," are not the privileged domain of legacy system reengineering projects alone. One of the main upsides of Chicken Little was the ability of the model to split a large project into smaller pieces, each of which would have a clear and visible result when delivered, namely, another piece of the legacy system operating on the target system. Two main benefits of this are the ability of the organisation to remain focused on specific milestones throughout a long project, and the ability of management to occasionally see some actual working benefits from a long-term investment.

To understand this early skepticism of Cold Turkey, it helps to view the DARWIN study in its (historical) context. A characteristic of the period in which the DARWIN project took place, of course, is the lack of availability of advanced software tools to automate migrations safely at that time. In 1991, the automated system migrations industry was not as mature as it is today, and there were many documented failures of the attempts of organisations to migrate large mission-critical information systems. The earliest developers of migration tools, like Anubex in 1995, would only start a few years later, and as a result the bulk of IS migration projects in the period leading up to the DARWIN project happened through what the industry now calls "manual work."

Cold Turkey gets relief
Some serious criticism of the Chicken Little approach came two years after the publication of Brodie and Stonebraker's book, when researchers from Ireland presented the results from an independent project called MILESTONE. The results of their research were presented during the 1997 Asia Pacific Software Engineering Conference and International Computer Science Conference in Hong Kong. The study, which can be found here, rejects the Chicken Little methodology, not on the indisputable project management benefits it brings, but on technical grounds for the way it is achieved. The report states: "Brodie and Stonebraker's Chicken Little methodology offers the most mature approach. However, the need for the legacy and target systems to interoperate via gateways during the migration process adds greatly to the complexity of an already complex process and is also a considerable technical challenge. Thus a need exists for a safe, comprehensive, gateway-free approach to legacy system migration."

The "Cold Turkey" method from the MILESTONE project, however, does not differ greatly from the "Chicken Little" method from the DARWIN project. The main difference is that under DARWIN, new subsystems are developed and taken into production straight away, whereas with MILESTONE, new subsystems are developed but only taken into production once the whole system is finalised. The final step of the MILESTONE methodology is the complete transfer of data from the legacy environment to its target. The report stresses that with their approach, the need for data gateways is eliminated, with the migration of the live data being the last step in the process.

The Confusion
This discussion of when to do a cutover of live data from legacy to target system and in how many steps it should take place may have you puzzled. What does the location of the live data in a migration project have to do with "legacy systems migration?" According to Brodie and Stonebraker, a legacy information system is one that has the "legacy characteristics" of being resistant to change. Systems resist change due to the poor quality of the documentation that describes them, the poor internal understanding of the system through the absence of specifications, and the fact that through sustained maintenance over many years, the structure of the program code has become weak. So, if an information system has these legacy characteristics, how will moving its data to another environment help? Similarly, the MILESTONE paper maintains, "Legacy system migration is concerned with developing a target system which retains the functionality and, importantly, data of the original legacy system but which can be easily maintained and adapted to meet future business requirements." If it is important that data be retained, why is it necessary to move it somewhere else?

It would seem that the term "legacy system" has become synonymous with three different concepts:

• A system of poor quality that resists change, regardless of the platform on which it runs;
• Any system, regardless of its quality, that runs on a proprietary or obsolete platform; or
• A system of poor quality that resists change and runs on a proprietary or obsolete platform.