Reengineering Autonomic Components in Legacy
Software Systems: A Case Study
James. J. Mulcahy
Florida Atlantic University
Computer Science & Engineering
Boca Raton, Florida, 33431, USA
jmulcah1@fau.edu
Abstract—Modern enterprise-scale software systems in the
retail industry are often implemented as systems of systems that
are composed of one or more legacy software components
making up parts of a supply chain that deliver products to both
in-person and online customers. The systems are often one-off
complex implementations tailored to the needs of that particular
stakeholder. System components may communicate with other
internal legacy components like accounting and warehousing
systems or external third-party components that handle order
processing, security screening, or shipping-related tasks. From
time to time, stakeholders may need to adapt their systems by
replacing or modifying one or more of the sub-system
components to operate on new hardware, communicate with
other components using different data communication
techniques, or to interact with new external third-party solutions.
It is therefore useful for solutions for the individual components
to be designed with an architecture that lend themselves to be
easily reengineered or replaced without disturbing the other
system components, and without adding significant complexity to
the overall system of systems. In prior works, the authors of this
paper introduced in a series of case studies a repeatable
architectural design pattern that implemented self-adaptive
autonomic interaction managers (AIMs) that not only reduced or
eliminated the need for human operators to monitor, tune, or
troubleshoot the implemented components, but could be easily
modified or reengineered in the future to adapt to new operating
environments.
The contribution of this paper is the testing of the efficacy of the
AIM design introduced in prior works by the authors, by
simulating the reengineering of a set of AIMs tasked with
handling web-based order traffic between the stakeholder system
and Amazon.com. In this effort, the AIMs were re-implemented
on a different operating system, coded in a different
programming language than the original implementation, using a
different data communication protocol to communicate with
other systems. The authors simulated web-based order traffic to
test the resulting implementation. The effort demonstrated that
using the original autonomic design patter, AIMs could be
rapidly adapted to a new environment, while maintaining
original behavior and without adding complexity to the
stakeholder’s system.
Keywords—software engineering, software reengineering,
legacy systems, autonomic computing
978-1-5090-4623-2/17/$31.00 ©2017 IEEE
Shihong Huang
Florida Atlantic University
Computer Science & Engineering
Boca Raton, Florida, 33431, USA
shihong@fau.edu
I. MOTIVATION
The motivation for this work comes from the typical
challenges faced by stakeholders of legacy enterprise resource
planning systems, known as “ERPs.” An ERP system is often a
significant investment for its stakeholder. It is typically tailored
to the specific needs for the business it supports, and may be
unique enough to make replacement or extensive reengineering
economically unfeasible. ERPs are systems composed of a
complex combination of software applications that cover many
of the major business processes of the business they support
[1]. These days, ERPs are more likely to be legacy systems
than not, and maintaining their business value requires
evolving them to adapt to changes in technology or the
exposure of third-party solutions that can replace or enhance
some of their internal operation (i.e. order entry, shipping,
auditing) [2].
Maintaining systems to preserve or enhance business value
is one of the most expensive aspects of software engineering
with respect to legacy systems [3][5]. Modifying an existing
system tends to add complexity and fault-proneness to that
system unless its components are explicitly designed to
mitigate these challenges [6]. One approach used by
practitioners is the development of systems or parts of systems
that are self-adaptive and mitigate the need for humans to
operate or to maintain them [4]. Removing humans from the
loop using autonomic design was described by IBM in 2001
when they identified four major self-adaptive attributes or
behaviors that make a system or system component
“autonomic” [7]:
Self-configuring – The software recognizes changes to its
environment and reacts to address those changes.
Self-optimizing – The software automatically adjusts its
behavior to more efficiently complete its tasks.
Self-healing – The software recognizes system faults or errant
conditions that jeopardizes normal operation and
automatically takes steps to repair or mitigate those
conditions.
Self-protecting – The software recognizes conditions that can
produce system faults and takes steps to avoid them.
 In prior works, the authors produced case studies describing architecture (SOA) approach to exchange data with third-party
