SIMTech technical reports Volume 6 Number 2 Jul-Sep 2005

Manufacturing legacy system modernisation

L. L. Aw, K. M. Goh and K. Yi

Abstract – Information systems are important assets
in any organisations. They support the daily opera-
tions of the organisations. Through the years, for
deployed information systems to stay viable, they
need to be replaced, rewritten or modernised to fulfil
new requirements. These information systems are
referred as legacy systems. Legacy systems refer to
mission critical software systems still in operation,
but difficult to modify when the organisation has new
requirements. Many companies are facing problems
on how to handle these legacy information systems.
The objective of this report is to discuss and evaluate
the possibility of either upgrading or integrating the
legacy system for new requirements. The different
types of modernisation are introduced. This report
details the steps to develop a modernised system. A
case study is presented to demonstrate how to mod-
ernise a warehouse control system. It allows readers to
understand aforesaid issues and possible solutions to
solve the modernisation problems.
Keywords: Legacy systems, Integration, Modernisa-
tion
1 BACKGROUND
In organisations, there are running systems de-
veloped based on older technologies and hardware
and these systems are referred as legacy systems.
Another definition of legacy systems refers to “any
existing system, regardless of how long ago it had
been built, that is still functioning and plays an im-
portant role in the organisation but it has the problem
of modification when organisation requires new re-
quirements. The legacy system is more than the
software that runs the system because it contains
knowledge of the organisations” [2-4]. These systems
continue to provide core services to organisations,
handling the organisations’ daily operations. The
problem is these systems are difficult to modify, scrap
or replace. The organisations are heavily dependent
on the systems. The systems contain the knowledge of
from the legacy system. Organisations have to face
the problem of what and how to accommodate the
new business requirements on the legacy systems. To
rewrite with another modern language or replace the
legacy application with another newer application is
costly and there is a high risk of failure, as the appli-
cation takes some time to complete and this may
become a legacy system too. To replace the legacy
system with modern, packaged software and hardware
is possible but it is difficult to identify a suitable
package. Most of the time, customisation is required
and risks are also present. New technologies have
evolved very rapidly and most of the old technologies
are difficult to interface with the new technologies.
Therefore, there is a need to decide what to do with
the legacy systems and methodologies to modernise
the legacy systems for new business requirements.
2 OBJECTIVE
The objectives are to show some ways of mod-
ernising an existing system to incorporate new re-
quirements. This includes analysing the legacy system,
searching the current technologies and the available
software on handling the legacy system. This report
aims to highlight problems, considerations, method-
ologies and approaches in modernising a legacy sys-
tem.
3 METHODOLOGY
3.1 Phases to Modernise a System
Figure 1 shows the different phases that are re-
quired to modernise an existing system. The phases
involved are the Initial Phase, Analysis Phase, Soft-
ware Development Life Cycle Phase and the Software
Tools Selection Phase.
3. Software
1. Analysis Phase
2. Software Tools
Selection Phase
Development Life
Cycle Phase
- Identify list of problems and
Constraints
- Select type of programming - Understand user
requirement
languages and database.
- Gather information
- As-Is Diagram
- Select the software products
required.
- Follow and deliver the
software using the software

the organisations accumulated throughout the years. - To-Be Diagram

- Conduct feasibility test
development lifecycle
- Choose the modernization
methodologies
Examples of legacy systems can be any applications
- Understand the existing
applications - Select software architecture
- Use the UML diagrams for
running on mainframes, old computers, DOS-based, understanding and
communicating with

10-based T networks, proprietary network, old type of customer

PLC and many others.

As time goes by, new business requirements are
required from the legacy systems. The legacy system Fig. 1. The different phases to modernise an existing sys-
may not be able to handle the new requirements. For tem.
example, a new system requires to access information

