Introduction

For more than twenty years, I have developed, maintained, optimized, and modernized enterprise applications with PowerBuilder.

During that time, I have seen many technologies emerge with promises to completely transform software development, replace existing platforms, and solve almost every organizational challenge automatically.

Some of those technologies introduced valuable ideas and became industry standards. Others disappeared after only a few years.

For that reason, when generative artificial intelligence began taking a central role in the technology industry, my first reaction was not immediate enthusiasm, but caution.

After many years of working with mission-critical systems, databases, transactions, security, complex business rules, and enterprise processes, you learn that not everything new automatically represents an improvement.

You also learn that an impressive demonstration does not always become a reliable enterprise solution.

At first, I resisted using artificial intelligence.

I wondered what a language model could teach someone with more than two decades of experience solving real business problems with PowerBuilder.

How could artificial intelligence understand the business rules accumulated over many years, the operational exceptions, internal processes, and technical decisions that shaped a mature enterprise application?

Over time, however, I realized that I was asking the wrong question.

Artificial intelligence did not need to replace my experience. It could help me use that experience more effectively.

It did not need to compete with PowerBuilder. It could expand its possibilities.

And I did not have to choose between an established technology and an emerging one. The real opportunity was learning how to combine them.

1. Resistance Is Not Always Fear of Change

Those of us who have worked in enterprise software development for many years are sometimes described as resistant to change.

However, that resistance does not always come from fear or a lack of curiosity.

In many cases, it comes from experience.

We know that an enterprise application is not simply an attractive user interface. Behind every window, there are validation rules, permissions, transactions, accounting processes, integrations, exceptions, and dependencies that may not appear in any documentation.

We also know that modernizing a mature application is not simply a matter of translating code from one programming language to another.

When an established application is replaced, there is also a risk of losing years of accumulated business knowledge.

That knowledge may be distributed across PowerScript code, DataWindows, events, stored procedures, database triggers, configuration files, external components, integrations, and decisions made by different generations of developers.

For this reason, it is reasonable to carefully evaluate any proposal based on rewriting everything from scratch.

Experience teaches us that technologies should be evaluated according to their ability to solve real problems, not according to their temporary popularity.

My initial resistance to artificial intelligence came precisely from that concern.

I did not want to depend on a tool capable of producing code that appeared correct while lacking a complete understanding of the application’s actual context.

Eventually, I understood that AI should not be treated as an automatic source of truth.

It should be used as a support tool whose results must always be reviewed, tested, measured, and validated by an experienced developer.

That change in perspective was fundamental.

2. Artificial Intelligence as a Copilot, Not a Replacement

Artificial intelligence can generate code, analyze SQL queries, explain functions, create documentation, propose architectures, design interfaces, and identify potential issues.

However, it does not automatically understand the specific needs of an organization.

It may suggest how to optimize a query, but it does not necessarily know why a particular business rule was implemented fifteen years ago.

It can generate a REST service, but it does not automatically understand the organization’s security policies.

It can propose a new interface, but it does not fully understand the operational needs of users who work with the system every day.

For this reason, I believe the best definition of AI in enterprise software development is that of a technical copilot.

The developer continues making the important decisions.

AI helps accelerate analysis, explore alternatives, reduce repetitive work, create initial prototypes, and approach problems from different perspectives.

In PowerBuilder projects, artificial intelligence can be used to:

• Analyze extensive PowerScript code.

• Explain legacy scripts.

• Generate initial technical documentation.

• Detect duplicated logic and possible maintenance problems.

• Suggest unit and regression tests.

• Generate controlled test data.

• Review SQL queries used by DataWindows.

• Propose performance improvements.

• Create initial versions of REST integrations.

• Generate JSON structures and data transformations.

• Produce HTML and CSS prototypes.

• Design dashboards for the WebBrowser control.

• Convert technical results into executive reports.

• Help identify dependencies before modifying an object.

• Suggest modernization strategies for existing modules.

The important difference is that developers no longer need to begin every task with a blank page.

AI can produce an initial proposal.

Our experience determines whether that proposal is correct, secure, efficient, maintainable, and appropriate for the business.

3. The Core That Continues to Make a Difference: DataWindow

After exploring different programming languages, frameworks, and architectures, my appreciation for DataWindow has not decreased.

On the contrary, every comparison allows me to better understand how advanced its original design was.

DataWindow is not simply a database-connected grid.

