<p>Legacy systems are considered to be potentially problematic by many software engineers for several reasons. Legacy systems often run on obsolete (and usually slow) hardware, and sometimes spare parts for such computers become increasingly difficult to obtain. These systems are often hard to maintain, improve, and expand because there is a general lack of understanding of the system. The designers of the system may have left the organisation, leaving no one left to explain how it works. Such a lack of understanding can be exacerbated by inadequate documentation or manuals getting lost over the years. Integration with newer systems may also be difficult because new software may use completely different technologies.</p><p>Despite these problems, organisations can have compelling reasons for keeping a legacy system, such as:</p><p>-The costs of redesigning the system are prohibitive because it is large, monolithic, and/or complex. </p><p>-The system requires close to 100% availability, so it cannot be taken out of service, and the cost of designing a new system with a similar availability level is high. </p><p>-The way the system works is not well understood. Such a situation can occur when the designers of the system have left the organisation, and the system has either not been fully documented or such documentation has been lost. </p><p>-The user expects that the system can easily be replaced when this becomes necessary. </p><p>-The system works satisfactorily, and the owner sees no reason for changing it; or in other words, re-learning a new system would have a prohibitive attendant cost in lost time and money. </p><p>If legacy software runs on only antiquated hardware, the cost of maintaining the system may eventually outweigh the cost of replacing both the software and hardware unless some form of emulation or backward compatibility allows the software to run on new hardware. However, many of these systems do still meet the basic needs of the organisation. The systems to handle customers' accounts in banks are one example. Therefore the organisation cannot afford to stop them and yet some cannot afford to update them.</p><p>Note that &quot;legacy&quot; has little to do with the size or even age of the system - mainframes run 64-bit Linux and Java, after all, right alongside 1960s vintage code. In fact, some of the thorniest legacy problems organisations now face are in trying to leverage or replace existing &quot;fat client&quot; Visual Basic code as customers demand reliable Web access.</p><p>Some thoughts and ideas on dealing with this matter, as part of an enterprise <a href="50-service-oriented-architecture-soa" title="SOA">SOA</a> roadmap,&nbsp;can be found elsewhere on this site, at this link: <a href="../pages/49-renewal_legacy_applications">http://www.theitsanctuary.com/pages/49-renewal_legacy_applications</a></p>

type the text from the image

or Cancel