Migrating a Large Scale Legacy Application to

SOA: Challenges and Lessons Learned

Ravi Khadka∗ , Amir Saeidi∗ , Slinger Jansen∗ , Jurriaan Hage∗ , Geer P. Haas†
∗ Department of Information and Computing Sciences, Utrecht University, The Netherlands
{r.khadka, a.m.saeidi, slinger.jansen, j.hage}@uu.nl
† IBM, The Netherlands

geer.haas@nl.ibm.com

Abstract—This paper presents the findings of a case study of from legacy systems to SOA enables enterprises to achieve
a large scale legacy to service-oriented architecture migration flexibility for collaboration, agility within a constantly chang-
process in the payments domain of a Dutch bank. The paper ing environment [3] and thus enabling business-IT alignment.
presents the business drivers that initiated the migration, and
describes a 4-phase migration process. For each phase, the With these claimed benefits, there has been an increasing
paper details benefits of using the techniques, best practices interest in academia to investigate approaches for migrating
that contribute to the success, and possible challenges that are legacy systems to SOA [4].
faced during migration. Based on these observations, the findings This paper presents the findings of a case study of the
are discussed as lessons learned, including the implications of
migration of a large scale legacy system from a Dutch
using reverse engineering techniques to facilitate the migration
process, adopting a pragmatic migration realization approach, bank to a SOA. For reasons of confidentiality, hereinafter
emphasizing the organizational and business perspectives, and the bank is referred to as “NedBank”. The paper describes
harvesting knowledge of the system throughout the system’s life a 4-phase migration process that is used in NedBank. For
cycle. each phase, the paper identifies the benefits of using par-
ticular techniques/methods within that phase, best practices
I. I NTRODUCTION
that helped to achieve success, and possible challenges that
In the current business environment, enterprises are pres- were faced during migration. Based on these observations,
sured to respond to changes in the market, laws and regula- the paper presents the lessons learned from the case study.
tions, and to remain efficient and innovative to reap benefits The findings of the paper not only emphasize the benefits of
from on-demand and new business opportunities. In order to using reverse engineering techniques to facilitate the migration
manage these changes and remain competitive, flexibility is process, but also urges academia to pay attention to business
required within the enterprise, supported by technology [1]. and organizational aspects. The business and organizational
Technology support itself is constantly evolving with the ad- aspects include governance of the migration process, early
vancement of new computing paradigms and improvements in involvement of the existing technical staff, and knowledge
hardware infrastructures. Enterprise systems should therefore harvesting of the system.
be designed to enable continuous evolution and to remain The paper is structured as follows: Section II discusses
responsive to new business opportunities, realizing better re- related work; Section III explains the research approach and
use and maintainability, and to improve business-IT alignment current technological landscape of the payments domain of
to achieve business goals [1]. One of the obstacles to adapt to NedBank; Section IV presents the migration process and
such changes is the presence of legacy systems [2]. Despite discusses benefits, best practices and challenges faced during
their well-known disadvantages, such as being inflexible and the migration; Section V analyzes and presents the findings as
hard to maintain, legacy systems are still vitally important lessons learned. In Section VI, the paper concludes with some
to enterprises as they support complex core business pro- potential future work.
cesses; they cannot simply be removed as they implement
and execute critical business logic effectively and accurately. II. R ELATED WORK
Unsurprisingly, the knowledge contained in these systems is
of significant value to an enterprise. On the other hand, proper De Lucia et al. [5] describe an approach and tools to migrate
documentation, skilled manpower, and resources to evolve legacy applications to web applications. Sneed [6], [7] has
these legacy systems are scarce. Therefore, momentum is contributed several wrapping techniques to migrate COBOL
growing to evolve those legacy systems within new techno- applications to SOA. A plethora of research has been reported
logical environments such as Service-Oriented Architecture on migrating legacy applications to SOA. They are reflected
(SOA) as SOA facilitates the reuse of existing assets [3]. in the survey [4]. However, considerably fewer real world case
The SOA paradigm is favored by loose-coupling, flexible studies of legacy to SOA migration are reported. Nasr et al. [8]
composition of business services, re-usability, and abstraction describe two large scale industrial case studies of legacy to
from the underlying technology platforms. Hence, migration SOA migration; Colosimo et al. [9] present an empirical study

978-1-4799-2931-3/13/$31.00 c 2013 IEEE 425 WCRE 2013, Koblenz, Germany

