Modernizing PowerBuilder applications – a few approaches

Introduction 

PowerBuilder applications are used in mission critical environments and are the backbone of successful businesses. The question that every Software Development Director has on his/her table is: “what about modernization?”. Why so?

• the UI looks very old, and not just for the PB possibilities, but mainly because of lack of effort to modernize it. With many available tools, skipping the modernization of UI is a choice more than a limitation
• The applications run on Windows only, often in 32 bit (like an iPhone 5). No Mac, no browser, no tablet/mobile devices, and often from a terminal server that, albeit secure, feels a bit like a mainframe box
• The architecture scalability is limited, and that means that operating a PB application can be challenging

However, like in many banking and very important ERP systems, the most valuable applications characteristics are the user experience and a reasonably scalable back-end, and that’s reachable with a PB system (while web applications, exposed to millions of concurrent users, are not really in the target).

Modernization Approaches

In another article (https://enable-dev.com/pb-modernization-thru-application-upgrade/), I’ve underlined that before modernizing a PB application, it is mandatory to keep it updated, and then to try to do whatever possible to minimize the rewriting effort.

Modernizing the UI using the available tools still requires a Windows platform (properly updated), but the impact on the user experience is significant. When we want to go beyond this limit, we have to rewrite the application. 

Several approaches can be used to modernize a PB application, and other than the UI (that has to be rewritten) the following areas have to be addressed: business logic, architecture, database. 

This doesn’t mean that there are no other valid approaches, as every system is different: a lot of modernization experience is needed to succeed.

Approach 1

This is the UI-first, and consists of packaging the existing logic in reusable components. The architecture is not scalable, and it runs on Windows. However the UI is quickly modernized, and the benefit for the users is evident.

Approach 2

This requires a migration of the business logic, surely more intense than the first approach. The benefit is that the architecture becomes scalable. Can be built on top of the approach 1, as an upgrade

Approach 3

The logic is totally new, and this means tons of changes (and potentially bugs) will be introduced. This approach is surely more risky and time consuming. It doesn’t make sense to build on the other approaches. The advantage is a limited modern system – still sitting on an old and obsolete database

Approach 4

Everything new means tens/hundreds of developers dedicated to documenting (don’t be surprised that old systems have little or no technical documentation) and rebuilding a system from scratch. A truly modern system that, if completed quickly, can be a game changer. Data migration and user training are of course huge topics to address, as a consequence of this approach.

Which approach?

Every combination of system and company is unique. However, there are some elements that can be used for guidance:

• UI first, no big change in terms of concurrent users: use approach 1 or 2 (or 1 first, upgrade to 2 if needed). This gives the biggest benefit to the users, in reasonable time, with limited costs. The platform and DB stay almost the same, unless more scalability is needed (in this case approach 2 is recommended).

Pro: Low risk, reasonable time, happy users

Cons: limited scalability

• “Internet banking” approach: use approach 2 or start with approach 1 and then upgrade to 2, as it is unlikely that approach 1 alone would be enough. 

Pro: Limited risk, reasonable time, scalable (but not as a public internet service), happy users, reasonably happy operations

Cons: cannot scale to public internet service structure

• When UI is not enough and you dare to rewrite the system: use approach 3, but do it quickly, to avoid technology obsolescence. Fast or slow, this approach is very expensive, and results are not as good as with approach 4: the database is as bad as it was in the past (in old PB applications, there is often complete lack of design principles).

Pro: happy users (but only if done quickly), scalable, reasonably happy operations (DB is basically the same)

Cons: Risky, big effort, limited modernization (same old database)

• When you want a real modern system: be prepared for a very big investment and in a short time. 

Pro: very scalable (when this is really needed), happy users (but only if done quickly), happy operations (if they manage to properly address the complexity of deployment), fully modern system

Cons: Risky, big effort, most expensive and complex approach. Basically like buying an existing modern application and improving it.

Key points to guide us on these very complex topics

• UI modernization is mandatory, and must be done as soon as possible to keep users happy
• To modernize the UI you need a solid API-backed approach
• Keep in mind: risk, investment, timeframe, strategy to use, user training, database migration
• When we say “Big Risk”: this is not just additional costs: it can really blow-up the business
• Modernizing is necessary but it requires huge energy and modernization experience
• Sometimes the urge to extreme modernization is more a wish than a need: be realistic
• Being successful in developing an application doesn’t mean being successful to modernize it

Which tools?

• UI can be rewritten in Flutter, React, Angular, Vue.JS, .Net MAUI, Blazor just to name a few
• Packing the business logic can be done with PowerBuilder-based REST-API tools (there are several available)
• Migrating the business logic to C# can be done with .Net DataStore and native migration tools

Rewriting the logic completely can be done with proper religious blessing, huge budget, a deep risk analysis, and a lot of developers. Adding a full rewriting from scratch is even more expensive than buying another solution and customizing it (plus data migration).

Is it possible to Modernize a PB application?

Yes, it is possible, considering first of all what we really need, and the cost/benefit of the operation.

It must address a rewrite of the UI, necessary for keeping the users happy and involved. It must be done quickly.

If you modernize the database, you are heading for a full rewrite that will also cost you very complex migration programs. If you don’t, you have to lower your expectations: it will be a partially modern solution, so it is not reasonable to have high risk and huge costs.