real-world development projects during which autonomic stakeholders. Simplified Object Access Protocol (SOAP) was
components designed to exhibit the four aforementioned used to communicate with Amazon for the exchange of
behaviors were implemented to handle order entry by consumer order information. The new implementation would
customers using external marketplace systems [10], security use a simpler File Transfer Protocol (FTP) approach.
screening of customers and orders for sensitive products [11],
The following section contains some preliminary results of
and for handling the shipping process for returned order items
a proof-of-concept effort that implemented the afore-
[12]. Autonomic interaction managers (AIMs) were used as
mentioned changes. The effort took less than fifty (50) man-
data brokers between the legacy stakeholder system and third-
hours to accomplish and the resulting implementation retained
party systems. The resulting solutions were designed to
the autonomic behavior of the original solution.
minimize human error and reduce human effort needed to
monitor and tune the interaction between stakeholder and
external systems. II. THE SOLUTION
The legacy ERP retail system adapted by this work includes
It is not enough, however, to produce solutions that reduce
an order fulfillment process that uses a legacy order
the complexity and human involvement in a system of
systems. Because technology is ever-changing, the solutions processing API to import new customer orders. The orders are
should be fairly easily adaptable to new technical then checked for validity and product availability, and then
prepared for processing by the stakeholder’s warehouse
requirements and stakeholder needs. For example, a
system (Fig. 1). In the warehouse, the orders are “picked”
stakeholder may need or desire to alter the environment in
from inventory and “packed” into containers (e.g., boxes) for
which parts or all of their legacy ERP systems and subsystems
shipment, steps that are collectively referred to as “pick &
operate. Hardware components may become obsolete, as may
software hat the legacy systems interact with. Apart from pack.”
necessity, the stakeholder’s motivation may be to address non- A second external system owned by the stakeholder hosts a
functional requirements like cost, efficiency, reliability, or Simple Object Access Protocol (SOAP) server that
even security. communicates with Amazon’s Marketplace Web Service
application programming interface (API) known as MWS. The
Any number of changing or new requirements can motivate
stakeholders of legacy systems to evolve their systems. It is basic order flow from Amazon to the stakeholder’s system is
therefore advantageous that system components be designed shown in Fig. 2.
with an architecture that is easily adaptable to change without An AIM component is used to collect customer order files
expensive and complex reengineering efforts. In prior works, from Amazon using Amazon’s MWS API, and are staged to
the authors used an approach the lent itself to future the SOAP server. The order files are periodically transferred
adaptation. In the project described by this paper, we by one of the asynchronous AIM components to the
simulated the reengineering of autonomic middleware stakeholder’s minicomputer, an HP 3000 running the MPE/iX
components developed for a company that offered a subset of operating system. The stakeholder is hereafter referred to as
its product line for sale on Amazon.com, a popular e- the “host” machine and the SOAP server as the “target”
commerce platform. machine. The communication between the SOAP server and
Amazon is beyond the scope of this paper.
In our case study scenario, existing AIM components that
were part of the stakeholder’s existing order processing
workflow were to be retired from an HP3000-based
minicomputer and re-implemented to operate on a personal
computer using the Microsoft Windows operating system.
This was not a simple matter of copying source code to a new
machine and rebuilding the solution from it.
The original AIMs had been constructed using a
combination of scripts and applications. The scripts were
written in a job control language (JCL) that was native to the
HP3000 and would have to be reengineered as “batch” scripts
native to the Microsoft Windows command prompt
environment. The applications for the original AIMs were
written in the COBOL programming language. The new
implementation would require reengineering these
applications using the C++ programming language. The Fig. 1. Stakeholder Order Processing Flow
original implementation included a service-oriented

