November 2024 - Synchrony Systems

PowerBuilder is best known for its rapid application development (RAD) capabilities, particularly for building data-driven client/server business applications. It’s estimated that billions of lines of PowerBuilder code are running applications in North America alone, let alone globally.

PowerBuilder is considered to be a 4GL language. Key features of 4GL are a higher level of programming abstraction that is then used to generate the code into a lower-level language such as C or C++ and extensive components embedded into the language itself or its built-in system library. PowerBuilder is more of the latter than the former. Its WYSIWYG IDE with its event-driven programming model and all-in-one DataWindow presentation with powerful yet simplified data access CRUD capability, including sorting, filtering, computed fields, reporting, and other capabilities, is what gave it its claim to fame in its heyday.

Today, companies are looking to transform these applications to web and cloud environments to reap the benefits of their ubiquity, scalability, and global adoption. But what are the actual challenges of taking working, bespoke production applications written in PowerBuilder and transforming them into modern stateless microfrontends and microservices web architectures deployed in secure and scalable cloud platforms? Our modernization experts share some of the critical technical challenges teams face when undertaking such an endeavor.

Challenges modernizing PowerBuilder applications

Architectural differences

Generally speaking, PowerBuilder applications use a client-server architecture where the client handles much of the business logic and the server manages database access. Web applications, on the other hand, follow a more distributed architecture, often involving web servers, application servers, and browser-based web clients.

Splitting a monolith, especially a client-server, standalone, stateful monolith, into a web architecture is not for the lighthearted. Key challenges are:

Refactoring and decoupling presentation layout and logic from the underlying business model and logic.
Extracting application services into the web server tier and replacing direct access with REST calls.
Identifying interdependencies, interwoven user interfaces, and business logic and properly splitting it to work in the web tier.
Removing dependencies on stateful data access, such as open cursors and long transactions.
Last but not least, re-implementing the decades-old reliable software in new, and often multiple, new modern programming languages.

General code migration challenges

Modern web applications often use frameworks such as Angular, React, or Vue.js. Integrating the PowerBuilder business logic and data access layers with these frameworks requires significant refactoring and a very heavy lift in the absence of automation and refactoring tools. While dealing with a single PowerBuilder language, often target architecture requires multiple languages – JavaScript on the client and/or Java or C# on the server. In addition, PowerBuilder uses its own scripting language, providing additional capabilities for manipulating data retrieved from databases that may require a complete redo or an equivalent custom interpreter that will implement the equivalent semantics and functionality on the web.

Type safety and validation

PowerBuilder’s dynamic data typing allows flexibility but can lead to runtime errors. Migrating to a statically typed language involves enforcing type safety throughout the application, requiring an upfront investment in defining interfaces, types, and classes for consistent data handling and error prevention. Validation is often embedded inside the DataWindow objects and must be shifted to a mid-tier or form validation in the browser.

User Interface (UI) transition

PowerBuilder applications use a desktop-style UI with windows and dialogs that don’t naturally translate to a reactive web layout, especially for DataWindow 4GL-like components. Web frontend frameworks such as React offer rich UI components. Still, those components do not have all the equivalent properties and presentation semantics offered by the PowerBuilder’s rich set of controls and visual components and certainly do not provide a DataWindow equivalent functionality. If a like-for-like outcome is chosen, an initial step of modernizing a PowerBuilder application will require an equivalent DataWindow compatibility component framework to be implemented in the target web UI framework. For a more comprehensive modernization with the objective of achieving a native web UI/UX target, a more granular approach is necessary to break down the underlying data window-dependent behavior into separate independent pieces of display/presentation behavior, corresponding data access and data binding, and reporting capabilities.

Data access

The DataWindow is the PowerBuilder superpower. Its abstraction includes presentation (drawing and displaying forms that can have both simple and complex widgets), data access that includes SQL or stored procedure invocation, data binding, and transactions. A more comprehensive approach is needed to achieve functional equivalence on the web target with a smart, well-integrated compatibility library that sits on top of existing frameworks such as React or Angular. Adapting the data access layer to work with web technologies involves changes in how database connections are managed. The main challenge is the proverbial “thin-client” architecture, which implies statelessness. It’s not just that we are using different technologies for session management, connection pooling, etc.; the underlying transformation of the monolith into a microservices and microfrontends web and cloud architecture is where the real challenge lies.

Session management paradigm shift

PowerBuilder applications often rely on the session state maintained within the client application. In a modern web application, managing the client state requires technologies like Redux or another persistent data store on the browser side. Moving from a primarily client-side state management model to a distributed client-server architecture requires careful consideration of data synchronization. Depending on the application’s needs, data consistency and responsiveness are often achieved using REST APIs or WebSockets.