Practice Track
of legacy migration in Italian companies; Kokko et al. [10] the payments domain have been subjected to frequent changes
report on SOA adoption process in nine Finnish organizations. which have resulted in a “spaghetti architecture” [19] posing
The use of reverse engineering techniques in software long-term problems such as increased complexity, inflexibile
evolution has been extensively researched. Various research to changes and evolution, and increasing maintenance and
roadmaps and surveys (e.g., Bennett et al. [11], Muller et running costs. Currently, the payments domain consists of five
al. [12], Canfora et al. [13]) have been presented. As per the major legacy subsystems as detailed in Table I.
interest of this research, extracting program quality metrics
has been reported in [14], [15] and details of use of software TABLE I
D ETAILS OF THE SUBSYSTEMS IN THE PAYMENTS DOMAIN
visualization in reverse engineering & re-engineering has been
reported in a survey by Koschke [16]. Data-intensive legacy
system migration has been reported by Henrard et al. [17]. Subsystem Language Platform LOC
CalculateInterest COBOL IBM Z/OS 401,761
ForeignAccount COBOL HP Tandem 2,193,570
III. R ESEARCH BACKGROUND BalanceCheck COBOL HP Tandem 817,882
The current research has adopted an exploratory case study AccountAgreement COBOL IBM Z/OS 529,055
ReportCustomer COBOL HP Tandem 587,519
method [18], primarily reporting on how the migration is
carried out and seeking new insights about which activities are
performed during migration. Data collection in this case study
To better understand the basic working principles of and
is performed based on the participant observation method [18],
dependencies between these systems, a use case is described
wherein two of the researchers were directly involved in the
in which a customer is created and (s)he withdraws money
migration project. The data collection included the following:
from an Automated Teller Machine (ATM). Figure 1 depicts
(i) consulting documentation to identify the need for and goals
a high level sequence diagram, in which every directed edge
of the migration process; (ii) workshops & informal discus-
between two subsystems implies a coupling between the two.
sions to discuss the progress of the migration in real time, and
(iii) semi-structured interviews to understand various aspects
&XVWRPHU $FFRXQW$JJUHHPHQW %DODQFH&KHFN )RUHLJQ$FFRXQW &DOFXODWH,QWHUHVW 5HSRUW&XVWRPHU
of the migration process. In total six semi-structured interviews 2SHQ$&

were conducted. The interviews were conducted in English and &UHDWH$JJUHHPHQW

lasted between 60-120 minutes. Prior to the interviews, each 8SGDWH,QIRUPDWLRQ

8SGDWH,QIRUPDWLRQ
expert was introduced to an interview protocol, a document 8SGDWH,QIRUPDWLRQ

detailing the objectives of the interview with some sample 3URYLGH$&QR 8SGDWH,QIRUPDWLRQ

:LWKGUDZ$PRXQW
questions, and a glossary of the technical terms to attain a &KHFN YDOLGDWH

common understanding. 5HWXUQ$PRXQW

%DWFKXSGDWH
Research Context: NedBank is one of the largest banks
&DOFXODWH &DOFXODWH
in the Netherlands with more than 900 branches worldwide. 8SGDWH 6\QFKURQL]H 6\QFKURQL]H

Triggered by the Single Euro Payment Area (SEPA) initiative 8SGDWH

of the European Union, NedBank started the migration of its

core banking systems under a project that started in 2010
and is expected to end in 2018. The main objective of this Fig. 1. Sequence diagram depicting coupling within the payments domain
project is to renovate and migrate its legacy systems to SOA.
The estimated cost of the project is 600M Euro. The project A new contract for opening an account is created in a
is subdivided into 6 different portfolios: channel support, Siebel-based sales environment in one of the local branches.
payments, current accounts, customer reporting, counter, and During the account opening process, Siebel requests several
sales & product agreements. After an initial investigation, this AccountAgreement services in order to get an account number
research is scoped to the migration of the payments domain and to create agreements for the customer. The account and
because of the following two reasons: (i) the subsystems agreement creation are processed in real-time. Upon open-
within the payments domain are diverse with respective to ing an account for a customer, the other four subsystems
programming languages, hardware and operating systems in (BalanceCheck, ReportCustomer, ForeignAccount and Calcu-
use, and (ii) the payments domain is of prime importance in lateInterest) are updated accordingly. When the customer with-
the day-to-day operation of the banking business. draws money from an ATM, initially the request is validated
The payments domain is responsible for the overall manage- with the agreements stored in the BalanceCheck subsystem
ment of banking transactions including foreign transactions, and the withdrawn amount is reserved from the customer’s
and interest & cost calculation per transaction of NedBank account. Such individual banking transactions are stored in a
customers. The subsystems within the payments domain are flat file and at the end of the day, the flat file is updated with the
considered to have high impact on the business of NedBank transactional information from the ForeignAccount subsystem:
and have a high priority within the banking system. The a subsystem responsible for recording the foreign transactions.
payments domain was one of the first domains to adopt Afterwards, the flat file is processed by the CalculateInterest
automatization in NedBank. Over the years, the subsystems of subsystem that is responsible for interest, commission and