Fig. 2. Order Flow between Amazon & Stakeholder
A second AIM component is tasked with checking the host
machine for un-processed orders. Un-processed orders are
injected into the ERP system’s order database using a legacy
order processing API. The API generates as output an order
acknowledgement file for each of the processed orders, and
stages them on the host machine until they can be transferred
to the target machine.
A third AIM component periodically gathers the
previously-generated order acknowledgement files and
transfers them to the target machine. The target machine’s
SOAP implementation periodically transfers the files in
batches to Amazon. Amazon generates customer emails using
the acknowledgement files, informing each customer that the
order they placed has been accepted and processed by the
stakeholder.
Each of the three AIM components are written in job
control language (JCL) in scripts referred to as job streams.
The job streams are composed of both system-level commands
and the execution of application programs written in the
COBOL programming language. The architecture describing
the flow of customer orders from Amazon to the host machine
and the flow of order acknowledgements from the host
machine to Amazon using the autonomic interaction managers
is shown in Fig. 3.
Fig. 3. Amazon/Stakeholder Architecture
The platform on which the original components were
implemented was being sunsetted by the hardware vendor and
it was expected that the stakeholder would seek to implement
the components in a different environment in the future. In
this section we describe the proof of concept that was
undertaken to re-implement the AIM components to test the
efficacy of the repeatable architectural approach by which the
original solution was implemented.
This section describes the solution that was implemented on
a Windows-based machine with no SOAP server. The order
and acknowledgement files are stored in specific inbound and
outbound folders managed by a File Transfer Protocol (FTP)
server implemented on the same machine. To simulate orders
arriving from Amazon, a web-based order simulator program
was written in C++ to periodically drop order files into the
inbound folder. Order acknowledgment files destined for
Amazon are placed in the outbound folder. For this proof of
concept, the acknowledgment files are not actually transferred
to Amazon.
Each AIM contains four (4) major steps, each implementing
one of the four self-* attributes described in the previous
section (Fig. 4).
The “schedule successor” step implements the self-healing
behavior of the AIM by using the native task scheduler to
schedule a future instance of itself. If the AIM fails at any
point after this step (e.g., from a disk write failure,
communication failure, etc), an instance of itself will execute
and pick up where the prior instantiation left off, thereby
“healing” itself from a system fault without the need for
human intervention.
The “check concurrency” step implements the self-
protecting behavior of the AIM by checking that no other
instance of the same AIM is already executing. If another
instance is executing, the new AIM aborts itself, thereby
“protecting” itself from causing a race condition where
multiple AIMs attempt to process the same file.
The “configuration” step implements the self-configuring
behavior of the AIM by checking for any changes in the
environment upon which it should act – namely, the
appearance of a file that needs to be processed.
Fig. 4. AIM Self-* Steps
 The “optimization” step implements the self-optimizing