It is a declarative technology that integrates data retrieval, presentation, editing, validation, sorting, filtering, reporting, change tracking, and database updating.

That level of integration continues to represent a significant advantage.

In many modern frameworks, a relatively simple enterprise operation requires combining several independent elements:

• A data model.

• A data access layer.

• A visual component.

• A data-binding mechanism.

• Validation rules.

• Change tracking.

• State management.

• Serialization.

• Communication with the server.

• Error handling.

• Transaction management.

• Additional code to synchronize the interface with the data.

In PowerBuilder, much of that cycle can be managed centrally through DataWindow.

This does not mean that DataWindow is the perfect solution for every possible scenario.

It means that it remains an extraordinarily efficient technology for data-intensive enterprise applications, especially when combining business forms, complex queries, record editing, reporting, validation, and transactional processes.

The accumulated value of hundreds or thousands of DataWindows should not be viewed simply as a legacy obstacle.

In many organizations, those objects represent a strategic asset.

Each DataWindow may contain years of functional knowledge:

• Table relationships.

• Joins.

• Calculated fields.

• Business expressions.

• Visual rules.

• Formatting.

• Filtering.

• Grouping.

• Validation logic.

• Update rules.

• User workflow behavior.

Discarding all of that work simply to adopt a different user interface can become an expensive and risky decision.

PowerBuilder developers understand that the value of a DataWindow is not limited to what appears on the screen.

Its true value lies in how much business knowledge it encapsulates.

4. Modernization Does Not Necessarily Mean Rewriting

For many years, modernization has been associated with the complete replacement of existing technology.

Under this perspective, a PowerBuilder application could only be considered modern if it was rewritten using another language or framework.

I believe that interpretation is too limited.

Modernizing an application means improving its ability to respond to the current and future needs of the business.

This may include:

• Improving the user experience.

• Strengthening security.

• Integrating with external services.

• Exposing functionality through APIs.

• Automating repetitive processes.

• Incorporating intelligent analysis.

• Improving deployment.

• Supporting cloud environments.

• Adapting to different resolutions and devices.

• Reducing maintenance time.

• Improving auditing and monitoring.

• Facilitating integration with other systems.

None of these goals automatically requires removing PowerBuilder.

A complete rewrite may be appropriate when there are sufficient technical and business reasons.

However, it should not be the default response.

Before starting a full replacement, organizations should ask:

1. What specific problem are we attempting to solve?

2. Is the problem related to the technology, the architecture, the interface, or the development process?

3. Which business rules could be lost during the rewrite?

4. What is the real cost of reproducing all existing behavior?

5. How long will the old and new applications need to coexist?

6. How will both systems be validated against the same business scenarios?

7. Does the organization have the resources required to maintain the new platform?

8. Can the application be modernized gradually instead?

9. Which modules genuinely need to be replaced?

10. Which components continue providing business value and should be preserved?

In many situations, progressive evolution is less risky and delivers business value faster than a complete rewrite.

True modernization means preserving what works, correcting what creates limitations, and adding what is missing.

5. The Appeon Era and the Connection to the Modern Ecosystem

PowerBuilder should no longer be evaluated exclusively according to the image some developers remember from older versions.

Appeon has continued evolving the platform through improvements to the IDE, compilation process, security, integration capabilities, deployment, DataWindow, cloud connectivity, source control, and the general development experience.

Modern versions of PowerBuilder provide developers with new opportunities to preserve their existing investments while integrating applications with the broader technology ecosystem.

One of the most important elements for visual modernization is the WebBrowser control based on Microsoft Edge WebView2.

This control makes it possible to combine a native PowerBuilder application with HTML, CSS, and JavaScript components without abandoning the existing architecture.

This creates a highly valuable integration space.

PowerBuilder can continue managing:

• Database transactions.

• Database connectivity.

• DataWindows.

• Business logic.

• Validation rules.

• Update processes.

• Internal security.

• Report generation.

• Existing enterprise integrations.

• Critical operational workflows.

At the same time, WebView2 can be used to incorporate:

• Interactive dashboards.

• Advanced charts.

• Technical diagrams.

• Modern calendars.

• Visual editors.

• Maps.

• KPI panels.

• Specialized document viewers.

• Conversational interfaces.

• Artificial intelligence results.

• Dynamic HTML reports.

• Components developed with modern web technologies.

This is not simply about displaying an isolated web page inside a PowerBuilder window.

It is about building a communication channel between both environments.

PowerBuilder can send structured data to the web component.

JavaScript can present that information visually.