426
cost calculations, and synchronizing the updated records to in developing and executing the migration process, aligning
the other subsystems. the business goals with the architectural requirements, and
From the information in Table I, it is obvious that the sub- coordinating architectural priorities inline with the business
systems of the payments domain are combined with heteroge- goals.
neous IT infrastructures with variations in the COBOL dialects Benefits, Challenges and Best Practices: A legacy to SOA
used, and the hardware platforms on which they operate. The migration is a multifaceted process that involves technical,
subsystems range from internally developed subsystems like organizational and business issues [20]. To manage such a
CalculateInterest to third party built-in packaged subsystems multifaceted process, a central governing body with suitable
such as ForeignAccount. The subsystems are efficient in terms governance of the entire migration process is indispensable.
of performance, capable of effectively analyzing, processing Needless to say, a legacy to SOA migration is a complex and
and synchronizing millions of records. Nevertheless, to achieve challenging process and any failure can threaten the success
such performance, various features within the subsystems are and fortune of an enterprise [21]. In particular, software
duplicated and/or updated in ad-hoc manner, increasing system failures in the financial domain not only cost millions but
complexity. The increase in complexity has now become a also decrease customer confidence1 . In this migration process,
bottleneck to the changeability of the subsystems within the the formation of the Program Management Committee has
payments domain. suitably fulfilled the need of such a governing body and hence,
Additionally, based on our observations (interview, doc- contributes towards a successful migration. The teams within
umentation, workshops and informal discussion), the main the Program Management Committee have clear responsibil-
business goals of the NedBank upon migrating to a SOA are ities such that any unpredicted changes were systematically
(i) accelerating time-to-market, (ii) reducing costs in the pay- resolved. For instance, any Request For Change (RFC) is
ments domain, (iii) transparency in ownership & governance primarily resolved by the Business Change Management and
of the products, and (iv) preventing knowledge erosion. Architecture Board unless the RFC has high business priority
and higher estimated cost than a chosen threshold value.
IV. T HE M IGRATION P ROCESS Then, the RFC is forwarded with recommendations from
In this section, we explain the legacy to SOA migration the Business Change Management and Architecture Board to
process of the payments domain. Due to the complexity and the Core Team and to the Steering Committee for further
tight coupling between the subsystems of the payments do- considerations.
main, the activities within the migration process are performed Realizing that a large scale migration to SOA is not only a
in a phased, controlled manner based on the business prior- technical endeavor, the existing knowledge within the technical
ities. The migration approach consists of the following four staff need to be utilized. The involvement of technical staff
phases, being: (i) Forming a migration program management (legacy system developers and maintainers) in the committees
committee, (ii) Developing a logical target-architecture, (iii) facilitated the knowledge transfer to the migration team. It
Analyzing the gap, and (iv) Realizing the migration. is a recurring phenomenon that the technical staff is hesitant
to share knowledge due to the fear that their expertise may
A. Forming a Migration Program Management Committee become redundant due to migration. This phenomenon was
The legacy to SOA migration process needs to be capable countered here by involving the technical staff to actively
of addressing various kinds of issues including business, participate in the migration process.
organizational and technical issues [8]. The migration process
involves a long term investment of resources and is aimed B. Developing a Logical Target-Architecture
at conducting a large-scale migration by performing activities Initially, a logical target-architecture conforming to the
with minimal dependencies and maximal parallelization. Thus, business goals was developed. A logical target-architecture
to establish a suitable planning and management, a governing forms the organizing logic for business processes and IT in-
body, the Program Management Committee, was created. It frastructure, in which the business components are contained.
includes various stakeholders representing senior management Developing a logical target-architecture that conforms to the
officials, business architects representing the different business business goal was not an easy task. To start with, a group of
units, software architects and technical managers, external con- members from the migration project initially participated in a
sultants and application developers. The committee is divided workshop to define a functional architecture: an architectural
into the following teams with specific responsibilities: a Steer- model that identifies features that contribute to achieving the
ing Committee to develop a strategic policy for the migration; business goals. The team members included business process
a Core Team to develop the business-IT alignment strategy; analysts and business architects from the Business Change
a Program Management team to manage the payment portfo- Management team along with software architects and appli-
lio; a Business Change Management team to ensure proper cation developers from the Architectural Board. Various other
alignment of business goals with the IT architecture; and external consultants and experts from financial software ven-
an Architecture Board to develop an architectural governance dors also participated in the workshop. Together they provided
within the payments domain. The role of the Business Change
Management and Architecture Board is crucial, in particular, 1 IT failure of Royal Bank of Scotland (RBS): http://goo.gl/xpDjy