63
L. L. Aw, K. M. Goh and K. Yi
To modernise an existing system, the phases in-
volved are the Analysis Phase, Software Tools Selec-
tion Phase and Software Development Life Cycle
Phase. The Analysis phase, which is the most impor-
tant, is to analyse the existing system. During the
analysis, a list of problems and constraints, its envi-
ronment and all factors pertaining to the system are
noted. In some cases, the existing system is connected
to other systems. In this phase, the possible solutions
are discussed and explored.
In the Software Tools Selection Phase, software
tools are evaluated and selected. The products for
implementing the possible solutions are evaluated.
The last phase is to design and implement using a
software development life cycle. This phase is similar
to implementing new software applications. Different
types of software modelling tools are used.
4 CASE STUDY
4.1 Warehouse Control System
Company ABC manufactures goods. Once goods
are manufactured, it is transferred to the warehouse.
Goods in the warehouse are spare parts,
sub-assembled parts, completed products.
The warehouse is a building that covers 100 m x
100 m x 100 m. It has different types of storage areas
such as areas for perishable goods and areas for
cold-storage goods. Different vehicles are used in the
warehouse for different goods and operations.
Goods location information is retrieved and
shown using terminals located at different locations of
the warehouse.
Company ABC requirements are given as fol-
lows:
• Automatic goods entry information – when
goods arrived at the warehouse, goods in-
formation is automatically recorded.
• Goods information transfer – to allow goods
information from the new warehouse to be
automatically transferred to the existing
system.
• Ad-hoc goods information retrieval – any
users is able to request goods information at
any time at any terminals of the warehouse.
• Data Population – to collect the goods in-
formation from the existing warehouse in-
formation system.
4.2 Analysis Phase
The list of problems and constraints of the
Warehouse Control System (WCS) is shown in the
following:
• For the source code documentation, it may
not be the same revised version as the source
code running in the system.
• Throughout the years, the different operating
systems are upgraded.
• The warehouse control system is written to a
64
limitation of certain concurrent users.
• The real-time data from the programmable
logic controllers (PLC) and updated to the
WCS files. How frequent or how it is stored
is unknown.
• The WCS is running on 24 hours non-stop.
• There is the legal issue of changing the
source code.
Besides identifying the problems and constraints,
the existing network architecture of the existing sys-
tem has to be understood.
The WCS is based on a VAX system and is
connected to it are two serial terminals servers. Green
screen text terminals are connected to the serial ter-
minal servers. A few green screen text terminals are
mounted on moving vehicles. The speed of the net-
work is 10 Mbps.
The network connection from the VAX system to
the text terminals uses Ethernet. A bridge is used to
connect the PLC and conveyors to the VAX. The
network protocol is Ethway. The network connec-
tivity from the text terminal in the mobile vehicle to
VAX is by way of microwave guides.
After having some understanding of the problems
and issues, the team identified that one of the possible
solutions is to use TCP/IP to communicate with the
VAX system. The current VAX system does not have
the TCP/IP protocol installed. The team requested the
customer to install TCP/IP on the VAX system.
The team was also informed that there is a limi-
tation on the number of processes for the WCS system.
No one is sure about the exact number of processes
that the WCS can handle. It is known that when the
maximum number of processes was running, the
whole application would crash. Therefore, tests are
performed to generate the maximum number of proc-
esses on the existing inventory system. The amount of
hard disk storage, the speed of the network, any
problems if additional access to the existing ap-
plication is allowed are recorded and noted.
Once TCP/IP was installed on the server, tests are
conducted to ensure it is working properly. Besides
performing different types of tests, the type of net-
work connector required by the VAX system is iden-
tified and purchased.
Tests are also conducted from the personal com-
puter for the connectivity to the WCS. With the tests
conducted, the team concludes that connectivity to the
server application was accomplished. For the
connectivity of mobile vehicles to the VAX, wireless
connectivity was explored.
During the different tests, the customer has to be
actively involved because the team is not familiar
with the existing system. Permission had to be granted
to allow access to the existing system. Any interrup-
tions on the existing systems during testing are
quickly solved and interruptions to the existing sys-
tem are kept as minimal as possible.
The team members also explored the different
types of possible modernisation methodologies. The