Performance

Whether the application is modernized for the web or built ground up for the web, it comes with the web territory of potential network latency in user response times and scalability depending on the demands of the underlying application profile. When modernizing a client-server architecture to the web, there is also the risk of potential consequential database “chattiness.” Once the application has achieved functional equivalence, attention must be placed on performance, overall application deployment, and scalability.

Security

There are differences in security practices for client-server applications and web applications. One of the most challenging parts of a PowerBuilder modernization to the web is extracting the application logic and, most importantly, the data access in the form of SQL and stored procedure calls to a web service layer. Once successfully split, other security layers, such as secure authentication (e.g., MFA, SSO), authorization protocols (e.g., OAuth, SAML, JWT), and data encryption and secure transmission (e.g., HTTPS), become more straightforward.

Overcoming these challenges

Addressing these challenges requires careful planning and a comprehensive modernization strategy. A phased approach to modernizing the application while maintaining its core functionality and user experience is often the best. At Synchrony, we go by the slogan, “don’t let perfection stand in the way of progress.” With our in-house advanced analytical tools, powered by code refactoring and code generation automation, we help streamline an otherwise very complex undertaking by simplifying its inherent complexity, reducing the risks associated with group-up overhauls, and ensuring that modernizations achieve functional equivalence and are completed at a fraction of cost and time with the absence of advanced automation.

Contact us to discuss your specific modernization needs or if you’d like to learn more about our PowerBuilder modernization experience and expertise.

Legacy systems, the reliable workhorses of the past, can become security nightmares in today’s ever-evolving threat landscape. While they may keep critical functions running smoothly, their outdated technology and lack of modern security features create vulnerabilities that cybercriminals are eager to exploit. Let’s explore five key ways legacy systems can significantly increase your cybersecurity risk:

1. Outdated security can’t keep up with modern threats.

Remember the massive Log4j vulnerability that shook the cybersecurity world in late 2021? Legacy systems, often running on unsupported operating systems or software versions, miss out on critical security patches like these. This exposes them to known vulnerabilities attackers can easily leverage to access sensitive data or disrupt operations.

2. Legacy dependencies on aging hardware and software.

Many legacy systems rely on outdated hardware and software for core functionalities. Not actively developed or supported, these components are often riddled with unaddressed security flaws. For a recent example highlighting the security risks posed by outdated software, the Adobe ColdFusion vulnerability CVE-2023-26360 case is a strong illustration. In 2023, threat actors actively exploited this flaw to breach systems, including two U.S. federal government agencies, targeting their outdated versions of ColdFusion. Hackers exploited this vulnerability to gain access, install malware, and perform reconnaissance activities on the compromised systems. However, prompt defensive measures thwarted lateral movement and data exfiltration.

3. Limited visibility into security posture.

Legacy systems often lack the built-in security features present in modern platforms. They may struggle to integrate with modern security tools like Security Information and Event Management (SIEM) systems, hindering the ability to have a comprehensive view of a company’s security posture. This lack of visibility makes detecting suspicious activity or potential breaches within the legacy system difficult.

4. Accidental exposure of internal applications.

As business needs evolve, internal applications running on legacy systems can unintentionally be exposed to the internet over time. This creates a direct path for attackers to target them. One example is the 2023 Microsoft Azure data leak, where sensitive internal data was accidentally exposed due to a misconfigured endpoint. This exposure allowed unauthorized users to access information meant to remain internal, underscoring how overlooked configurations in legacy systems and applications can lead to significant data security risks.

5. Slow integration of modern security solutions.

Legacy systems often require significant modifications or complete rewrites to incorporate modern security features like multi-factor authentication or data encryption. Migrating these applications to the cloud is often incremental, as each component needs modification to work securely in the new environment. Until these applications are fully adapted, they’re more vulnerable to attacks and may not benefit from the cloud provider’s built-in security features.

Modernization is the path to a stronger security posture.

Ultimately, a long-term plan for modernizing or replacing legacy systems is crucial for a robust cybersecurity posture. Synchrony’s Modernization Lifecycle Platform (MLP) supports this process by automating the migration and transformation process, enabling collaborative workflows, and offering clear, traceable insights into software modernization. Continuous Modernization (CM) complements DevOps practices like Continuous Delivery (CD) and Continuous Integration (CI) by allowing organizations to apply software updates consistently and incrementally. This method enables smooth upgrades across in-house applications, APIs, and other software components, regardless of underlying technologies, keeping security and functionality aligned with evolving needs.

Challenges of PowerBuilder modernization