Going Modern

PowerBuilder has been around and successful for almost two decades now and after many discussions with PowerBuilder developers, it has become apparent to me what the marquee feature of PowerBuilder really is.  Some developers would comment on the ease of report creation, and others on the presence of client-side processing capabilities, but most only wanted to talk about their beloved Data Window.  After taking a look at what makes the DataWindow tick, it is truly the power of the DataWindow that makes developers’ lives easy.

Over the last 18 months, I’ve gotten to work with a variety of PowerBuilder versions, and had first-hand experience with the Data Window. When you look at it, it is a fantastic piece of tech.  For those of you who don’t understand the concept and what it does, let me try to explain.  The DataWindow is a group of user interface elements that can easily be tied to the database using the PowerBuilder IDE.  What makes the DataWindow so sticky is that once the interface has been defined and the SQL statements have been written, the two-way data connection can be made. Two way data means that if the data is updated on the UI and saved by the user it will be persisted to the database, and if the data changes on the database, upon refresh of the UI that data will be sent back. Developers love this because it is a minimal amount of code to begin developing screens that map to their business requirements quickly. This allows them to focus on the solving the business problem at hand because they do not have to worry about application infrastructure.

Unfortunately, there are number of architectural elements of PowerBuilder that severely limit its ability continue to be a viable option for continued IT support. Most prominently is its lack of support for a rich web environment that can recreate the performance, client side processing capabilities, and UI widgets that are considered standard in today’s Web 2.0 frameworks and delivered in a centrally managed, no-install medium. Also, finding resources to maintain and enhance PowerBuilder are severely hindering the IT department’s ability to continue support these applications as they age. The customers I’m working with are in need of a solution for the deployment issues, legacy language/skillset issues, diminishing support for PowerBuilder, and the need to move to a more open codebase like Java.

To help these customers, we’ve built Java technology that should be an easy transition for current PowerBuilder developers and Java developers interested in building a Java web app that gives that “Desktop Application in a Browser” feeling. In addition to building technology that can meet or exceed the client side capabilities of a PowerBuilder application in the web, Nexaweb has developed a semi-automated process that can quickly cut the process of moving from PowerBuilder to J2EE with greater functionality, flexibility and maintainability.

Modernizing to J2EE from PowerBuilder will be our focus in a demo today (Wednesday, February 17 at 2 p.m. EST) during our webinar with Sierra Atlantic.  I would definitely recommend checking it out.  You can register here: https://www1.gotomeeting.com/register/798601449.

The current state of affairs has most organizations asking IT to build business cases for new expenditures, especially when it comes to updating an application that isn’t necessarily broken.  For IT, broken tends to mean that an application is getting harder to find resources to keep it current, maintenance is time consuming, and the technology it’s built on can’t support the features the business is asking for.  For the business, it’s about revenue.  If an application gives them what they need, let’s them do their job, it works.  However, if they feel the application is holding them back and keeping them from realizing the most revenue possible, it gets top modernization priority. For example several of our most recent banking customers want to leverage existing back office systems (e.g. pricing engines) to extend their global trading systems to external traders, partners and banking customers. This drives significant revenue by dramitically increasing transaction volume and customer satisfaction through eCommerce.

When a decision is made to modernize, the discussion always get political.  Some folks are in favor of building their own application to ensure it serves their business, while others feel the cost savings of going with a Commercial Off-the-shelf Software (COTS) solution is a no brainer.  The build vs. buy dilemma is as old and stubborn as PowerBuilder, Visual Basic and C++ themselves.  Neither approach is wrong, but all have their drawbacks.  Modernizing an application using in-house resources ensures that specific features and functionality will be included, but not without a cost.  A COTS solution can dramatically reduce the costs, but tends to require a trade off of features and functions leaving the business without any real advantage or edge.   So, what’s the answer?  That’s a million dollar question, and a puzzle more and more organizations are having to solve.  How are you approaching modernization at your organization?  Is revenue driving final decisions?  What are your thoughts on the build vs. buy question?

Chris Heidelberger, CEO, Nexaweb

A large percentage of outsourced, onshore and offshore resources, are skilled in XML, Java and other Internet-based languages and development techniques, meaning their ability to tinker with and add features to 3GL/4GL applications is limited at best and that cost savings of such as model is neutralized. Adding to the conversation is the acknowledgment that more than 200 million lines of COBOL code are currently in use while another five million are being written each year. This presents a challenge given the waning number of students studying computer science and the shrinking number of experts in legacy applications.

According to Gartner, “interviews conducted with IT sourcing managers across the Gartner client base hint at what’s to come: Many have seen price hikes of 10% to 15% in certain skills during the past year.” (more…)

Legacy applications have architectural limitations that prohibit their ability to support large scale deployments. They often necessitate servers and technicians at each location with continuous client software maintenance and service, all creating redundant headcounts, resources and costs.

Application modernization toward an open, web architecture can address these technology limitations as they relate to the demands of globalization and will create new opportunities in terms of people and delivery. First, regarding the architectural limitations of legacy technologies, modernization toward an open, web architecture supports centralized deployments and zero-client installation which significantly lessens the need for local technicians, eliminates client software maintenance needs, and supports a reduction in hardware and infrastructure –consequently lessening energy requirements. From a pure software development perspective, adopting a loosely coupled architectural Web approach can reduce the time to execute a change request by 90 percent.

Secondly, modernization with Internet-based technology creates new methods of delivery and new ways to carve the resources pie. In terms of people, transformation toward an open, standardized application platform allows better utilization of a global workforce, especially from countries such as China and India. In terms of delivery, the lack of skilled IT resources against the demand will drive innovation and investment in new delivery models such as SaaS, IT process automation, and Internet-based service offerings that lessen reliance on human resources to resolve issues that can be solved in other ways.