The user can interact with the content and send events, selections, or results back to PowerBuilder.

In this way, the system preserves its enterprise core while adopting a more flexible and modern visual layer.

6. Hybrid Architecture as an Enterprise Strategy

A hybrid architecture makes it possible to use each technology where it delivers the greatest value.

Instead of forcing PowerBuilder to solve every possible visual requirement, or transferring the entire application to a new platform, responsibilities can be distributed intentionally.

A modern hybrid PowerBuilder architecture can be organized into several layers.

Enterprise Core

PowerBuilder maintains critical processes, transactions, consolidated business rules, DataWindow operations, validation, and interaction with existing systems.

Integration Services

Functions that need to be shared with other systems can be exposed or consumed through REST services, JSON, HTTP, messaging, or middleware.

Visual Experience

Components requiring a more dynamic presentation can be implemented with HTML, CSS, and JavaScript inside the WebBrowser control, or as external applications connected through services.

Artificial Intelligence

AI can be integrated as an additional service to analyze information, classify documents, summarize data, assist users, generate recommendations, or automate specific tasks.

Validation and Governance

PowerBuilder remains responsible for applying deterministic business rules, controlling transactions, validating information, and recording results.

This separation prevents AI from having uncontrolled access to critical enterprise processes.

For example, an AI model could analyze an invoice and return a JSON structure.

However, PowerBuilder should validate the extracted information, apply the business rules, request user confirmation when necessary, and determine whether the transaction can be recorded.

AI proposes or interprets.

The enterprise application validates and executes.

7. Expanding My Perspective Changed My Professional Evolution

The most important transformation in my recent professional journey did not begin with a new programming language, a new framework, or an artificial intelligence model.

It began when I expanded the way I looked at technology.

For many years, I approached development primarily from the perspective of what PowerBuilder had traditionally been used to accomplish.

Once I opened my mind to other technologies, integration models, visual approaches, cloud services, web development, and artificial intelligence, I began to see PowerBuilder differently.

I stopped asking:

What are the limitations of PowerBuilder?

And I started asking:

How can PowerBuilder be connected with modern technologies to create something new?

That change in perspective significantly influenced my evolution as a developer.

Instead of viewing HTML, JavaScript, WebView2, REST services, cloud platforms, external APIs, and artificial intelligence as competing technologies, I began to see them as complementary tools.

Each one can extend the capabilities of PowerBuilder while allowing us to preserve the stability, business logic, security, and data-management strengths already present in our applications.

This new mindset motivated me to explore, experiment, build demonstrations, and share what I learned with the PowerBuilder community.

As a result, I have published more than 21 code examples demonstrating practical possibilities for improving and extending PowerBuilder applications.

These examples are not intended only to demonstrate isolated technical features.

Their broader purpose is to show that PowerBuilder can participate in modern, creative, intelligent, visually attractive, and highly integrated solutions.

Through these examples, I have explored ideas involving:

• Modern user interfaces.

• WebView2 integration.

• Artificial intelligence.

• REST APIs.

• Cloud services.

• Process automation.

• Advanced data visualization.

• Dynamic HTML content.

• External service consumption.

• Document processing.

• SQL analysis.

• Code analysis.

• Enterprise security.

• Hybrid application architectures.

• New approaches to PowerBuilder development.

Every example has reinforced the same conclusion:

PowerBuilder is not limited to the development patterns we used ten or twenty years ago.

Its real potential also depends on how willing we are to experiment, combine technologies, share knowledge, and rethink the way we design our solutions.

The more I explored, the more I realized that many perceived limitations were not always limitations of the platform.

Sometimes they were limitations in the way we imagined its use.

When a solid enterprise platform such as PowerBuilder is combined with modern services, web technologies, artificial intelligence, and the experience of the developer, the number of possible solutions grows dramatically.

This is why I now believe that our greatest limitation is not the tool.

Our greatest limitation is our imagination.

8. Real-World Scenarios Where AI Can Enhance PowerBuilder

The combination of PowerBuilder and artificial intelligence can create value in many areas.

Legacy Code Analysis

An application with more than twenty years of evolution may contain thousands of objects and scripts written by different developers.

AI can help explain methods, identify potential dependencies, detect duplicated patterns, and generate preliminary documentation.

This is especially valuable when the original developers are no longer part of the team.

AI-Assisted SQL Optimization

The SQL statement of a DataWindow can be sent to a model with specific instructions to identify:

• Unnecessary subqueries.