behavior of the AIM by comparing the number of files it
detects are waiting to be processed and adjusting the
frequency for that AIM’s execution up or down based on the
expected volume of files versus the detected volume of files
(Table 4). Because each AIM has its own set of environment
variables, the expected volume may be set to a different value
by human users of the system, and thus the frequency at which
of that AIM executes may be different than the other AIMs at
any given time.
A. Three AIMs, Three Tasks
As in the original system, three AIM components are tasked
with processing the simulated order files and their
acknowledgments. The first AIM (AIM_GET) monitors an
inbound folder and periodically transfers orders to another
processing folder using FTP. This process is analogous to the
transfer of files from the SOAP server to the stakeholder
minicomputer in the original solution.
The second AIM (AIM_PROC) periodically collects the
orders and simulates the injection to an ERP system database.
A built-in delay of one (1) minute is used to simulate the
processing time of this process in the original solution. An
order acknowledgment file is generated. Once the order is
“processed,’ the AIM moves the order file to an archive folder
both as a backup process and to prevent the order from being
picked up and reprocessed by the next iteration of the second
AIM.
The third AIM (AMC_PUT) periodically collects the
acknowledgement files and transfers them to the outbound
folder via FTP. All three AIM components self-adjust their
behavior according to the detected volume compared to the
expected volume, just as they did in the original
implementation. Each AIM operates asynchronously and
independently of one other.
Each AIM exhibits self-healing and self-protecting
behavior. To achieve these behaviors, the AIM communicates
with the native system task scheduler. For the Windows-based
system, the solution uses the Windows “Task Scheduler 1.0”
API to query the operating system for duplicate instances of
the same AIM that are either scheduled or executing.
The development effort for this simulation case study took
less than fifty (50) hours to complete. Each AIM component
and its external C++ helper programs were written in C++.
Each AIM and each helper program was implemented as an
individual project using Microsoft Visual Studio. The program
used to simulate incoming customer order traffic was also
written in C++ and implemented as a separate project in the
MSVS solution. The environment variable files were created
using Microsoft Notepad and populated with initial values to
control the AIM behavior. Each AIM had its own set of
environment files.
To test the implementation, the simulator (named
“Populator”) for the incoming order traffic was executed. It
generated order files that appeared an inbound folder on the
test machine. To produce a realistic testing scenario, the
Populator application generated order files at a volume and
frequency that mimicked a typical e-commerce order traffic
pattern. For example, order volumes tend to peak around mid-
day and again, but less significantly, during mid-evening.
These patterns were presumably from customers that shopped
online during lunch breaks at work and after dinnertime at
home. Online orders may also peak on certain days of the
week (e.g., Wednesday and Thursday) in advance of a typical
payday (Friday), or at certain times of year (e.g., two weeks
before Christmas). The order-populating application was
designed to simulate these typical e-commerce web traffic
patterns.
Fig. 5 shows the order volume that was generated by the
order-populator over a simulated period of twenty-one (21)
hours. An increase in orders is generated at typically peak
ordering times in the afternoon and evening.
Fig. 6 shows data logged from the simulation of the
AIM_GET process. It was used to test the self-optimizing step
with the orders generated by the Populator application. The
expected volume for this AIM was set to 10 orders, and the
initial execution interval was set to 3.5 minutes, with a floor
constrain of 1 minute and a ceiling constraint of 6 minutes.
The values correspond to one tenth of real time operation
values of 10 and 60 minutes, respectively. The adjustment
factor for this AIM was set to 0.25. That is, the AIM execution
interval would be increased or decreased by 25%, depending
upon the volume of orders processed compared to the volume
that was expected.
Each table entry that includes an asterisk next to the interval
value corresponds to a cycle in which the AIM adjusted its
interval in the self-optimizing step. For example, the first table
entry shows that three (3) orders were collected, which was
less than the expected volume of ten (10) orders. The self-
optimizing step reacted by increasing the interval from 3.5
minutes to 4.375 minutes (+25%) to reduce the frequency.
Fig. 5. Simulated Order Traffic

