Data Oriented and Process Oriented Strategies For Legacy Information Systems Reengineering
Data Oriented and Process Oriented Strategies For Legacy Information Systems Reengineering
net/publication/260286757
Data oriented and Process oriented Strategies for Legacy Information Systems
Reengineering
CITATIONS READS
9 21,915
2 authors, including:
Raul Valverde
Concordia University Montreal
128 PUBLICATIONS 804 CITATIONS
SEE PROFILE
All content following this page was uploaded by Raul Valverde on 22 February 2014.
Abstract–The legacy information systems often implement are often remodelled during system architecture phase based
manual data updates for information obtained from external on the software development methodology chosen. This
systems. The manual updates are cumbersome, error prone, paper focuses on traditional data and process models and
and expensive. The legacy systems miss interfaces to external
attempts to propose few reengineering strategies.
systems that could be used for automatic updates of system
data. Moreover, the legacy systems also lack extensions to
The traditional data oriented reengineering focuses on
supplier or customer systems that are essential for creating migrating databases of legacy systems to current relational
supply chain relationships. This paper explores the data databases, enterprise data standardization, integration of
oriented and process oriented models of legacy systems, and disparate information systems, etc. [3]. The data oriented
discusses the details of systems development and evolution reengineering can also be conducted by focusing on
models mainly aiming at an ongoing reengineering of legacy improving data objects one by one in a pragmatic manner as
systems. This paper proposes simple strategies for creating presented in this paper. This approach eliminates the
interfaces to external systems for automatic updates of data, possibility of system failures, and minimizes the impact on
and for adapting to the process evolution that requires a legacy
overall system while reengineering the system. The process
information system to extend its communications with
oriented reengineering considers each work activity and
external systems that could help in creating successful supply
chain relationships. These strategies can reshape a legacy remodels a relevant part of the legacy system. The effort
system to be reengineered into a new enterprise information could be as simple as extending the legacy information system
system whether the legacy system is of a data oriented model, to an external process.
or of a process oriented model.
II. TRADITIONAL DATA MODEL REENGINEERING
Key words–Legacy system, Data oriented model, Process
oriented model, System reengineering, Data structure. The traditional software development methodologies
include data models for organizing data and its documentation
I. INTRODUCTION [4]. Data modeling is also called as database modeling
because a data model is often implemented as a database [2],
A legacy system is an application that uses an obsolete as depicted in Entity Relationship Diagram (ERD) that
hardware platform or software which is hard and expensive presents the data in terms of the entities and their
to maintain. Due to the fact that a legacy system is old, it is relationships. An entity is an instance of a class of persons,
hard to find the skill set for maintaining the software or places, events, objects, or concepts about which data is
replacing hardware parts if a hardware failure occurs. Recent captured and stored. An entity is a single occurrence. An
trend is the shortening life period of software systems and to attribute is a descriptive characteristic of an entity. A
quickly adapt to the new developments in software compound attribute could include multiple attributes, in other
engineering; otherwise the systems become outdated very words, a group of attributes or a data structure. A relationship
soon and become legacy systems. The huge investment in a is a natural association that exists between two or more
legacy systems often compel reengineering and reuse of entities. The relationship may represent an event for linking
system components for evolution, maintenance and newer the entities. Cardinality defines a minimum and a maximum
hardware platforms. Therefore, legacy systems range from number of occurrences of an entity that may be related to a
traditional software systems to recent component-based single occurrence of the other entity. Since all relationships
systems. The modeling techniques that were used during among entities are bi-directional, cardinality must be defined
legacy systems development also serve as building blocks in both directions for a relationship. Every entity must have
during reengineering phase. This paper presents both a key which is an attribute, or a group of attributes, which
traditional data and process oriented modeling techniques assumes a unique value for each entity instance. It is
and proposes reengineering approaches that would prolong sometimes called an identifier. A primary key is the candidate
the life span of a legacy system. key that uniquely identifies an entity instance. A foreign
The systems documentation often includes models that key is the primary key of another entity that is duplicated in
describe the requirements collected during initial system the entity for the purpose of identifying the relationship.
analysis phase of software development process [1]. These
requirements models simplify the system complexity and help
software maintenance process [2]. The requirement models
© 2012 ACEEE 47
DOI: 01.IJIT.02.01. 532
ACEEE Int. J. on Information Technology, Vol. 02, No. 01, March 2012
defines a person, an organization unit, or a system internal or the same legacy software systems are in-use although an
external to organization that lies outside the software system organization radically changed or reorganized its processes.
scope, but interacts with the system being studied [4]. An organization employs different ways of adapting to
External agents provide inputs into the system, and receive process changes, often conducting appropriate data entry
outputs from the system [2]. A data store is an inventory of in to and out of a legacy system to continue using it. This
data which is frequently implemented as a file or database additional data entry is cumbersome and expensive; instead,
[4]. It is data at rest compared to a data flow which is data in it is profitable to gradually reengineer the legacy system.
motion. Data stores depicted on a DFD store all instances of A methodology for reengineering is presented in [5]
data entities depicted on an ERD. A data flow represents an focusing on business process, as follows:
input of data to a process, or the output of data from a process. Prepare for reengineering,
It may also be used to represent the creation, reading, deletion, Map and analyze As-Is process,
or updating of data in a file or database. A control flow Design To-Be process
represents a condition or non-data event that triggers a Implement reengineered process, and
process. The following strategy for process modeling is Improve continuously.
proposed in [4]: While planning a legacy system reengineering, one should
1. Draw a context DFD to establish initial system scope. target process improvements such as (a) work balancing, (b)
A context diagram defines the scope and boundary for the work-flow redesign, (c) eliminating non-value-added
system. Because the scope of a software system frequently activities, and (d) revising administrative controls [6]. A
changes during the requirements and design phases of process can be viewed as a set of sub-processes with
software development, the context diagram may also change performance criteria as follows:
to reflect upon the same. Distributed processing for faster response,
2. Draw a functional decomposition diagram to partition the Data redundancy across processes,
system into subsystems. A decomposition diagram shows Increased automation to integrate and minimize manual
the top-down functional decomposition or structure of a processes,
system. It provides an outline for arriving at data flow Simplifying cross functional processes,
diagrams. Eliminating redundant sub-processes,
3. Create an event-response or use-case list for the system in New process creation and integration,
order to determine what business events the system must Integrating current enterprise applications, e.g. Supply
respond to, and what responses are appropriate. Some of the Chain Management (SCM), Customer Relationship
inputs on the context diagram are associated with events. Management (CRM), Enterprise Resources Planning (ERP),
4. Draw an event DFD or event handler for each event. For etc.
each event, illustrate any data stores from which records As discussed earlier, if the reengineering is carried out in
must be ‘read’ should be added to the event diagram. Data a pragmatic manner focussing one feature at a time,
flows should be added to reflect upon the data read. Any reengineering will be successful. Here, we propose an
data stores in which records must be created, deleted, or approach for reengineering that focuses on integrating a new
updated should be included in the event diagram. Data flows process, e.g. supplier process via web interface as presented
to the data stores should be named to reflect upon the nature in figure 4. It is possible to reengineer few parts of a legacy
of the update. system by providing user interfaces to integrate new
6.Merge event DFDs into a system diagram. The system processes; for example, automatic inventory replenishment
diagram is said to be exploded from the single process on can be achieved by extending the system to integrate a
context diagram. The system diagram shows either: all of the supplier process as follows in Figure 4.
events for the system on a single diagram, or all of the events This approach in figure 4 integrates the external supplier
for a single subsystem on a single diagram. processes and eliminates the order transaction processing
7. Draw detailed and primitive DFDs for the more complex delays. The legacy system can use the current business rule
event handlers. Each event process on the system diagram(s) set and automatically generate new orders while respecting
must be exploded into either a procedural description or a the lead time to suppliers.
primitive data flow diagram. For event processes that are not
very complex – in other words, they are both an event and an
elementary process, they should be described. The data flow
diagrams show all the elementary process, data stores and
data flows for single events
8. Document the logic of each elementary process using
structured English.
9. Document data flows and processes in the data dictionary.
Reengineering techniques for Process models
Usually systems are not reengineered often, as a result, Figure 4. Legacy systems reengineering to integrate external
supplier process
© 2012 ACEEE 49
DOI: 01.IJIT.02.01.532
ACEEE Int. J. on Information Technology, Vol. 02, No. 01, March 2012
CONCLUSIONS
In this paper, the traditional data and process modelling
of legacy information systems and reengineering approaches
were presented. The reengineering approach focused on
systems evolution to benefit from in-house experience of
systems team, able to maintain and evolve the software
system. A fully reengineered system reflects upon the current
Figure 5. Data oriented vision versus Process oriented vision of a business model and the feature set required sustaining the
Legacy system business in a medium term. It is argued that the traditional
methodologies are not comprehensive enough to accurately
model systems, then the only way to meet business
requirements in an enterprise setting is to create several
models in detail across the width and depth of the business.
The paper recommends a gradual reengineering of system
rather than a radical one shot, big budget, and expensive
reengineering that can fail. The paper recommends a
reengineering of both data model and process model in order
to reorganizing the data and process models in a pragmatic
way. The paper presented the approaches for reengineering
with examples. The reengineering approaches proposed in
Figure 6. Co-existing original and reengineered data models of a this paper prolong the legacy information system lifespan in
Legacy system a cost effective manner.
Both original data model and reengineered data model to
coexist, the “ifdef … endif, and ifndef ….. endif” pre-processor
statements can be used during reengineered software
development stage.
© 2012 ACEEE 50
DOI: 01.IJIT.02.01.532
ACEEE Int. J. on Information Technology, Vol. 02, No. 01, March 2012
© 2012 ACEEE 51
DOI: 01.IJIT.02.01. 532
View publication stats