MAINFRAME MIGRATION: INDRODUCTION
Information systems were adopted by enterprises several decades ago, and they have been used ever since. As a result, operationally, most enterprises rely on old, out-ofdate systems. These systems are known as legacy systems. Well-known examples of this kind of systems are COBOL systems because, there are over 200 billion lines of operative COBOL still running worldwide. Furthermore, since enterprises’ goals and context vary, in time these systems have suffered modiﬁcations to be kept suitable for the enterprises. For example, nowadays it is impossible to conceive a bank that does not offer Home Banking services, yet most bank systems were originally written in COBOL. Therefore, it is common to ﬁnd a 50 year old technology, such as COBOL, working alongside with the most modern technologies, like .Net, AJAX, or JEE, in the same enterprise. As a result of this situation, enterprises have to face high costs for maintaining their systems. This is mainly because these systems usually run on mainframes that must be rented. In addition, there is the necessity of hiring developers specialized in old technologies for updating the system functionality, which is both expensive and rather difﬁcult. Taking these facts into consideration, many enterprises opt for modernizing their legacy systems using a newer technology. This process is called migration. Currently, a common target paradigm for migrating legacy systems is SOA(Service-OrientedArchitecture). In SOA, systems are built using independent functionalities called services that can be invoked remotely. Services are offered as platform-agnostic functionalities that can be used by any system inside or outside their owner organization. To ensure platform independence, Web Services technologies are the commonest way of implementing SOA systems since the former relies on well-known Internet protocols, such as SOAP and HTTP. Therefore, migrating legacy systems to Web Services technologies is a fairly common practice. However, there is no standard recipe to effectively migrate legacy systems to SOA. Recent literature proposes that a legacy system can be migrated by following two approaches. The ﬁrst approach, called direct migration, consists in wrapping a legacy system with a software layer that exposes the original system programs as Web Services. This approach is known to be cheap and fast, but it has the disadvantage that the legacy system is not replaced by a new one. Instead, the enterprise obtains two systems to maintain: a legacy system, and its newly-built SOA layer. On the other hand, the approach called indirect migration is based on re-implementing the legacy system using a modern platform. This approach is expensive and time consuming because not only the system should be re-implemented and re-tested, but also in some cases the business logic embodied in the legacy system should be reverse-engineered. This happens because system documentation could have been lost or not kept up-todate. The result of an indirect migration is not only an improved version of the system, but also updated documentation for future reference. From the SOA point of view,an important difference between direct migration and indirect migration is the quality of the SOA frontier that is the set of Web Services exposed to potential consumers as a result of migrating a legacy system. The SOA frontier quality is a very important factor for the success of a SOA system because, as Figure1 depicts, SOA frontier is used for both service registries and consumer. Service registries use the SOA frontier for indexing services and, then, allowing service consumers to search for them. In contrast, service consumers need the SOA frontier to understand and invoke the services. And a SOA system success can be measure by how many service consumers it has. This is however ignored by most enterprises as direct migration is by nature the least expensive and fastest way of deriving a SOA frontier from a legacy system, but such a SOA frontier commonly is a mere “Internet-ready” representation of original system program interfaces, which were not designed with SOA best design practices or even conceived for being used by third-parties as Web Services essentially are.
Instead, a SOA frontier design is commonly beneﬁted by the re-implementation of original system programs during indirect migration. To obtain a better trade-off between cost and SOA frontier quality, we have developed a new migration approach with similar quality than the one obtained using indirectmigration,butbasedondirectmigration. Our approach, called assisted migration, takes a legacy system migrated using direct migration and performs an analysis of possible refactoring actions to increase the SOA frontier quality. Although this approach does not remove the legacy system, we think that the obtained SOA frontier can be used as a starting point for re-implementing it. Therefore, such a SOA frontier smoothes system replacement because it does not change when the legacy system is replaced by the new one. For evaluating the viability of assisted migration, we used a case study involving a COBOL system in which direct migration and indirect migration were applied. This system is owned by the biggest Argentinean government agency, and manages data related to almost the entire Argentinean population. The system was ﬁrstly migrated usingthedirectmigrationapproachbecauseofstrictdeadlines. Since the SOA frontier quality of the ﬁrst migration was not suitable for new developments, the agency decided to perform a second migration. In this case, the indirect migration approach was used to improve the SOA frontier quality. Having these two migration attempts, we applied the assisted migration approach by feeding it with the direct migration version of the original system. Then, we compared the three obtained SOA frontiers in terms of cost, time, and quality. According to this analysis, our approach produces a SOA frontier nearly as good as that the indirect migration, but at a cost similar to that of direct migration.