Sofrepost, a subsidiary of La Poste (the French mail), develops and sells SPS, a management system for post offices. Our clients are national postal systems from a dozen countries on several continents.

SPS is composed of five packaged applications developed with PowerBuilder that represent around 150 Mo of code, 400 windows and 1200 DW.

The initial development of our application took place in 1996 and required approximately 10 man years. The application has since been regularly modified to extend its functionalities.

More recently, the requests of our clients have led us to study solutions to modernize this system, with three main objectives:

1. Web migration: The clients wish to lower the deployment costs to their many post offices. They also need to offer access at a distance via a simple web browser, in particular for the use of financial services.
2. Makeover: Presentation standards have evolved over the years, therefore we need to redesign the graphic interface to give it a more modern look.
3. Flexibility: The more the functionalities are extended, the more difficult it becomes to provide an application that responds to all needs. Clients have regularly asked for adaptations. The first requests were dealt with by modifying the code, but that resulted in the need to maintain multiple versions of  the application. It became necessary to make the application flexible and configurable so that clients were able to adapt their copy without having to modify the code.

Which Strategy?
We first needed to choose a strategy and a technical platform:

• Redevelop the application: Writing a web version of the system would probably take place in Java or .NET and would require several years and a budget of several million Euros. This strategy would also risk failure tied to the adoption of new technologies and the considerable length of the project.
• Adapt the existing application: Staying with PowerBuilder presented fewer risks, but it would also require specialized solutions to attain the objectives listed earlier. After study and confirmation, this was the strategy we adopted.

Which Tools?
Web Migration
The applications were web-deployed with Appeon for PowerBuilder.

• They were first modified to be compatible with this tool; certain unsupported PB functionalities were replaced.
• Of the five applications in the system, three needed to be migrated to the web. Each migration took approximately three months.
• Migration was done once and for all. Appeon includes a tool that guided our developers so that all future development in PB will include only the functionalities supported for web deployment. The next versions of the application can therefore be developed in PB and the next web deployment can be performed immediately, without requiring additional changes.

Makeover
The user interface was adapted to the new style guide:

• Certain modifications were performed with PowerBuilder.
• Others were done with Customization Studio - they were first saved in a repository, and then automatically applied to the source code. This process allowed all changes to be saved in an independent repository, to then be applied to other copies of the application adapted for specific clients.

Flexibility

• Customization Studio was integrated into the application to render it entirely configurable. The users can modify screens and reports directly from the executable version of the application.
• Reduces cost - integration required a few hours of work. The customization would be done by the clients according to their needs. There was no license cost for the company: clients using this tool would purchase an OEM license.

Results?
Web Migration
Users could access the application via a web browser. They would find the same as the client/server applications. Response time varied - from one to a few seconds - based on the transactions.

Makeover
The functionalities were the same, but the application's style changed (see Figure 1-3).

Figure 1: Original application

Figure 2: Customized application

Figure 3: Customized application deployed to the web

Flexibility
Clients could now customize the system themselves, reorganizing screens or adapting reports. They defined these modifications on an executable version of the application, without accessing the source code. The changes were stored outside the application and could easily be deactivated if there was a problem.

Conclusion
Strategy
The choice to adapt the PowerBuilder application, rather than to develop it in another technology, proved to be worthwhile: all our business objectives were achieved for a fraction of the cost of a redevelopment, with a time frame of several months and a significantly lower risk of project failure.

Recommended for all PB projects? Not necessarily. It would of course depend on your objectives and technical constraints. If you want an opinion on this subject, you can contact Novalys, who was responsible for the success of the project.