Welcome!

PowerBuilder Authors: Chris Pollach, Yeshim Deniz, Jayaram Krishnaswamy, Kevin Benedict, Avi Rosenthal

Related Topics: PowerBuilder

PowerBuilder: Article

Who Will Become the PowerBuilder of the Web 2.0 Set?

Web 2.0 environments are making the browser a full-fledged participant in enterprise computing
By Judith Hurwitz
Article Rating:
January 12, 2008 08:45 AM EST
Reads:
 15,975

Judith Hurwitz's Blog

Recently I have been having déjà vu back to the days of PowerSoft. If you are old enough to remember, PowerSoft was the leader in making graphical development practical for the masses — rather than the object oriented gurus. Back in the early 1990s when PowerSoft’s product PowerBuilder  was in its heyday, it had been able to achieve dominance over arch rival Gupta Technology and a myriad of other long forgotten competitors. Ironically, at the time, Gupta had a much more sophisticated object oriented environment than PowerBuilder. But PowerBuilder was able to achieve leadership because the company found a way to make the traditional COBOL developer (and there were lots of them) very successful as graphical software designers.

The secret was that while PowerBuilder professed to be an object oriented graphical development environment, it was actually a procedural environment that was familiar to the COBOL developer. Therefore, the skills that had made this generation of developers successful in an earlier generation provided the platform for a new career path in client/server development. Therefore, PowerBuilder took the market by storm and set the path for the early success of client/server computing.

Now, fast-forward to today and the advent of Web 2.0. We are seeing lots of interesting tools such as Nexaweb, JackBe, and Kapow. All these companies have a common strategy: they want to become the PowerBuilder of this new generation of application development environments. To create a rich, collaborative environment requires a level of sophistication that would prohibit less technical developers from participating. Therefore, just as PowerBuilder provided a way for the masses to create a graphical first generation environment, so this next generation of development tools will bring Web 2.0 to a broad audience. These web development environments provide the dynamic, stateful approach needed to create Web 2.0 environments.

I think that this movement towards Web 2.0 and these abstracted tools to support them will complete the picture of a service oriented architecture. The Web 2.0 environment is making the browser environment a full-fledged participant in enterprise computing. Over time, we’ll see lots of business people creating compelling business services in this way focused on innovative, collaborative software that provides a rich client environment that provides sophisticated communications, as well as a stateful distributed computing platform. This is not an easy feat but one that some innovative players are going to grab to become the PowerBuilder of the Web 2.0 set.

Published January 12, 2008 – Reads 15,975
Copyright © 2008 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.

More Stories By Judith Hurwitz

Judith S. Hurwitz is president and CEO of Hurwitz & Associates, LLC, a research and consulting firm focused on emerging technology including big data, cognitive computing, cloud computing, service management, software development, and security and governance. She is a technology strategist, consultant, thought leader and author. In 2015 Hurwitz coauthored Cognitive Computing and Big Data Analytics (Wiley, 2015). A pioneer in anticipating technology innovation and adoption, she has served as a trusted advisor to many industry leaders over the years. Judith has helped these companies make the transition to a new business model focused on the business value of emerging platforms. She was the founder of CycleBridge, a life sciences software consulting firm and Hurwitz Group, a research and consulting firm. She has worked in various corporations including Apollo Computer, and John Hancock. Judith has written extensively about all aspects of enterprise and distributed software. Judith is a co-author of six “For Dummies” books including Big Data for Dummies and Hybrid Cloud for Dummies. In 2011 she authored Smart or Lucky? How Technology Leaders Turn Chance into Success. (Jossey Bass, 2011).

Judith holds B.S. and M.S. degrees from Boston University. She serves on several advisory boards of emerging companies. She is on the board of directors of Boston University’s Alumni Council. She was named a distinguished alumnus at Boston University's College of Arts & Sciences in 2005. She is also a recipient of the 2005 Massachusetts Technology Leadership Council award.

Comments (5) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
Scan 02/14/08 02:26:25 PM EST

Her comments more closely resemble Visual Basic and not powerbuilder. Until the arrival of .Net, visual basic was the least object oriented GUI tool with tons of procedural code inside every function and event one can get hold of, as it did not even support basic feautures such as inheritance or encapsulation. It became popular because of the Microsoft tag that was attached to it. I am really surprised how the blog had completely ignored this fact. IF powerbuilder turned Cobol programmers into OOP programmers then Visual Basic turned non programmers into programmers.
SS 02/04/08 01:58:01 PM EST

I would like to echo the same sentiments as Bernard. Powerbuilder supported all the important characteristics of OOP more than many other graphical tool, but unlike Java did not force one to be object oriented . I have come across many apps written in PB that were extremely object oriented (due to the fact that these were written by developers well versed in OOP) and some poorly coded apps due to lack of OOP knowledge on the part of the developer. This goes to prove that there is nothing typically wrong with the product iteself. The mass appeal was due to the datawindow that made database manipulation much easier than any other tool and it still continues to be unrivalled.
HommeDeJava 01/25/08 12:21:15 PM EST

Google is definitely the Web 2.0 PowerHouse / PowerBuilder. They are creating all the Web 2.0 Open Source Frameworks to be able to build easily all the great applications following the idea of Web 2.0 application patterns.

GWT, Android, Google Gears, AJAX Feed API, OpenSocial, YouTube API, Gooogle Maps
Bernard Dy 01/24/08 02:55:39 PM EST

"...while PowerBuilder professed to be an object oriented graphical development environment, it was actually a procedural environment..."

The PowerBuilder I know supported true OO before Java existed; however, it also allowed programmers to use as much procedural logic as they wanted, whereas Java and .Net languages are better at forcing object use (but are hardly immune by any stretch to procedural code bloat).

But I understand your point. Because so many developers during the PowerBuilder halcyon days did not have proper training in OO concepts and techniques, PowerBuilder apps by design (or lack thereof) tend to be non-OO piles of COBOL-like scripts. This is, however, more a reflection of the practitioner's skills than of the tool (and I would know - I wrote some bad PB code in the earlier years).

Mr. Armstrong is correct: PowerBuilder is to C++ what things like Dreamweaver are to HTML. For better or worse, that's probably what made PowerBuilder successful in the 90's.
Bruce Armstrong 01/24/08 12:36:27 PM EST

Not sure about the COBOL part. I have known and continue to know a vast number of PowerBuilder developers. Few of them have any experience with COBOL. I certainly didn't. The few COBOL folks I did know did not find the tool familiar to work with.

PowerBuilder abstracts the developer from low level implementation details. To that end, it makes it easier for anyone who doesn't want to deal with such details to do development. That's probably more in line with the point you're trying to make.