• Problematic joins.

• Functions applied to indexed columns.

• Repeated calculations.

• Possible filtering problems.

• Potential performance improvements.

The proposed query should never be applied automatically in production.

It must be evaluated using execution plans, realistic data volumes, functional tests, regression tests, and actual performance measurements.

Unit and Regression Test Generation

AI can analyze a PowerScript function and suggest:

• Normal test cases.

• Boundary conditions.

• Negative scenarios.

• Invalid input combinations.

• Exception scenarios.

• Regression cases.

A developer can use these proposals to create a testing library for critical functions.

Automatic Documentation

Using exported PowerBuilder source code, AI can help generate:

• Functional descriptions.

• Technical summaries.

• Flow diagrams.

• Dependency inventories.

• Explanations for new developers.

• Reports identifying possible risks.

• Object catalogs.

• Modernization recommendations.

Document Processing

Multimodal models can help interpret:

• Invoices.

• Purchase orders.

• Forms.

• Contracts.

• Receipts.

• Identification documents.

• Operational reports.

PowerBuilder can display the original document, receive the extracted information, present it in a DataWindow, and allow the user to validate it before saving it.

Internal Enterprise Assistants

An enterprise application can include a consultation panel where users ask questions in natural language.

The answer should not come exclusively from the language model.

The application can retrieve authorized information, build a controlled context, enforce access rules, and request that AI produce a clear explanation.

Complementary Interface Generation

AI can help create HTML prototypes, CSS styles, JavaScript components, SVG graphics, and visual dashboards that are later integrated into the WebBrowser control.

This makes it possible to accelerate the development of modern interfaces without transferring the entire application to another framework.

9. Risks We Should Not Ignore

Adopting artificial intelligence does not mean accepting its output without question.

AI models can produce incorrect answers, invent functions, omit important conditions, or generate code that appears valid but contains subtle errors.

In enterprise applications, we must also consider:

• Data privacy.

• Personal and confidential information.

• Intellectual property.

• Logging of submitted prompts.

• The location where information is processed.

• Access control.

• Auditing.

• Consumption costs.

• Service availability.

• Vendor dependency.

• Human validation.

• Decision traceability.

• Regulatory compliance.

• Model version changes.

• Security of API credentials.

Not all code and not all data should be sent to an external service.

Responsible integration requires clear definitions regarding:

• Which information AI may process.

• Which data must be anonymized.

• Which operations require human approval.

• Which responses must be logged.

• Which decisions must remain deterministic.

• What should happen when the AI service is unavailable.

It is also advisable to separate experimentation environments from production environments.

A prototype may demonstrate that an idea is technically possible.

Turning that prototype into an enterprise function requires testing, controls, metrics, monitoring, error handling, fallback mechanisms, auditing, and security reviews.

Artificial intelligence does not eliminate software engineering.

It makes good software engineering even more important.

10. The New Role of the PowerBuilder Developer

The arrival of artificial intelligence does not reduce the value of an experienced developer.

It transforms that value.

For many years, a large part of our work involved manually writing every line of code.

Today, we can dedicate more time to accurately defining the problem, reviewing architectures, validating results, designing better tests, and making stronger technical decisions.

Deep PowerBuilder knowledge remains essential because an AI tool may generate PowerScript, but it does not necessarily understand:

• The event lifecycle of a PowerBuilder window.

• The behavior of DataWindow buffers.

• The difference between ItemChanged and ItemFocusChanged.

• The implications of AcceptText.

• Correct SQLCA management.

• The DataWindow update process.

• The differences between TriggerEvent and PostEvent.

• The behavior of applications deployed with PowerServer.

• The dependencies between objects stored in different PBLs.

• The effects of dynamic modifications using Describe and Modify.

• The transactional consequences of a code change.

• The functional history behind a legacy implementation.

AI may become familiar with these topics through documentation and examples, but practical experience allows a developer to recognize when an answer is incomplete or unreliable.

The developer of the future will not necessarily be the person who writes the greatest number of code lines.

It will be the person who:

• Asks better questions.

• Provides better context.

• Validates results more rigorously.

• Understands the business more deeply.

• Designs safer architectures.

• Connects technologies more intelligently.

• Shares knowledge with the community.

11. A Practical Roadmap for Getting Started

The adoption of AI and modern components should not begin by attempting to transform the entire application.

It is better to select small, measurable, and low-risk use cases.

A practical roadmap could include the following stages.