427
the initial blueprint of the functional architecture. Following many systems ranging from in-built COBOL system such as
the first workshop, three more workshops were conducted CalculateInterest to a third party packaged application such as
that resulted in identifying various business components to ForeignAccount. There are not only variations in the COBOL
realize the initial functional architecture as shown in Figure 2. dialect, but also in the running platform such as IBM Z/OS, HP
The identification of the business components, referred to as Tandem Nonstop. Also, the documentation of most subsystems
“componentization”, was one of the initial activities to realize was outdated. An investigation of the documentation quality
potential candidate services. The notion of componentization of the CalculateInterest system identified missing technical
is a way to construct a business component, which corresponds documentation (TD), limited finalized/approved documenta-
to a feature contributing towards a business goal. tion, and fairly good functional documentation (FD). However,
the details of the TD and FD for features are still not
Distribution complete. Furthermore, the technical quality characteristics
such as coupling, maintainability, and duplication within the
Counter support functionality Channel support functionality
Payment Payment subsystems were still unknown.
Card Issuing Functionality Channel2
Channel1 As a starting point, all the subsystems of the payments do-
Customer Account related functionality Payment processing functionality
main were analyzed using source code analyzers to determine
Product
Configurator
Current Account Service Book Entry the program quality in terms of quality metrics including main-
Payment Engine tainability, module coupling, duplication and changeability.
Payment Facility
Product
Internal
These quality metrics were derived using reverse engineering
Agreement SEPA
Interest Commission Cost Command tools. Such quality metrics provided a better understanding of
the technical qualities of the subsystems within the payments
Number
Pool
Reporting Vere Fens domain. Table II depicts an excerpt of the assessment results
of the subsystems in the payments domain in which Maint.
represents maintainability; Coup. represents coupling; Dup.
Fig. 2. Logical Target Architecture
represents duplication; Change. represents changeability and
Test. represents testability metrics. Refer to [14], [15] for the
Previously, such features were scattered over various sub- details and explanations of these metrics, as they are out of
systems. For instance, the “calculate interest” feature was the scope of this paper.
previously found in two subsystems: (i) CalculateInterest and
(ii) BalanceCheck. Earlier, “product agreements” feature was TABLE II
E XCERPT OF LEGACY ASSESSMENT RESULT
also distributed over various subsystems. In the logical target-
Name #prog Maint. Coup. Dup. Change. Test.
architecture, related features are gathered within one logical CalculateInterest 913 2.10 2.14 1.32 2.06 2.13
unit to ensure that architecture governance is easy, and to ForeignAccount 9249 1.07 2.47 1.24 1.95 1.80
minimize the product gaps within the payments domain. BalanceCheck 2902 2.03 2.70 1.32 2.05 1.72
AccountAgreement 1364 2.45 3.69 1.34 2.33 1.77
Benefits, Challenges and Best Practices: Identifying busi-
ReportCustomer 918 2.25 3.04 1.23 2.24 1.82
ness components representing potential candidate services in
legacy to SOA migration is a challenging task. In this migra-
tion process, a goal-service modeling approach, proposed by Furthermore, to have an in-depth understanding of the
Arsanjani et al. [22], is followed. A goal-service modeling technical qualities of each COBOL program, a detailed anal-
approach is used to componentize the business component ysis was carried out for each subsystem using proprietary
because it ties services to the business goals. Each identified automated source code analyzers. Such a detailed analysis pro-
candidate service was prioritized based on its business value. vided insights into individual COBOL programs within each
Additionally, a catalogue for each business component was subsystem. For instance, individual programs were categorized
created, indicating the degree of reusability by other compo- into good, bad and average based on their complexity. Figure 3
nents and possible functional dependencies (coupling) with depicts an excerpt of a detailed program analysis derived
other components in the logical architecture. Such a catalogue from source code analyzers of the CalculateInterest COBOL
provides an overview of components whose migration can programs. Due to space limitations, the detailed analysis is
be performed independently, preferably in parallel with other not presented in this paper, but anonymized reports of the
relatively independent components and hence, maximizing CalculateInterest and the ForeignAccount are available2 .
parallelization of the migration process. In total, 44 different As a part of the legacy assessment, a call dependency
high level features were identified. diagram of the subsystems was generated and analyzed based
upon number of incoming call (NIC) and number of out-
C. Analyzing the Gap
going calls (NOC). As a result, numerous computationally
The third phase of the migration process is to gather and intensive COBOL programs (with high NIC and high NOC)
determine the information about the legacy system features and core libraries (with high NIC) within each subsystems
that can contribute to the realization of the logical target-
architecture. The payments domain consists of a mix of 2 http://goo.gl/bwqnq

428
 Max Norm 30 0 1000 15% 90 5000
