| Complete Reengineering Methodology
Sujit Patange, Prachi Kulkarni,
Sameer Sawale
IT Elite Systems Pvt. Ltd.
What is reengineering?
Reengineering is rewriting or restructuring of an
existing system with some advanced technologies. In
other words, reengineering is a significant modification
and evolution of the existing system to meet the changing
business requirements. Reengineering includes reimplementation
of existing system with new or expanded capabilities.
A realistic approach can start by analyzing legacy systems
to understand the current architecture and developing
a strategy for mining and reusing existing assets. Mining
involves rehabilitating parts of an old system for use
in a new system.
Why reengineer an existing system?
Initially very few organizations had realized the
importance of using software products. Such organizations
had developed in-house software, according to their
requirement. Gradually as software awareness was spread,
software products were readily available and people
started thinking of integrating and customizing these
software products according to their current business
needs and that is where 'Reengineering' concept came
into picture. Using reengineered software products became
more generic when managers in the organizations realized
the Y2K problem.
Maintaining legacy systems was a complicated job and
a costly affair too.
The core programs where worked upon frequently and
so had too may patches, which made it difficult to maintain.
Resource availability for maintenance went on reducing
day by day and to overcome this, a trend of migrating
from legacy systems to advance technologies started.
The organizations were highly benefited by this as the
maintenance cost was reduced and advance technologies
provided many new features, which helped them in exploring
their business.
From mergers and acquisitions leading to consolidations,
legacy systems do not provide a way to integrate with
a variety of external systems. Lack of support for current
integration standards such as XML made the task difficult.
Reengineering was as an affordable solution for all
such problems.
This paper describes
- Types of
reengineering projects.
- Issues to
be handled while reengineering a project.
- Phases to
develop a reengineering project.
- Automated
Tools.
- Benefits of
Reengineering.
Types of reengineering
projects (top)
Types of reengineering depend on
the type of enhancement that the system requires. Reengineering
projects are classified as follows
- Refacing
- Restructuring
- Redevelopment
- Replacement
Refacing
(top)
Refacing refers to giving a new front-end but keeping
the important back-end unchanged. Legacy systems were
software targeted to restricted users. Interfacing with
these systems was difficult for other user. So if the
targeted users are to be increased, making the software
user friendly is a necessity. Refacing is a solution
for this. It states that the "green screen" should be
converted to a GUI, keeping the functionality of the
system unchanged. This technique can have minimal costs
and low downtime but some problems associated with legacy
system remain unsolved.
Languages used for developing Legacy systems did not
support good user-friendly interfaces. Many times user
has to remember commands, which was a very tedious task.
To overcome this, 'Refacing' is one of the solutions.
Web enabling is a technique often used for such kind
of reengineering projects. By this technique you are
widening the user community and at the same time making
it user friendly.
Restructuring
(top)
In legacy systems, the presentation layer, business
layer, application layer and the database access are
bound together. All layers being tightly coupled, changes
made in one of the layer would affect the other layer.
So maintaining the software was a tricky and complex
job. The need for maintenance could be change in the
business rules or it could be technology changes brought
in the software fields.
An alternative for this is 'Restructuring' these tightly
bound layers into separate modules. This facilitates
changing one layer without affecting the functionality
of rest of the layers. For example, if one of the business
rules changes, then developer can concentrate only on
the business layer. An advantage of doing so is each
module is isolated and so can be safely used by some
other application if required. All these modules are
then integrated to form a single system.
Redevelopment
(top)
Redevelopment is a technique used when the business
processes are drastically changed and it is unviable
to upgrade the existing system to meet the current business
needs. Redevelopment leads to implementation of a new
system, which provides the basic functionality, which
was provided by the existing system along with some
added features, which cater to the current business
needs. It also offers proper documentation and reduces
the cost of maintenance.
This process is time consuming and expensive. In redevelopment
all activities like requirement gathering, designing,
coding, testing, user acceptance and implementation
are followed. The requirements are gathered partly by
studying the existing system. Downtime is required for
data migration from existing system to new system.
Replacing
(top)
The legacy system is 'replaced' by some off-the-shelf
product is the option suggested in 'Replacing'. Replacing
option is preferred if an off-the-shelf product meets
80% of the current business requirements. The off-the-shelf
product should provide solutions at least to all important
business processes carried out in the organization.
Implementing such systems may also require some changes
in the business processes.
Issues to be
handled while reengineering a project (top)
Some of the issues of reengineering touch to technical
consideration and some to functional considerations.
Technical considerations
| Tools Used |
|
Control -flow
restructuring
Configuring
Business rules
Conforming to
coding standards
Improving source
code readability
Renaming
program items
Language translation
|
Code re-structuring
Re-code is a change to implementation characteristics.
It happens at two different levels. One is at source
code level, which includes control-flow restructuring,
Configuring Business rules, conforming to coding standards,
improving source code readability, renaming program
items, etc. Second is at implementation level like Language
translation.
Control flow restructuring
Control flow is decided using some conditional statements
like if-statement, while-statement.
If BOOLEAN expressions is tested in control structures.
The entire BOOLEAN expression is considered one true-or-false
predicate regardless of whether it contains logical-and
or logical-or operators. For example, consider the following
C/C++/Java/PL-SQL code fragment:
if ((condition2 || function1())&& condition1)
statement1;
else
statement2;
This may lead poor performance as even if condition1
is false it is going to call function1() which is of
no use in this condition. We can make it efficient by
changing condition as
if (condition1 && (condition2 || function1()))
statement1;
else
statement2;
Configuring Business rules
In many legacy systems Business rules were hard coded
in the code. Hard coding in the old source code imposes
restrictions on functionality. To add on some new functionality
of the same kind one need to make changes in code, compile
the code. These needs to be followed by testing to make
sure changes made do not change the current execution
and give desired output. This hard coding can be removed
by using some parameters which can either be stored
in the database or generated at run time.
Conforming to the coding
standards
Many old systems did not follow coding standards, which
leads to complexity in maintaining the software. By
applying coding standards one can do away with this.
Improving source code readability
By adding comments and doing proper Indentation source
code can be made more readable.
Renaming program items
Some times objects are not properly named or names do
not imply its purpose. One who named it and used it
knows, exactly the functionality of it but other person
cannot. This leads to changes in the code. So objects
defined should be renamed as per standards.
Re-documentation
"Re-documentation is the creation or revision of a semantically
equivalent representation within the same relative abstraction
level. The resulting forms of representation are usually
considered alternate views (for example, dataflow, data
structures, and control flow) intended for a human audience".
In many old systems no documents were maintained. So
understanding of the true functionality, design specifications
and business logic becomes very difficult. In traditional
documentation only text was used, no diagrams, presentation
were used. Now many new tools to draw such helpful diagrams
are available. Using such tools and representing information
in graphical mode makes it easy to understand the whole
system within very small time.
Platform transitions
Due to scarcity of resources for maintaining mainframe
systems organizations are now migrating to advanced
technologies. System migration in such cases includes
changes in platform and hardware.
Consider a situation where old software and new proposed
software are on different platforms. Say old system's
database is 'INFORMIX' and new proposed database is
'ORACLE 9i'. In such cases lot many complexities are
to be considered. Old systems objects should be mapped
with new systems objects. All attributes of the old
system's objects should have some substitute in new
system. It may be the case that some concepts used in
old system are not supported in new system. In such
cases it is required to find alternatives or simulation
of the concepts in new system. E.g.
The old database is INFORMIX and new database is Oracle
9i. In INFORMIX a table has name 'PUBLIC'. While transforming
this database schema into Oracle 9i 'PUBLIC' is keyword
and cannot be used as table name. So the table should
be renamed in Oracle 9i.
Language conversion
Many old systems were developed using procedural language.
These languages have many limitations on control flow.
Some of these languages do not support reusability feature.
Now many Object Oriented Languages are launched. These
languages do supports all features provides by procedure
languages plus offers new features that makes code more
efficient, optimized, readable and easy to manage. Also
these languages provide good user interface, graphical
display to make application more attractive and easy
to use.
Migration to client/server
and web
New era of web technologies, made it possible of having
instantaneous presence of the business in Global Market.
Today, speeds at which businesses establish their web
presence hold the key to success. So the trade of converting
traditional green screens (dumb terminals) to web pages
and system to web application came. So porting a web
application, which follows all Business rules and provide
user-friendly interfaces require Reengineering. In traditional
systems user were well trained and they had proper knowledge
of the systems. So on screen validation, security issues
were not considered while developing. But as different
types of end user with different privileges can work
with the systems in web application, while developing
system developer has to think of security levels, privilege
levels, screen field validations along with business
rules. In traditional systems database server is physically
connected and number of clients connected is limited.
But in web application numbers of users do ask for services
to either web server or database server. To achieve
such functionality different techniques like connection
pooling, HTTP prototypes are used.
Many of the legacy systems were single user. But web
applications or client/server application are multi-user,
so problems of concurrency, deadlocks, data consistency
should be considered.
Business rules extraction
In many Legacy systems code is not readable, no comments
are written, very less or poor documents are available.
Very few peoples in an organization know all business
rules in details. It is a great challenge to extract
business rules from reading code, documents or interviewing
organization people. Many times organization grew by
overtaking some small organizations or merging two organizations.
In such conditions legacy systems are either integrated
or merged or used separately. So understanding all business
rules correctly, finding dependencies in functionality,
as a single system is difficult. Many tools are available
in market to extract business rules from piece of code.
Using these tools 90% of business rules can be found
from the coding. Along with code, many times business
rules were implemented in database itself by applying
constraints on it. For example, suppose if minimum balance
in saving account is say $100, and customer is trying
to withdraw amount, which will violate above condition.
In implementing such logics many times constraints are
imposed in database itself, so reading only code one
cannot extract such rules. This need detailed study
of code al well as database schema. From code extracting
design is called Reverse Engineering.
Testing
Testing in reengineering is bit easier than new development.
All test cases are well defined. Still some problems
occurred, in case, system do have external interfaces
like flat files created by the application are passed
to some other system like IBM mainframe. If system development
is in-house then very less problem occur in developing
application. But in case the project is outsourced to
third party, many a time development and deployment
environment could be different, many problems may occur.
Many times character set used may be different or deployment
environment doesn't supports development environment's
features.
Many times testing data is created from old legacy
system's database. This testing database may require
historical information, which is not selected while
creating test data. This may give false result in testing.
For example, suppose condition is like, if last transaction
is not happened within a time span of 30 days, some
extra charges should be applied. In test data the last
transaction is not inserted and one tried to execute
it in both old and new system. In such condition output
of the old system will differ from output of new system
and one may conclude that this test case is failed.
Data migration
Data migration is one of the important issues of reengineering
projects. In reengineering project one cannot afford
losing a single bit of information, database. So data
migration is itself a complicated task and handled separately.
Many times, in implementation of new system some changes
are made in database schema. So while migrating data,
care of such changed logic should be taken. For example,
suppose in a legacy system column name do not imply
the exact use of it, so the column is renamed in new
database. Or some constraint is added to the column
and data in the legacy system database violates this
condition
Design Issues
After analyzing the existing system the analyst comes
up with a revised system architecture, which satisfies
the current business needs and also enhances the performance
and efficiency of the system. But the organization may
insist on maintaining the way of implementation of some
business processes as they were done in the old system,
which may reduce the efficiency of the new system.
Functional issues
Switch Over
This is an important issue of installation. After unit
testing and approving functionality of the system, time
is to start working with the new system. But organizations
do not take risk of changing systems in one night. Organizations
start using new system parallel to their existing systems.
For this developers implement Tools like Forward gateway
transferring old system database to new system database
and reverse gateway transferring new system database
into old system database. Parallel run is a temporally
process till the organization is thoroughly convinced
by the new system outcomes.
User Training
Its normal human tendency to get habituated if he/she
is used to do some task even if it is complicated. In
legacy system user gets acquainted to Green screens.
Some times invocation of the same functions gets changed.
So it is required to train the users for operating the
new system. For doing so, User Manuals are provided
to end user and Technical Manual to Administrator. Even
some time special training is required to arrange for
system users.
Time to Market
This is a marketing issue of an organization. In a well-established
business the organization should concentrate on their
quality of services and how to beat their competitors.
With new technologies like web, the organization is
just a mouse click apart from his customer. Accuracy
and the speed of the services can be significantly improved
using advanced technologies, renovated systems. This
will help organization to reach customers faster than
the competitor.
Reengineering
Approach (top)
| Phases |
|
Inventory
Analysis
Planning
System Analysis
Design
Development
Testing
Implementation
Parallel Runs
|
There can be two approaches while reengineering software.
One of them is a big bang approach and the other is
a phased approach. Generally, a software system is an
integration of subsystems. Big bang approach states
the complete migration from existing system to a new
one but the phased approach states the migration of
all subsystem one by one and thus gradually replacing
the complete system. Using the phased approach, the
organization reduces the risk factors and the downtime.
Implementing both the approaches one has to walk through
the following phases for reengineering a system
Inventory Analysis
This phase deals with module-wise inventory. It gathers
the artifacts, programs that implement the functionality
of each module, intermediate flat files and the database
scheme. The programs, database objects and flat file
that are no longer used are eliminated.
Planning
Complexity of the above gathered Inventory items are
studied using the automated tools. This helps in effort
estimation. Then taking into consideration the skilled
resources and the advanced technologies used to develop
the new system the planning is carried out.
Analysis
In renovating a project the important source of gathering
exact requirement is studying 'Current System' and documents
available of the system. Using tools analyst can extract
business rules from source code.
Study the legacy systems to understand the current
system architecture. This gives a clear picture of the
various modules and their interrelation. Identify the
reusable components and estimate the changes that would
be needed to rehabilitate them for reuse in new software
architecture. Use reverse engineering technique to extract
business logic from existing code. At same time focus
should also be on additional user requirements.
Design
Here we define the process flow, modules and their interdependencies.
Dependencies and the relation ships between various
database entities are modeled. Finally we come up with
new system architecture, which incorporates additional
features to implement current business needs.
Development
'System Architecture' designed in design phase is implemented
using advance technologies chosen during the analysis
phase.
Testing
Testing phase constitutes of creation of test data and
eliminating loopholes that are identified.
Implementation
Implementation comprises of data migration and deployment.
Data migration is a process carried out to populate
the new database from existing legacy systems. Deployment
phase includes installation of new system and training
users to operate the system.
Parallel Runs
After installation of new system, in product environment
old and new systems are used simultaneously. During
this phase outcomes of both systems are audited. This
is an iterative phase carried out in production environment
till is the customer is convinced.
Automated tools
used in Reengineering (top)
In reengineering project analysis phase consists of
extracting business rules from existing system. Also
in design phase technologies used for developing new
system is decided considering the requirements of the
system. Reading legacy code or studying legacy database
analyst is in a position to extract 60% of business
rules. Tools are used to dig out the rest of the business
rules. Tools also enable rapid development.
Reverse engineering tools are helpful to analyst in
extracting business rules and generate pictorial view
of the system. Forward engineering tools can be used
in generating source code from design diagrams. There
are also tools for converting coding script from source
language to target language.
Benefits of Reengineering
(top)
Reengineering offers organizations a number of distinct
advantages:
- Reduction in maintenance
costs, with enhanced understanding of the
functionality of applications. Optimized cost of
ownership of transformed system and reduced overall
costs (appointing new resources, training and
maintenance of legacy system).
- Improved access to the system
through re-deployment and re-orientation of existing
hardware and software resources. Anytime, anywhere,
secured access to users and customers. Easy access to
Users over the Internet since no additional hardware
or software is required to access the application.
User-friendly interface that requires minimal training
/ re-training. This will improve relationship with
customers getting more business from them
- Shifts dependence of
maintenance activities from few individuals to
transparent processes and tools. Ease of maintenance
from a Programming / Maintenance group perspective
- Comprehensive documentation
of system with complete knowledge of processes, which
will be helpful for maintaining the software.
- Managers get ride off
concentrating on working of legacy systems. So they
can focus on business.
- With advanced technologies like Data warehousing,
new features of extracting some business conclusion
from historical data could suggest the managers to
opt for Business Process Reengineering. In Insurance
sector, on analyzing 50 years of data, managers can
mold the existing policies to enlarge the profit.
Risk involved in Reengineering
Though reengineering increases the value of legacy
system but involves some risk factors as -
- While analyzing the legacy
system, the analyst may miss out some important
business rule, which may lead to undesired outcomes of
the new system.
- No system can be ideal. The project comes to an
end because the time and budget are played out. Thus
the new system may have some faults, which were not
identified in testing phase.
Conclusion
Reengineering process includes understanding and documenting
the existing system, splitting the complete system into
different layers as application layer, business layer
etc. making the system easy for maintenance, extracting
reusable components and if situation demands converting
the legacy system to a web based process or client/server
application. This can be achieved through a proper methodology
that is tailored to individual project needs.
page
top
|
