Transcript Sybase PowerBuilder Modernization Step by Step

Sybase PowerBuilder
Applications
Modernization
About the Company
•
•
•
Founded in 2002
Unites high-level information technology and
organization architecture professionals.
Areas of specialization:
– Legacy modernization from Oracle Rally to Java
(Enterprise Edition) environment
– Legacy modernization from Sybase PowerBuilder to JEE
or .NET environments
– Borland Delphi modernization to JEE environment
– Oracle PL/SQL to Java modernization
– Legacy environments
– Architecture, Foundations, Database and Application
development in Java and .NET environments
7 July 2015
2
Relevant Projects
A large U. S. power corporation
A large U.S. government agency
A large Israel government agency
7 July 2015
3
Partners
7 July 2015
4
Managing the future of your legacy
applications???
Modernization
7 July 2015
5
Rewriting from scratch
•
•
•
•
Very expensive and costineffective
Long “time-to-production”
cycle
Wasting of resources for
maintaining of the existing
application during the long
development of the new one.
Risky in terms of budget,
time and functionality
"Legacy code" often differs from its suggested
alternative by actually working and scaling.
Bjarne Stroustrup, the father of C++
7 July 2015
6
Conversion or Face Lifting?
Face Lifting
Conversion
Modernization
project cost
Relatively low cost
May go up to 1/3 of the complete
rewriting cost
Modernization
project duration
A couple of months
Generally from 5 to 12 months
Maintenance
personnel
The legacy team (which may be
problematic to have), and in addition
new personnel is required.
Regular developers knowing how
to work in the modern
environment – easy to be found
Maintenance costs High costs: development in the legacy
environment, face lifting tool licensing,
regular “micro-modernization” projects
for face lifting, face-lift environment
maintenance etc.
Regular development costs in the
modern environment
Development
environment
Development of the new features in the Development of the new features
old legacy environment with all the
in the modern environment with all
problems
the benefits
Time to market
Face-lifting cycle prevents new features New versions can be produced
from fast deployment
faster
7 July 2015
7
Automated Modernization
•
•
•
•
•
The existing application logic is automatically preserved
Low risks in terms of the project scope and schedule
Easier deployment and shorter end-user learning curve
You always can go back
Maximum use of the existing manpower
7 July 2015
8
PowerBuilder
Modernization Process:
Architecture Change
7 July 2015
9
Legacy Thick Client Architecture
7 July 2015
10
Modern Thin Client Architecture
Microsoft .NET 4.0
7 July 2015
11
Modern Thin Client Architecture
Java Enterprise Edition
Any Servlet/JSP
Container
Database
Server
JSP
Business
Logic,
Data Access
7 July 2015
12
PowerBuilder
Modernization Process: Steps
7 July 2015
13
1. Learning the Application and the
Environment
Objective
Understanding the application and its environment.
Process
Learning the application.
Obtaining the source code.
Identifying exceptions.
Mapping external resources (images, help files, INI files, XML and text
files, registry keys etc.) and interfaces (DLLs, applications etc.).
Understanding the target environment.
Schedule
About three weeks for a medium-size application
Deliverables
Draft version of the System-Wide Standard (S.W.S.) for the application.
Application sizing and modernization project estimations
Target platform and “modernization feasibility” recommendations
7 July 2015
14
2. Integrity Check
Objective
Preparation of the original application for the conversion.
Process
System integrity checks.
Building walkthrough scenarios (by the client) - scenarios “how an enduser works with the application”.
Identifying failures.
Application fixing (if required), or documenting for after-conversion fixes.
Schedule
About a month, depending on the application and the client availability.
Deliverables
Cleaned application
Bug report + fixes plan
Walkthrough scenarios (by the client), approved by MainTrend
7 July 2015
15
3. PowerBuilder Objects Export
Objective
Extracting of all the PowerBuilder objects from the application libraries to
text files.
Process
Libraries consolidation.
Duplicates identifying.
Export of all the PowerBuilder objects to text files.
Schedule
Less than a week.
Deliverables
Plain text source files for all the PowerBuilder objects (correct versions).
7 July 2015
16
4. Reverse Engineering
Objective
Preparation of the intermediate files, required for the code generation
step
Process
Parsing of the code of all the PowerBuilder objects and building the
abstract syntax tree and the dictionary for the application.
Managing relationships and inheritances.
Deleting unnecessary objects.
Schedule
From a week to two weeks.
Deliverables
Abstract syntax tree for the application (xml files)
Application dictionary (xml file)
The second version of the S.W.S. document
7 July 2015
17
5. Code generation
Objective
Producing of the code according to the target environment.
Process
Automatic generation of the destination code.
First fixes according to the S.W.S.
Manual completion for exceptional objects (e.g. OLE).
Schedule
Defined in the S.W.S. depending on the size and complexity of the
application.
Deliverables
Application code migrated to the target environment.
A third version of the document S.W.S.
7 July 2015
18
6. Unit Test (UT)
Objective
UT environment building.
Performing of the unit tests.
Process
Preparation of the UT environment at the customer premises (servers,
required software, test database etc.).
Linking the unit test application to the test database.
Installation of the UT application in the UT environment.
Performing of the unit tests.
Schedule
Defined in the S.W.S. depending on the size and complexity of the
application, and on the availability of the customer.
Deliverables
UT environment installed at the customer premises
UT report
7 July 2015
19
7. Database Migration
Objective
In case the database platform is changed – to have the production
database migrated to the new platform.
Process
Database metadata and database data migration.
Building reports for the application changes required in response of the
database changes
Preparation of production servers and related software.
Tests and the database fine tuning.
Schedule
Defined in the S.W.S. depending on the size and complexity of the
application, and on the availability of the customer.
Deliverables
Complete and working database.
Report of the performed database changes.
7 July 2015
20
8. Integration
Objective
Building of interfaces and links to external systems.
Integration of all the application parts.
Process
Changes to match the new database structure.
Adjustments to the operating system.
Building interfaces to external systems.
Building and linking of external objects.
Making the integration of all the parts of the system
Schedule
Defined in the S.W.S. depending on the size and complexity of the
application, and on the availability of the customer.
Deliverables
Customized application connected to external objects.
7 July 2015
21
9. Integration Test
Objective
Integration tests including end-users involvement.
Process
Performed as a “Test and fix” cycle.
Performed in cooperation with the customer’s end-users according to
the walkthrough scenarios prepared in the second step.
Schedule
Defined in the S.W.S. depending on the size and complexity of the
application, and on the availability of the customer.
Deliverables
Verified customized application connected to external objects.
7 July 2015
22
10. Web-environment adaptation
Objective
Making adjustments to the thin-client browser-based environment.
Process
Adjustment of the web forms according to S.W.S.
Adjustment to the size limits to get the desired response times.
Fixes and adjustments which are found needed during the process.
Schedule
Defined in the S.W.S. depending on the size and complexity of the
application, about a month for a medium-size application.
Deliverables
The application ready for the user acceptance test.
7 July 2015
23
11. Implementation to Production
Objective
Acceptance and moving to production.
Process
User acceptance tests.
Finishing of all the needed installations in the production environment.
Moving to production.
Training for the end-users.
Training for the client’s developers.
Schedule
Defined in the S.W.S. depending on the size and complexity of the
application, and on the availability of the customer.
Deliverables
The modernized application working in the production environment.
7 July 2015
24
Legacy Software Migration
Case Study
Case Study (1)
•
•
•
•
•
The customer: DLF - Family Department of the
Commonwealth of Puerto Rico Government (a large
U.S. government agency).
More then 3000 users in more than 100 local
offices.
The legacy application: supported almost all DLF’s
activities.
More than 150,000 lines of code.
More than 30 man-years of investment.
7 July 2015
26
Case Study (2)
•
•
•
•
•
A joint team (Hewlett Packard of Puerto Rico as an
integrator, MainTrend as a conversion
subcontractor).
The core of the migration was the automatic
conversion
The entire migration took less than 7 months from
the project start to the new converted application
working in production
Costs about one third of the estimated budget of a
full rewrite.
The resulting application is now maintained by the
department’s own developers.
7 July 2015
27
Case Study (3)
•
•
•
•
•
•
•
No loss in business knowledge.
A significant reduction in client maintenance (browserbased solution).
Low assimilation efforts.
Much easier to find development personnel.
The more flexible programming environment reduces the
“maintenance cost per change”.
The new technology allows application enhancements to
increase business productivity.
Paul Segarra, the DLF’s project manager: “The system is
working great and everyone is highly impressed on how
quickly and accurately the conversion went!”
7 July 2015
28
Thank You!
For additional information:
Site: http://maintrend.net/
Email: [email protected]