Good
Max Norm 0 30 2000 10% 120 10000
Average
McCabe
# Cobol Lines of Complexity Maintainability Check Check Check Check Check Check
Program Code v(G) Index Maintainability Miwoc Volume Comments McCabe Metrics
(LoC) (MI) Index NCLoC
1 RT00000 464 20 53.4951227 Good Good Good Average Good Good
2 RT00100 1120 84 6.5556751 Average Average Good Bad Good Bad
3 RT00200 1273 85 2.7461408 Average Average Average Bad Good Bad
4 RT00400 559 26 38.7093703 Good Good Good Bad Good Good
5 RT00800 505 38 39.2838751 Good Good Good Bad Good Good
6 RT00900 1137 79 6.2149798 Average Average Good Bad Good Bad
7 RT01100 467 20 45.5457803 Good Good Good Bad Good Good
8 RT01200 542 28 40.7082519 Good Good Good Bad Good Good
9 RT01400 1011 67 20.4825089 Average Average Good Bad Good Average
10 RT01500 882 39 31.7499408 Good Good Good Average Good Average
11 RT01600 1853 115 7.6646816 Bad Average Average Bad Bad Bad
12 RT01700 248 6 84.4787602 Good Good Good Good Good Good
13 RT01800 360 11 60.5492274 Good Good Good Bad Good Good

Fig. 3. Excerpt of a detailed program analysis of the CalculateInterest COBOL programs

were identified, following the work of Geet & Demeyer [23]. quality in terms of software metrics such as maintainability,
Such programs were later manually investigated to locate module coupling, duplication, changeability. Such software
features within the subsystems. Figure 4 depicts an excerpt metrics have been extensively used in the software evolution
of the generated call dependency diagram of the CalculateIn- domain, for instance, to determine the reusability factor [6]. To
terest subsystem in which the red-circled programs (RT23N, better understand the individual programs within each subsys-
RT23M, RT20K and RT009), for instance, could potentially tem, the program level quality metrics along with the program
be core libraries of interest. visualization in the form of a call dependency diagrams were
After the legacy assessment, an inventory of high level fea- generated using reverse engineering tools. Furthermore, the
tures available within the subsystems of the payments domain interview sessions with the technical staff of the payments
was created. The inventory of the features was created by domain proved to be extremely important. Needless to say,
consulting the available documentation and interviewing the intimate knowledge of the existing resources is essential to a
technical staff of the subsystems. The latter method proved to successful migration, and necessary steps should be taken to
be very useful and confirms that the knowledge residing within harvest and preserve such existing knowledge.
the organization is of the utmost importance. The inventory D. Realizing the Migration
of the high level features was then analyzed by the Business The payment domain of the bank has a heterogeneous
Change Management and Architecture Board to determine the IT infrastructure with some of the features being efficient
priority and business value. The features were then mapped to and robust with respect to performance while others being
the logical components within the logical target-architecture rigid commercial off-the-self (COTS) applications. In such a
via the gap analysis method [24]. The mapping was performed scenario, relying on a single approach to realize migration is
by focused workshops conducted for each subsystem in which not a viable solution. Thus, the migration process made the
business analysts, application analysts, consultants, developers following four explicit choices for realization:
and lead architects discuss and finalize the mapping of each 1) Reuse and/or Upgrade: One of the key performance
subsystem. This mapping approach was effective such that the indicators of a bank is accuracy and efficient processing of
migration team not only identified the mappings, but also the voluminous financial transactions. In the payments domain,
dependencies within the high level features of the subsystems. some of the features are highly robust in terms of accurate
Table III depicts an excerpt of the feature mapping of the and efficient processing of transactions. Such features are
CalculateInterest and the AccountAgreement to the logical either reused or upgraded based on their business value and
target-architecture. the program quality characteristics derived in the “legacy
Benefits, Challenges and Best Practices: The “analyzing assessment” of the “analyzing the gap” phase. For example,
the gap” phase enabled the migration team to catalogue the the “calculate interest” feature is reused. With regards to the
existing features with the aim to maximize reuse features. CalculateInterest subsystem, one of the business analysts says
In particular, the use of reverse engineering tools/techniques “The clear separation in the features of the CalculateInterest
has facilitated understanding the current legacy assets, their subsystem has eased our maintenance. Also, if we consider
technical qualities, and identifying the potential features based rebuilding or splitting the features then the impact will be very
on call dependency diagrams. The “analyzing the gap” phase high– technically and economically and we are not sure if we
has not only been effective in identifying, prioritizing and can achieve the current performance. Thus, for the time being
determining the granularity of existing features, but also in we decided to reuse the features of the CalculateInterest”.
determining which feature is to be reused. The legacy assess- 2) Package Replacement: Numerous logical components
ment activity contributed to identifying the technical program within the logical target-architecture cannot be directly

429
 Fig. 4. Excerpt of a call dependency diagram of the CalculateInterest COBOL programs