Fig. 6. Retrieving Orders
The volume remained low for the next two cycles, so the
AIM continued to increase the interval value until it hit the
ceiling value of 6 minutes, where it remained for 5 more
cycles.
Beginning with the 9th cycle, a “lunch rush” was simulated,
and the order volume began to exceed the expected volume of
10 orders. For the next several cycles, the interval was reduced
by 25% to increase the frequency at which the AIM executed.
The interval never reached the floor value of one minute,
however, and beginning with the 14th cycle, the interval began
to increase again as the order volume decreased. The rest of
the table illustrates the adjustments the AIM continued to
make as the order volume fluctuated.
B. GET_PROC
The second AIM was executed for the first time one minute
after the initial AIM_GET was launched. This AIM
(AIM_PROC) periodically polled the inbound host folder on
the simulated host machine and “processed” all files present.
This processing entailed “sleeping” for 1 minute per order
and generating an acknowledgement file for each order,
placing the result in the host outbound folder. Depending on
the expected volume value found in the environment variable
for AIM_PROC, the new frequency was observed by the
author to be adjusted up or down accordingly.
The AIM_PROC component performed four steps to
accomplish these tasks:
• Schedule Successor – Check if an instance of
AIM_PROC has been scheduled but is not yet
executing. If no instance is detected, a new one
scheduled using the Windows Task Scheduler.
• Check Concurrency – Check if an instance of
AIM_PROC is currently executing. If instance is
detected, continue on to the next step, otherwise
abort the rest of the steps of this instance.
• Configuration – Check for files in the inbound folder
of the host machine. Each file is “processed” and an
order acknowledgement file is generated and stored
in the host machine’s outbound folder. The total
number of files is counted and passed to the next
step. Each order file is archived to a separate folder
so it is not processed again.
• Optimization – Using the number of files processed
by the configuration step as a guide, adjust the
interval value for the next execution of GET_PROC
by comparing expected value versus detected
volume.
In our simulation, GET_PROC successfully launched itself
at frequencies varying between the ceiling and floor intervals
constrained by its environment variable values. No duplicate
instances were observed, and successor instances were
successfully scheduled. Connectivity failures were simulated
by temporarily shutting down the FTP server, preventing order
files from arriving from the target inbound folder.
AIM_PROC continued to poll for orders, but since none were
found, it slowed its execution frequency over several
execution cycles. After restarting the FTP server, AIM_GET
resumed collecting and transferring files from the target to
host inbound folders, and AIM_PROC detected and processed
them accordingly. It adjusted its interval appropriately by
running more frequently due to the FTP outage until the
detected volume returned to expected levels.
Fig. 7 illustrates the behavior of AIM_PROC during the
same simulation and order volume depicted in Fig. 5. For this
AIM, the expected volume was set to 15, and modified during
the 6th cycle by the author to a value of 10 to simulate a
stakeholder “tuning” the process. The starting interval value
was set to 4.5 minutes, with a floor of 3 minutes and a ceiling
of 6 minutes, with an adjustment factor of 0.12 (12%). Like
the AIM_GET simulation, AIM_PROC initially adjusted its
interval upward in respond to lower-than expected volume
until it eventually reached the ceiling value. During the 8th
cycle, order volume exceeded the expected volume and the
interval was modified accordingly. The remainder of the table
illustrates the self-optimizing behavior over the rest of the
simulation.
Fig.7. Processing Orders
C. AIM_PUT
The third AIM was executed one minute after the initial
AIM_PROC instance was launched. This AIM periodically
polled the outbound folder on the simulated host machine and
transferred all files present to the outbound folder on the
simulated target machine. Depending upon the expected
volume value for AIM_PUT (defined in an environment
variable unique to AIM_PUT), the new frequency (interval)
was adjusted up or down accordingly during the simulation.
The AIM_PUT component performed four steps to
accomplish these tasks:
• Schedule Successor – Check if an instance of
AIM_PUT has been scheduled but is not yet
executing. If no instance is detected, a new instance
is scheduled using the Windows Task Scheduler.
• Check Concurrency – Check if an instance of
AIM_PUT is currently executing. If no instance is
detected, continue on to the next step, otherwise
abort the rest of the steps of this instance.
• Configuration – Use FTP to check for files in the host
outbound folder. Using FTP, transfer each file to the
target machine’s outbound folder. The total number
of files is counted and passed to the next step. Each
acknowledgement file is archived to a different folder
to prevent it from being processed again.
• Optimization – Using the number of files processed
by the configuration step as a guide, adjust the
interval value for the next execution of GET_PUT by
comparing expected value versus detected volume.
In our simulation, GET_PUT launched itself at frequencies
varying between the ceiling and floor intervals constrained by
its environment variable values. No duplicate instances were
observed, and successor instances were successfully
scheduled. Connectivity failures were simulated by
temporarily shutting down the FTP server. AIM_PUT
continued to poll for acknowledgement files, but since
connectivity failed, it gradually slowed its execution
frequency. After restarting the FTP server, AIM_PUT
resumed the collection and transfer of files from the host to
target outbound folders once AIM_GET and AIM_PROC
began populating the host folders. It adjusted its interval
appropriately by running more frequently due to the FTP
outage and subsequent “piling up” of files, until the volume
fell below the expected level.
Fig. 8 illustrates a sample of the behavior of AIM_PUT
during the same simulation and order volume depicted in Figs.
6 and 7. For this AIM, the expected volume was set to 5
orders. This threshold was chosen to simulate a stakeholder
desire to update Amazon with order acknowledgements at a
higher frequency than the order collection and order
processing steps. The starting interval value was set to an
arbitrary 2.76 minutes, with a floor of one minute and a
ceiling of 6 minutes, and an adjustment factor of 0.25 (25%).
Like the other AIMs in the simulation, AIM_PUT initially
adjusted its interval upward in response to lower-than
expected volume until it eventually reached the ceiling value.
Since the expected volume threshold was set so low, this AIM
adjusted its interval nearly every cycle during the simulation.
III. CONCLUSION
The case study described in this paper was designed to
validate the repeatable platform-agnostic approach first used
in [11] to collect and process web-based customer orders from
a third-party system. The validation tested by reengineering
the original autonomic components (AIMs) to operate in a
new environment with a different operating system and task
manager and using different programming languages and data
communication protocol than the original implementation.
The goal was to demonstrate how the approach could be
successfully used to develop autonomic interaction managers
that can be deployed to new platforms while retaining the
original behavior and without requiring the reengineering of
other components of the legacy system in which they
operated. While the components steps of each AIM were
reengineered, the overall architecture was not, nor were the
self-* autonomic attributes that resulted from that architecture.
The development effort took less than fifty hours and the
testing effort took a single day, validating the efficacy of the
approach. The resulting solution was structured the same way
as the original solution and behaved similarly. Testing proved
that the solution could run autonomously, exhibiting the
desired autonomic attributes of self-configuring, self-healing,
self-optimizing, and self-protecting. To show that human
operators can influence the solution’s behavior at run-time, the
author periodically adjusted environment variables over the
course of the testing process. The adjustments did not disrupt
the solution. The effort demonstrates the efficacy of the design
approach introduced in prior works by the authors.
In future work, the authors intend to expand the scope of the
several aspects of the case study: the self-configuration and
self-optimizing steps will use more sophisticated algorithms to
automatically set and alter the expected volume thresholds
based on historical order traffic. The self-protecting and self-
healing steps will adjust execution frequency of the AIMs to
avoid duplicate instances by monitoring the time it takes to
process a typical order and to transmit a typical file.
Fig. 8. Processing Order Acknowledgements
 REFERENCES