strengths and weaknesses of the different modernisa-
tion techniques are noted. After knowing the possible
modernisation methods, the team chose the presenta-
tion and the data modernisations.
4.3 Software Tools Selection Phase
In the next phase, software tools are evaluated
and selected. Software tools for the presentation
modernisations include the screen scraping software.
There are many different types of screen scraping
software available, the Reflection from WRQ was
selected. Initial tests are conducted on the WCS and
they were successful. Other software includes data-
base, development tools for the developed applica-
tions.
4.3.1 Software Development Life Cycle Phase
The Software Development Life Cycle Phase in-
cludes Project Planning, System Analysis, System
Design, Implementation, Integration and Test.
Diagrams and documents are written for this
phase. Many discussions with the customer are con-
ducted. In-house discussions are also carried out so
that team members have up-to-date information.
4.4 Related Topics
4.4.1 Modernisation Methods
In the data presentation methods, the database
gateway is described. A database gateway is a specific
type of software that translates between two or more
data access protocols. It is required because there is a
need to access data in databases using one version of a
piece of software for each different type of database.
There are many vendor-specific protocols that are
used to access databases, but few are of a de-facto
industry standards.
Open Database Connectivity (ODBC) is Micro-
soft’s interface for accessing data in a heterogeneous
environment of relational and non-relational database
management systems [1].
The application calls the ODBC API functions by
using a standard ODBC Structured Query Language
(SQL) syntax, and the ODBC driver makes the nec-
essary translations to send the statement to the data-
base management system (DBMS) and presents the
results back to the application.
The database gateway is free of charge as it
comes together with the product or it may be
downloaded from the Internet. Many tools have in-
cluded this in their package. It is easily understood
and easily implemented. This is a matured commu-
nication method and most of the current applications
used it. The weakness is that nothing is being done on
the legacy system, so the maintainability of the legacy
system still exists.
One of the presentation methods is screen
scraping. This technique accesses existing applica-
tions through their user-interfaces. User keystrokes
are simulated to implement the interaction with the
65
Manufacturing legacy system modernisation
legacy software. Screen scraping consists of wrapping
old, text-based interfaces with new graphical inter-
faces. The old interface is often a set of text screens
running in a terminal. The new graphical interface can
be a personal computer (PC) based, graphical user
interface (GUI), or even a hypertext markup language
(HTML) light client running in a Web browser. With
screen scraping, the legacy application can be ex-
tended easily, enabling one new User Interface (UI) to
wrap a number of legacy systems.
Screen scraping is usually based on proprietary
middleware, which intercepts the front end of the
legacy system and generates a GUI on top without
touching the core modules of the legacy applications
[2]. From the perspective of the legacy system, the
new graphical interface is indistinguishable from an
end user entering text in a screen. From the end user’s
point of view, the modernisation now provides a
modern, usable graphical interface.
This modernisation method is a matured, low cost
and common approach. The weakness is that this
approach can be slow because an application needs to
wait for the legacy application to render the required
screen. In addition, any change on the legacy appli-
cation user interface necessitates change to the mod-
ernisation code. Besides maintenance for the existing
system, the newly developed application needs
maintenance too. Therefore, this method adds more
maintenance to the existing system. The current
hardware is not necessary to be replaced. To mod-
ernise the system with any new or other systems,
additional hardware and software are required.
The developer needs to know and navigate to the
required screens and text on screens. This is done
using a software product. The developer is able to
develop and get information without changing code.
Screen scraping has proved to be useful for simple
task automation.
4.4.2 Reasons for Choosing the Methods
The following are the reasons to modernise the
WCS using the data and presentation methodology.
The business logic of the application and the same
user interface are retained. With a similar user inter-
face, there is no need to conduct any major training
for the end-users. A rewrite is the most costly and
time-consuming option, and it might pose the highest
project failure risk. Both database gateway and screen
scraping methodologies are able to fulfil the re-
quirements. Company ABC is able to continue to use
the 3,270 terminals and printers throughout the tran-
sition process. This extends the investment of the
legacy system and allows for a smoother, less drastic
transition. The company does not require expensive
upgrades or re-engineering of its existing inventory
system. Since users are familiar with the user inter-
faces, there will be no change done on the graphical
user interface.
L. L. Aw, K. M. Goh and K. Yi
4.4.3 Using the Two-tier Client/server Archi-
tecture
In the implementation, a two-tier client/server
architecture is used. Generally, the client handles the
presentation and some of the processing logic. Its
application transmits a request to the server. The
server handles the other portion of the processing
logic, provides the data that the clients require and
also store data on the server. The database manage-
ment server usually provides the portion of the proc-
essing related to accessing data. Clients commonly
communicate with the server through SQL statements
or a call-level interface.
The advantage of using a two-tier client/sever
system is that it works well in a homogeneous
environment and it is fast to develop using proprietary
rapid application development (RAD) tools. It meets
the demand of faster development time at the expense
of flexibility.
The disadvantage is that it is more difficult to
administer and maintain because when applications
reside on the client, every latest release must be de-
livered, installed, and tested on each client.
4.4.4 New Network Connectivity
New network architecture has to be included to
pass information from the new warehouse system to
the WCS. For the vehicle PCs which are currently
using microwave guide, the network communication
link is by wireless communication. Tests were con-
ducted to locate the best possible location for the
access points such that the connectivity link is always
present.
The dumb terminals are replaced by workstations
that are loaded with the Windows NT operating sys-
tem, the screen scraping software and the database
client and other necessary software. The other rele-
vant software includes some protection to prevent
users from meddling with the workstation.
The team also searched for products to convert
serial to Ethernet converters so that the newly built
applications are connected to the terminal server
through the Ethernet and the existing serial line to the
terminal server still remains. The serial line is still
required to run the existing applications.
5 RESULTS & DISCUSSION
Initially, the problem seems difficult to handle
and the confidence level is not high. There are the
network connectivity problems of how the new net-
work can interface to the WCS, the connectivity from
the mobile vehicle to the Ethernet, the limitations of
the number if concurrent users problem, the limita-
tions of the hardware ports problem, the limitations of
the hardware searching for the serial to Ethernet
converter and testing it. The limitations of the
maximum number of processes problem, if processes
exceed the maximum, the whole warehouse control
system goes down. After conducting different tests
66
and after identifying the types of modernisation to be
used, the team is confident of delivering the solutions.
By using the screen scraping and the data mod-
ernisation methodology, the team is able to leverage
on the same legacy code that the company has been
depending on for years.
Some of the issues in using the screen scraping
methodology are:
• During the implementation and testing, there
are many timing issues when using the
screen-scraping methodology. New re-
sponses of the WCS were also captured and
implemented in the new application. This
had to be done so that the new application is
able to respond appropriately.
• The screen behaviours of the WCS must be
examined thoroughly. For example, there
was an auto log-out feature that will show
the login screen after a time lapse. It was
only after live testing that this symptom is
realised.
• Improper logoff of the WCS could cause the
maximum processes to be exceeded. This is
the most difficult task, as ways of proper
logoff must be ensured. The customer is ad-
vised to check on the number of processes at
a frequent interval. The number of processes
is monitored during the testing and imple-
mentation stage.
• Distorted screens – The screen scraping
software is highly dependent on the screens;
if the original screens are corrupted, incor-
rect data may be obtained. This is overcome
by refreshing the screen; that is, sending the
command to refresh the screen. After a time
delay, a check has to be made to see if the
correct screen is displayed. Though the
screen scraping method had been in the
matured state, it is still widely used because
this may be the only way to access the legacy
system.
• Another issue is the availability old hardware.
The spare components for the old hardware
may not be easily available. In the case study,
the required network adaptor is not widely
available, therefore time is wasted in getting
the adaptor and it is not as cheap as a normal
network connector.
In modernising an existing system, all known
assumptions must be tested and ample time is to be
allocated for analysing the existing application. Every
organisation is different, and the range of existing
legacy systems provides a multitude of challenges.
The modernisation effort requires careful selection of
an integration model for a different legacy system.
There are cases where system or unpredictable
errors occur during the final stages of implementation.
Problems or considerations when integrating the new
system with the legacy system must be highlighted to
the customer. Ways, methods and a systematic ap-