Stage One: Developer Productivity

Use AI for:

• Documentation.

• Code explanation.

• Example generation.

• Test-case creation.

• SQL analysis.

• Technical summaries.

At this stage, no production functionality is modified directly.

Stage Two: Internal Development Tools

Create:

• SQL analyzers.

• Documentation generators.

• DataWindow review assistants.

• Dependency explorers.

• Code quality dashboards.

• Project metric reports.

Stage Three: Supervised Enterprise Functions

Integrate:

• Document extraction.

• Information classification.

• Summary generation.

• Text assistance.

• Data interpretation.

All results should remain subject to user validation.

Stage Four: Hybrid Architecture

Incorporate:

• Dashboards.

• Calendars.

• Diagrams.

• HTML editors.

• Maps.

• Specialized viewers.

• AI result panels.

PowerBuilder remains the process coordinator.

Stage Five: Enterprise Services

Expose selected functions through APIs or consume external services while establishing:

• Authentication.

• Authorization.

• Auditing.

• Monitoring.

• Error control.

• Secure credential management.

Stage Six: Controlled Automation

Allow AI to participate in more complex processes while maintaining deterministic rules for critical operations.

This progressive approach makes it possible to learn, measure results, and innovate without compromising application stability.

12. True Innovation Comes from Combination

For some time, I believed I had to choose between preserving my PowerBuilder experience and moving toward new technologies.

Today, I understand that this choice is unnecessary.

PowerBuilder represents decades of knowledge in rapid enterprise application development, transactional processing, reporting, and efficient data management.

Artificial intelligence provides new capabilities for interpretation, generation, summarization, analysis, and assistance.

HTML, CSS, and JavaScript provide visual flexibility.

REST services simplify integration.

WebView2 connects web experiences with native applications.

Cloud services provide new processing and connectivity capabilities.

Each element solves a different part of the problem.

Innovation does not mean replacing a solid tool simply because a newer alternative exists.

Innovation means designing an architecture where technologies collaborate effectively.

Final Reflection: Our Imagination Defines the Limit

After more than twenty years of working with PowerBuilder, one of the most important lessons I have learned is that professional evolution begins when we are willing to reconsider our own assumptions.

When I expanded my perspective and began exploring artificial intelligence, WebView2, REST services, modern web technologies, cloud integrations, and external tools, I did not move away from PowerBuilder.

I discovered new ways to make it more capable.

That openness changed the way I develop, experiment, and share knowledge.

It also motivated me to publish more than 21 code examples demonstrating what can be achieved when PowerBuilder is combined with the modern technology ecosystem.

Each example represents more than a technical exercise.

It represents an invitation to other developers to look beyond traditional boundaries and imagine new possibilities.

The purpose of these examples is not to claim that every application must use artificial intelligence or web technologies.

The purpose is to show that we have options.

We can preserve the proven enterprise foundation of our applications while improving their visual experience, connectivity, automation, intelligence, and ability to respond to new business requirements.

Artificial intelligence has helped accelerate that exploration, but the real transformation came from changing my mindset.

I no longer see new technologies as a threat to PowerBuilder.

I see them as opportunities to extend it.

I no longer believe that modernization requires abandoning everything we have built.

I believe it requires understanding its value and connecting it intelligently with the future.

PowerBuilder continues to provide a strong foundation for business logic, transactional processes, security, reporting, and data-intensive enterprise applications.

Modern technologies give us additional tools for expanding that foundation.

What we build from this combination depends on us.

The future of PowerBuilder will not be defined only by the features included in each new version.

It will also be defined by what its developers are capable of imagining, building, improving, and sharing with the community.

The future of our applications does not need to be built by destroying the past.

It can be built on top of it.

True evolution does not mean replacing everything we have created.

It means recognizing its value, modernizing it intelligently, and preparing it for the next twenty years.

PowerBuilder may provide the foundation.

Modern technologies may provide new possibilities.

But our only true limit is our imagination.

About the Author

Luis Avilan is a PowerBuilder developer with more than twenty years of experience designing, maintaining, optimizing, and modernizing enterprise applications.

His work focuses on combining the proven capabilities of PowerBuilder and DataWindow with modern technologies such as WebView2, REST services, cloud integrations, automation, and artificial intelligence.

Luis has published more than 21 practical code examples for the PowerBuilder community, demonstrating how developers can extend existing applications, explore hybrid architectures, improve the user experience, and create modern enterprise solutions without abandoning the value of their existing systems.