TABLE III
E XCERPT OF FEATURE MAPPING TO THE LOGICAL TARGET- ARCHITECTURE
High Level feature Target Arch. Component Priority Remarks
CalculateInterest
Register data Bank Administration High –
Calculate interest Interest High Merge international interest
Bank guarantee commission Fees Medium –
Checkout coupon Interest Medium To be included in the Interest logical component
AccountAgreement
Opening accounts/contracts Product Agreement High Merge current agreements in current account
Account management Number Pool High –
Managing data rate Product Configurator Low Include tariff data from other components

mapped to existing features of the legacy applications. Thus, the requirements as formulated in the outsourcing strategy-
some of the components in the target-architecture are being guidelines to ensure that outsourcing is done via strategic
replaced by a packaged solution. The decision to replace is partners and only when no other option is viable. A lead
reached by assessing the technical program qualities and eco- architect explains the need of outsourcing as “Features that
nomical feasibility of the feature. One of the examples of such are of low business value and can be developed cheaply are
a replacement is within the features of the ForeignAccount outsourced such as card authorization and card payments. This
subsystem, which in itself is a third party packaged subsystem helps us to focus on the high priority features.”
responsible for international payments. Thus, the features of
the ForeignAccount subsystem are replaced by a packaged The selection of an appropriate realization option is based
solution. An application architect says “ForeignAccount is a on various factors such as business value of the logical
package software with very limited documentation and reusing component, technical quality of the legacy assets, cost of
its features will lead to long-term maintenance problems in the implementation and the importance of ease of upgrading/up-
future. So we decided to replace it with a packaged solution”. dating.
3) Customized Replacement: With the introduction of the Benefits, Challenges and Best Practices: Realization of
Euro currency, various laws and regulations within the pay- the migration is the starting point of implementing the logical
ment domain have changed in the European Union. The components. Realization is not only about deciding which
bank has to comply with such changes. One of the business programming language is to be used, but also the associated
consultants emphasizes the importance of the SEPA stating environment such as hardware and operating system. The
that “SEPA is one of the triggers for the renewal of the whole other factor that contributes to the success of realization is
payments infrastructure. It is also one of the main business the determination of the suitable granularity of the poten-
drivers for lowering cost. Such crucial features have to be tial candidate services. In this migration project, there were
custom–built so that its maintenance and upgrade in the future predefined guidelines provided by the program management
will be easy for us”. committee on deciding which realization option to use. The
4) Outsourcing: The final option is to outsource an entire guidelines were developed by considering “external vs internal
feature to an external party for development. This option development” and “adoption of existing vs new technology”.
is chosen only if outsourcing contributes to the strategic Figure 5 depicts the realization options based on development
objectives of Payments (such as cost reduction) and must fulfill and technology adoption criteria.

430
 Existing Technology New Technology
COBOL programs for services, the generation of call depen-
dency graphs of the subsystems was helpful. For instance,

Internal
Reuse and/or Customized
Upgrade Replacement based on the work of Van Geet et al. [23], the red-circled
programs (RT23N, RT23M, RT20K and RT009) of Figure 4,
Technology
were COBOL programs of interest as they have high number
of incoming calls (NIC). Thus, upon generating and analyzing
External

