PowerBuilder, a classic foundation of many important and successful businesses, has embraced a path to modernization since Appeon direct involvement. Why is this relevant, with many software vendors trying modernizing their application with several (mostly unsuccessful) approaches?

 

Modernization has at least two styles: Upgrade and Rewrite. Rewriting PowerBuilder applications is reportedly difficult, expensive, time consuming –  unless you know very well what you are doing. I’ll cover modernization in a different article, but the point here is that our applications cannot stay in the slow sands until a new system is in place – this might take a decade and in the meanwhile if a vendor loses his customers there is no point (and no energy) to continue with neither the old or the new application. Harakiri.

 

Our customers complain about our PB applications for the following reasons:

  • Lack of browser interface
  • Client/Server architecture, not scalable and inadequate for the company structure
  • Old and stinky (sic) user interface
  • Lack of developers
  • Difficult to implement anything more modern than the ‘80s (security, localization, Messaging, background services, multi-threading, …)
  • Old tools not adequate with CI/CD

If any R&D Manager goes to the upper management or board of directors with the above list and the promise to solve this all in a few years with a new application, s/he will most probably get the approval. Despite the fact that:

  • “few years” is just a dream, and many software vendors try for a decade to modernize (this is just lack of knowledge and experience);
  • the costs are unpredictable – unless a strong plan is in place;
  • what is mentioned above can be actually worked around and exceptional results can be achieved quickly and effectively.

 

What I usually suggest in modernization approaches is to start with upgrading the PB application, and to ask yourself again if rewriting from scratch the full application is still a must-have or if, at that point in time, there are alternative approaches (partial and migrated rewriting). Our main priority as software vendors is not “to be modern”, but to back our customers with Products they can use effectively, without the urge to search for other vendors.

So let’s see how to address the points above.

 

Lack of browser interface

That is the striking point, and the one that weighs more on PowerBuilder. Desktop-cloud applications (if running on the supported desktop) are very efficient, but a browser interface gives much more freedom to the users, that could use the application on several devices. Of course there are deployment solutions (like Citrix) in which the viewer can run on many devices – but users still feel like entering a cubicle that, even though very safe, it is also outdated.

 

A browser interface is undoubtedly easier to use (primarily because it is designed with modern UX principles), but a B2B desktop cloud application is normally more efficient.

 

I’m sure that you remember the PowerServer Web – an impressive technology where no engineering effort was saved. The user interface was running in a browser (Windows only), and was pretty good if the UI was rewritten with a bit more modern UX design principles. However, porting an application that was written in the past proved not so effective (and on top of that, it wasn’t device independent).

 

Solutions: automatic porting and restyling or creating just the UI from scratch, leveraging PowerBuilder components running in the back-end, similar to what Web Banking applications do (this is called “PB Open” approach).

 

Client/Server architecture

This is not a limitation any longer: PowerServer is a brilliant scalable solution to run the PB App (Windows) on the cloud, with cross-platform backend components. Of course this is not a microservice architecture, nor a modular monolith, but if the problem is running the application out of the company intranet, this problem is effectively addressed and solved, with a scalable solution cheaper than deployment solutions (like Citrix). Today we have PowerServer for desktop-cloud DB applications, and PowerClient for desktop-cloud REST API applications.

 

User interface

Our PB UIs were designed in the past, and this often means that UX is not taken into account. In this case the learning curve for new users is very steep, and a common complaint is that the application is old (hinting that is inadequate, slow, not suitable any longer) while actually it was just designed in the past, but often with a solid foundation (depending of course on the technology and design principles used). Many Web Banking applications are still based on the old COBOL transactions, but the new UI gives a completely different feeling to users.

 

What can we do here? Use UI themes, implement the new controls (ribbon, tabbed interface – native or third parties), add an application navigator, implement resizing, change control validation and window validation. There is a lot that can be done, and even though not modern, your application can still be intuitive and very easy to use!

 

Lack of developers

It’s not as easy as in the past to find available PowerBuilder developers. But the many available ones are very experienced and very effective. The positive thing is that the availability is usually enough for upgrading and migration, you do not need a full-time PB developer staying “for life” on a single project. Not to advertise this, but my company is a leader in PowerBuilder outstaffing – that doesn’t simply mean putting PB resources under one roof, but actually leading, mentoring and monitoring their growth.

 

Standard needs for more modern applications

Have you heard: “we have to abandon PowerBuilder because our application requires XXX”? This usually refers to:

  • advanced localization, with dynamic change, translation memory management, layout switch (RTL-LTR), Unicode support
  • advanced messaging – mass e-mail, SMS, WhatsApp, chatting
  • Security with MFA, 
  • Docker containers, Exposing logic as Web Services, using REST APIs
  • multi-threading processing
  • access to the huge .Net library

 

Typical questions heard many times – but there are actually several alternatives: Dot Net support in PowerBuilder is available, as well as some multi-threading support, and a rich ecosystem that supports applications needs (Enable Multilingual, Fidelius ISV, Visual Guard, Ultimate Suite for PowerBuilder – just to name a few)! Of course, you need to know the tools and spend time to pick the right one for you – but isn’t this the interesting job of Lead Architects and Development/Innovation Managers?

 

CI/CD support

“The old PowerBuilder is only good for manual building”. But in fact there are plenty of tools (native and third-party) to support CI/CD, including SVN/Git support. And with the new PB2025 compiler, huge applications can be built in a few minutes. Now you don’t have any more excuse to create a new build when needed!

 

Conclusions

Modernizing is not a “one time pain”, but a continuous change to stay current with the times, avoiding a full rewrite as much as possible. PowerBuilder has today many tools to keep our customers engaged, and if a full rewrite is inevitable: it has to be quick to avoid on-going technology change and loss of customers. 

 

So my recommendation: 

1 – Keep your PB apps well maintained

2 – Modernize the application upgrading it for supporting your customers

3 – Consider a proper modernization plan that addresses exactly what you need to

 

Do not make the mistake (of many companies) that rewrite everything just because they do not know how to proceed!