Archives
Contribute
|
Technology: Migration – Legacy Systems To 4GL Technology - Part II
|
|
10/15/2005
Migration – Legacy Systems to 4GL Technology
Legacy applications are frequently large, monolithic and difficult to
modify, and scrapping or replacing them often means reengineering an
organization’s business processes (workflow) as well. Legacy migration
is about retaining and extending the value of the legacy investment
through migration to new platforms. This article discusses the benefits
and migration tools for migrating from leagacy systems to 4GL
technology.
The following Enterprise Architecture gives the flexibility and
scalability to the current and future business need. Any type of
clients can interact with the common system to form a single
transparent enterprise online.
Reusability
Existing systems were optimized to perform functionality in a
predefined structure. The business today in the global market calls for
frequent change in functionality implementation that demands fresh
development efforts to expand the capabilities of the existing system.
The consequences of which are time & costs and handicaps in coping
up with the new functionality requirements. Openness
Existing systems are usually tied to an existing vendor offering and
are hence proprietary. The business’s need today is to be able to
communicate seamlessly to many systems and be open to other application
systems. The migrated Business Component will be deployed as a
CORBA object in the application server, which can be accessed by any
front end applications written in any languages like Visual Basic, Java
etc. Any additional developments can be done using Java and
EJB’s, and can be deployed in the same server. There fore both the
components can co-exist in the same application server, commonly
accessing the business logic, which is in true sense an open
architecture Migrate Using Power Migratorâ„¢ tool This option of migrating the application to the web using our Power Migratorâ„¢ tool is discussed now.
As discussed earlier, most organizations and users are fearful of the
fact of moving the client server application to the web for many
reasons. The costs are prohibitive, the learning curves are very high
and the users are not sure if the migrated application’s look and feel
is similar to that of the original application. Now we discuss how the apprehensions can be resolved using Power Migratorâ„¢ Skills As we are using the same code for migration, there is no need to learn new skills
The existing development team’s Power Builder Skills are sufficient
enough to work with Power Migratorâ„¢ to move the application to the web.
A few junior level JSP programmers may be required, in case the generated JSP code needs to be altered. Reusability of the existing Code
The most compelling reason would be that it allows the client to
leverage the existing Power Builder code and use that to move the
applications quickly. If the client application is a large application,
it would make sense to assume that lots of business logic has gone into
the code. This could be missed in the event of a rewrite. If
the application is fairly large, that have been evolving over time, it
would make sense to use the skills sets of the present development
staff, and into which investments of thousands of dollars would have
gone into. These costs can be completely saved, as there are no
training costs. Cost benefits
The cost benefits are enormous for the reasons so far discussed. The
path towards migrating the current application would take less than
half the time it takes to rewrite the entire software. Similar cost
benefits are indicated, taking into account the huge infrastructure
investments to be made for rewriting the application. The effort to
migrate the application is also lesser considering the fact that the
application is already put in use and the development staff are skilled
on the application. Learning Curves. Negligible learning costs, as the Power Migratorâ„¢ is an automated tool. Component coexistence
After migrating the application to the web, instances may occur that
fresh developments may need to be done to either the same application
or a completely new development can be started using Java and EJB’s. In
such cases the components can co –exist on the same application server
without encountering any technical problems. No need to invest on a new
application server.
(Vidya received her MA in Communications from Madras University. She started SolveIT in 2003 to develop the tool to support migration. She can be reached at vidya@solveitcorp.com. )
|
You may also access this article through our web-site http://www.lokvani.com/
|
|