Packaged
Outsourcing
Replacement the call dependency graph those programs were investigated
by the existing programmers to identify their functionalities.
(ii) Knowledge Harvesting: Most of the documentation of
Development
the subsystems was either outdated or incomplete. With the
Fig. 5. Realization Choices results of the reverse engineering techniques, a considerable
amount of new information about the programs was identified
that were even unknown to the current maintainers of the
A crucial criterion to determine the realization option was subsystems. For instance, 599 out of 21085 copybooks are not
the business value and priority of the logical component. For used by the “CalculateInterest” subsystem. This finding was
instance, central to NedBank’s business are the calculation a surprise to the current maintenance team of the subsystem.
of interest, commission and cost calculation features. The Additionally, the flow graphs were generated to understands
logical components encompassing these features are reused the overall flow of the programs within the subsystem. These
and/or upgraded from the existing ones. Upon deciding to artifacts helped to update the documentation.
reuse and/or upgrade, the technical qualities of the features B. Adopting a Pragmatic Realization Approach
are examined to estimate the migration time. It was not
always simple to reuse or upgrade, particularly for third party In the realization phase of the migration process, a prag-
packaged solutions that are not updated or supported by the matic approach for executing the migration is adopted in which
vendor anymore. For instance, the vendor who developed the choices are based on various factors such as business value,
COBOL running in HP Tandem Nonstop went through various business priority, and the technical qualities of the features.
mergers and acquisitions such that the infrastructure is hardly The initial choice of reusing the existing functionalities is
updated and maintained. In such cases, a suitable packaged one of the notable benefits claimed by the proponents of
replacement is preferred. Any new logical component with SOA for leveraging existing assets. However, in a large scale
high business value falls under the “Customized Replacement” legacy application, reuse is not always feasible. Therefore, the
option. A low priority logical component is outsourced to a migration process of NedBank suitably adapted other possible
third party upon strictly fulfilling the “outsourcing” criteria. realization methods for a successful migration. Additionally,
for large scale legacy applications that include heterogeneous
V. L ESSON L EARNED IT infrastructures (diverse programming languages, various
hardware and operating systems) there is no silver bullet
A. Implications of Reverse Engineering Techniques solution to realize the migration process. For a successful
The reverse engineering techniques that are used in this migration process, any approach can contribute to the success
migration project had a significant role in finding the facts of the migration, provided that the approach is well defined,
of the current legacy programs and subsystems. In particular, and suited for the enterprise.
the use of such techniques in the “analyzing the gap” phase
to obtain various metrics and call dependency graphs not only C. Emphasizing Organizational and Business Perspectives
facilitated the creation of an inventory of the current assets, but Migration from legacy to a SOA environment is not only a
also identified computationally intensive COBOL programs. technical endeavor, but also involves significant issues from
In addition to creating an inventory of the current assets, the organizational and business perspective. Particularly in
using reverse engineering techniques has the following two the case of legacy systems having no or outdated documen-
implications: tation, early involvement of existing technical staff in the
(i) Assisting in Selecting the Realization Approach: The use migration process is proven to be useful. The involvement
of reverse engineering techniques has strongly facilitated the of the technical staff facilitates the knowledge transfer to the
selection of the realization approaches in the migration pro- migration team. The synergy between the technical staff and
cess. The migration team used the program quality metrics the migration team that was observed in this migration process
generated by the reverse engineering tools to estimate the was one of the key factors contributing towards the success of
complexity of the programs. For example, in Figure 3, the the migration. Equally important is the focus of the “Program
COBOL program RT01600 has high McCabe complexity and Management Committee” in the business-IT alignment that
a negative maintainability index (MI). Hence, RT01600 is a facilitated the migration to achieve the business goals. An
potential candidate of replacement unless it has a low business important lesson learned is that technical staff tends to resist
priority. Similarly, programs with good and average index change because they fear that their expertise and professional
have potential for reuse. In case of identifying candidate experience with legacy systems may become redundant due to