[1] H. Klaus, M. Rosemann, and G. Gable, “What is ERP?,” Information
Systems Frontiers, vol. 2, no. 2, pp. 141-162. 2000.
[2] Gartner, “Gartner says by 2016, the impact of cloud and emergence of
postmodern ERP will relegate highly customized ERP systems to legacy
status.” Available at http://www.gartner.com/newsroom/id/2658415.
Last accessed 21 November 2014.
[3] Y. Brun, G. Serugendo, C. Gacek, and H. Geise, “Engineering self-
adaptive systems through feedback loops,” Software Engineering for
Self-Adaptive Systems, Springer Berlin Heidelberg, 2009 , pp.48-70.
[4] M. Lehman, “On Understanding Laws, Evolution, and Conservation in
the Large-Program Life Cycle," Journal of Systems and Software, vol. 1,
pp. 213–221.
[5] S. Dehaghani, N. Hajrahimi, “Which Factors Affect Software Projects
Maintenance Cost More,” Acta Informatica Medica, vol. 21, no. 1, pp.
63–66. 2013.
[6] R. Seacord, D. Plakosh, and G. Lewis, “Modernizing Legacy Systems:
Software Technologies, Engineering Processes, and Business Practices,”
Addison-Wesley Professional, 2003.
[7] F. Zoufaly, “Issues and challenges facing legacy systems,”
Developer.com, 2002.
[8] J. Kephart, “An architectural blueprint for autonomic computing,” IEEE
Internet Computing, vol. 18, no. 21. 2007.
[9] M. Salehie and L. Tahvildari, “Self-adaptive software: Landscape and
Research Challenges,” ACM Transactions on Autonomous and Adaptive
Systems, vol. 4, no. 2, art. 14. 2009.
[10] J. Mulcahy, S. Huang, and A. Veghte, “Leveraging Service-oriented
Architecture to Extend a Legacy Commerce System,” Systems
Conference, 2010 4th Annual IEEE, pp. 243-248. 2010.
[11] J. Mulcahy and S. Huang, “Autonomic Software Systems: Developing
for Self-Managing Legacy Systems," Software Maintenance and
Evolution, 2014 30th International Conference on: Victoria, pp. 549-
552. 2014.
[12] J. Mulcahy and A. Huang, "An autonomic approach to extend the
business value of a legacy order fulfillment system," Systems
Conference, 2015 9th Annual IEEE International (SysCon): Vancouver,
pp. 595-600. 2015.