A 4GL future? - fourth-generation languages for creating enterprise applications - Technology Information - Column

Nowhere in the computing milieu is failure more vis- ible than in corporations' inability to build industrial-strength enterprise applications in a cost-effective manner. Many MIS organizations are stepping back-ward, rather than forward, in their search for the key to enterprise application development. v While hardware costs continue to drop dramatically, software development and maintenance costs continue to rise. And the failure rate for software development projects is climbing right along with the cost.

Why is this so? Why is there such confusion regarding which tools are best for building and maintaining client/server applications? Why are MIS organizations having a training crisis with their Cobol programmers? And why, after almost 40 years developing corporate applications, are MIS organizations being told they should go back to the drawing board and radically change their approach to enterprise application development?

Corporations today are finding that the hardware costs for running client/server enterprise applications are substantially lower than mainframe costs, but that the complexity involved in building and maintaining them makes them more costly.

Most industry professionals would agree that Cobol was a great advance over Assembly language programming. And most will say they were able to build transaction-oriented online and batch appli-cations and industrial-strength enterprise applications on mainframes. A subset will even agree that the 4GLs of the '80s were a significant advance over Cobol.

But that's where the agreements end. Today, pundits are suggesting all kinds of remedies, ranging from C, C++ or Smalltalk as the language of choice, to object-oriented programming as the programming paradigm. Consulting firms are pushing corporations to reengineer all their data processing applications, and recommending that MIS applications and responsibilities be pushed down to end-user departments. Outsourcing firms are trying to convince CEOs and CFOs that they have the expertise to build applications faster, cheaper and better than internal IS can.

What a sham. Yes, business is great for consultants and programmers with specialized language skills like C++. But are corporations better off than they were in the past? Many, in fact, are much worse off and uncertain as to their direction.

However, the corporations embracing the latest 4GLs are right on target. These corporations don't face a training crisis because MIS Cobol personnel can adapt to these higher-level languages with a week or less of training.

So why isn't everyone choosing 4GLs for enterprise development? One reason is that the most effective enterprise 4GLs don't come from the dominant software and hardware companies. And 4GLs have had their problems. Many run interpretively and are inefficient at execution time. Some may be tied to a particular DBMS or operating system. Publicity may be another factor: Consulting firms may hesitate to recommend 4GLs for in-house development because their skills won't be needed.

Today's new "enterprise 4GLs" should be able to answer many of these criticisms. These 4GLs provide:

DBMS, OS and TP independence. Applications can be written independently of the underlying DBMS, operating system or transaction processing monitor. Users can mix and match their network client/server applications in an open system environment. No special programmer coding is required -- the 4GL hides all the complexities of the disparate databases, OSs and TP monitors.

Automatic dynamic partitioning of logic. To ensure both flexibility and performance, enterprise 4GLs can dynamically shift the application logic between client and server during development and at execution.

High-level, easy-to-learn languages. Co-bol and other programmers can learn to use these new 4GLs in a matter of days, unlike object-oriented programming, which requires months of training. Many 4GLs do not require the programmer to learn a new paradigm.

Efficient execution speed. These new 4GLs are not interpretive and compile efficient code as well as, or better than, Cobol compilers.

Fast prototyping. Programmers can build application prototypes quickly and then use them as the foundation of the final system. Major applications can be built in months, rather than years.

Despite these benefits, 4GLs have to contend with inertia. However, their acceptance in corporate settings should start to accelerate as object-oriented programming proves to be more confusing than beneficial, and, further, as programming in C, Smalltalk and Cobol begins to drop off.

Martin Goetz is president of Goetz Associates, Teaneck, N.J.

COPYRIGHT 1996 Wiesner Publications, Inc.
COPYRIGHT 2004 Gale Group