431
the introduction of SOA. Therefore, it is important to involve how to automatically translate legacy applications to a modern
the technical staff from the start of the migration process language.
and provide necessary training to adapt to new technology. In
R EFERENCES
the current migration process, the formation of various teams
under the “Program Management Committee” has actively [1] M. van Sinderen, “Challenges and solutions in enterprise computing,”
Ent. Inf. Sys., vol. 2, no. 4, pp. 341–346, 2008.
involved the technical staff whose knowledge about the legacy [2] K. Bennett, “Legacy systems: coping with stress,” IEEE Soft., vol. 12,
systems have proven to be of significant importance. no. 1, pp. 19–23, 1995.
[3] M. Papazoglou, P. Traverso, S. Dustdar, and F. Leymann, “Service-
D. Harvesting Knowledge to Prevent Knowledge Erosion oriented computing: State of the art and research challenges,” Computer,
Apart from available documentation, existing knowledge in vol. 40, no. 11, pp. 38–45, 2007.
[4] R. Khadka, A. Saeidi, A. Idu, J. Hage, and S. Jansen, “Legacy to
the form of skills and experience within the technical staff SOA evolution- a systematic literature review,” in Migrating Legacy
is one of the most important assets. Over the years, such Applications: Challenges in Service Oriented Architecture and Cloud
knowledge and skills become scarce resulting in knowledge Computing Environments, A. D. Ionita, M. Litoiu, and G. Lewis, Eds.
IGI Global, 2012, pp. 40–71.
erosion due to factors such as ageing, and staff changing jobs. [5] A. De Lucia, R. Francese, G. Scanniello, and G. Tortora, “Developing
Hence, suitable strategies such as conducting and archiving legacy system migration methods and tools for technology transfer,”
interviews, and initiating knowledge transfer programs via Soft.:Pract. Exp., vol. 38, no. 13, pp. 1333–1364, 2008.
[6] H. M. Sneed, “A pilot project for migrating COBOL code to web
training should be undertaken to harvest and preserve such services,” STTT, vol. 11, no. 6, pp. 441–451, 2009.
existing knowledge. In the migration process of NedBank, the [7] H. M. Sneed, “Migrating from COBOL to Java,” in International
involvement of the technical staff in the migration process has Conference on Software Maintenance. IEEE, 2010, pp. 1–7.
[8] K. Nasr, H. Gross, and A. van Deursen, “Realizing service migration in
significantly helped in knowledge harvesting and preservation industry–lessons learned,” J. Soft. Maint. Evol., 2011.
while creating inventories of the high level functionalities [9] M. Colosimo, A. D. Lucia, G. Scanniello, and G. Tortora, “Evaluating
of the subsystems. Some of technical staff were interviewed legacy system migration technologies through empirical studies,” Inf.
Soft. Tech., vol. 51, no. 2, pp. 433–447, 2009.
and focused training programs were organized to facilitate [10] T. Kokko, J. Antikainen, and T. Systa, “Adopting soa–experiences from
knowledge transfer. Additionally, the existing documentation nine finnish organizations,” in 13th European Conference on Software
was updated or created in case if no documentation exists. Maintenance and Reengineering. IEEE, 2009, pp. 129–138.
[11] K. H. Bennett and V. T. Rajlich, “Software maintenance and evolution: a
VI. C ONCLUSION roadmap,” in Future of Software Engineering. ACM, 2000, pp. 73–87.
[12] H. A. Müller, J. H. Jahnke, D. B. Smith, M.-A. Storey, S. R. Tilley,
In this paper, we present the findings of a case study and K. Wong, “Reverse engineering: a roadmap,” in Future of Software
of a large scale legacy to SOA migration process within Engineering. ACM, 2000, pp. 47–60.
the payments domain of a Dutch financial institution. The [13] G. Canfora and M. Di Penta, “New frontiers of reverse engineering,” in
Future of Software Engineering. IEEE, 2007, pp. 326–341.
paper presents the business drivers that initiated the migration, [14] I. Heitlager, T. Kuipers, and J. Visser, “A practical model for measuring
and describes a 4-phase migration process. The migration maintainability,” in 6th International Conference on Quality of Informa-
process equally focuses on the technical and the business & tion and Communications Technology. IEEE, 2007, pp. 30–39.
[15] Y. Kanellopoulos, C. Tjortjis, I. Heitlager, and J. Visser, “Interpretation
organizational aspects of the migration. The migration process of source code clusters in terms of the iso/iec-9126 maintainability
starts by forming a “Program Management Committee” for characteristics,” in European Conference on Software Maintenance and
proper governance. Then, a logical-target architecture is devel- Reengineering. IEEE, 2008, pp. 63–72.
[16] R. Koschke, “Software visualization in software maintenance, reverse
oped based on the concept of componentization. The business engineering, and re-engineering: a research survey,” J. Soft. Maint. Evol.,
components within the logical target-architecture are aligned vol. 15, no. 2, pp. 87–109, 2003.
to support the business goals. The logical target-architecture [17] J. Henrard, D. Roland, A. Cleve, and J.-L. Hainaut, “An industrial expe-
rience report on legacy data-intensive system migration,” in International
is then mapped to the existing legacy features using a gap Conference on Software Maintenance. IEEE, 2007, pp. 473–476.
analysis method. Such a gap analysis suitably supports the [18] P. Runeson and M. Höst, “Guidelines for conducting and reporting case
potential of reusing the legacy features without significant study research in software engineering,” Emp. Soft. Eng., vol. 14, no. 2,
pp. 131–164, 2009.
changes to the legacy systems itself– one of the key promises [19] R. Heckel, R. Correia, C. Matos, M. El-Ramly, G. Koutsoukos, and
of the SOA. The migration is then realized following the L. Andrade, “Architectural transformations: From legacy to three-tier
pragmatic realization options of the migration process. and services,” in Software Evolution, T. Mens and S. Demeyer, Eds.
Springer, 2008, pp. 139–170.
The paper presents an industrial report detailing how reverse [20] S. Murer, B. Bonati, and F. Furrer, “Very large information system
engineering techniques were employed to facilitate a large challenge,” in Managed Evolution. Springer, 2011, pp. 3–34.
scale legacy to SOA migration process. It illustrates the pain of [21] R. N. Charette, “Why software fails,” Spectrum, vol. 42, no. 9, pp. 42–
49, 2005.
the practicalities and under-emphasized aspects of a large scale [22] A. Arsanjani, S. Ghosh, A. Allam, T. Abdollah, S. Ganapathy, and
migration project, and should be considered a call-to-action K. Holley, “SOMA:A method for developing service-oriented solutions,”
for computer scientists to study the project environment, both IBM Sys. J., 2008.
[23] J. Van Geet and S. Demeyer, “Lightweight visualisations of COBOL
from a business and organizational point of view, as much as code for supporting migration to SOA,” Symposium on Software Evolu-
they study the technical aspects of migration. tion, vol. 8, 2008.
As to future research, we aim to exploit model-driven [24] G. Lewis, E. Morris, and D. Smith, “Service-oriented migration and
reuse technique (SMART),” in Workshop on Software Technology and
modernization approaches to extract features from the sub- Engineering Practice. IEEE, 2005, pp. 222–229.
systems. Another interesting research area is to investigate

432