proach for integrating the legacy system must be
discussed with the customer for a better success rate.
The success of the project is also highly de-
pendent on the coordination and the relationships
between the customer, users, contractors and the team.
All parties involved in the project have been very
cooperative.
6 CONCLUSION
This report highlights problems, considerations,
methodologies and approaches in modernising legacy
systems. The given case study had shown that with the
right approach and chosen modernisation methods, it
is able to modernise the legacy system. Though the
requirements of the case study are fulfilled, there is an
increase in the maintainability of the legacy system.
The methodologies and approaches can also be
applied to other types of legacy systems such as
Manufacturing Execution System (MES) or Material
Resource Planning System (MRP).
7 INDUSTRIAL SIGNIFICANCE
The team had been uniquely able to analyse the
legacy system and solve problems without intruding
into the system. For anyone who intends to integrate
their legacy systems, they must understand that every
organisation and their range of existing legacy sys-
tems are different. A phased or modular approach is
used to ease the introduction of new concepts and
methods.
67
Manufacturing legacy system modernisation
The technical paper is able to identify, raise some
issues for the industry to understand and gauge the
problems of integrating with legacy systems. The
company is able to engage SIMTech to advise on
analysing their legacy systems or other similar types
of problems.
This report had demonstrated that modernising
legacy systems by using the proposed phases is fea-
sible. It is hoped that these findings and implementa-
tion add to the understanding of how best to modern-
ise existing applications and how people facing simi-
lar problems can use this as a guide.
REFERENCES
[1] S. Comella-Dorda, K. Wallnau, R. Seacord and J.
Robert, “Survey of legacy system modernisation ap-
proaches”, CMU/SEI-2000-TN-003, April 2000,
http://www.sei.cmu.edu/publications/documents/00.re
ports/00tn003.html
[2] K. H. Bennet, “Legacy systems: Coping with success,
software”, IEEE Software Magazine, vol. 12(1), pp.
19-23, 1995.
[3] M. Brodie and M. Stonebraker, Migrating legacy
systems, Morgan Kaufmann Publishers, 1995.
[4] B. Wilson, “The economic realities of software mi-
gration”, Anubex, 2004, at:
www.anubex.com/ereality.asp