Skip to main content

ABL in a Pacific World

Printer-friendly version

Where is the future of ABL?

It is useful to briefly consider the history of ABL in order to look at its future. Back in the 1980s, one of the key distinguishing characteristics of ABL when compared to competing 4GLs was that it was possible to write all of most applications in ABL. With the other 4GLs, one typically had to write 5 to 15% of the application in some 3GL such as C. Worst yet, the parts where one had to resort to C were the hard parts of the application so that one gained productivity in the easy part, but gained nothing in the hard part. Using the usual 80/20 type rule, this meant that, for example, a 4X boost in productivity applied to 80% of the code, but that code normally took only 20% of the development time, thus, there would be only a 15% boost in overall productivity because 20% of the code was still taking the full 80% of the time that it would without a 4GL. E.g., given an application which took 1000 hours to develop in a 3GL, the 80% of the code suitable for a normal 4GL, but which only took 200 of those hours, might be done in 50 hours. But, the remaining 20% or 800 hours would still take 800 hours, so the total improvement would be 850 hours versus the original 1000.

Being able to develop 100% of the application in ABL meant that the productivity gain was experienced throughout. I.e., the 1000 hour application could now be done in 250 hours or less. In many cases, the gain with ABL was greater.

Those gains were, of course, on simpler applications than we are dealing with today. Between then and now, the sheer growth in keywords in ABL is staggering. Parts of the ABL have become less 4GLish in response to a need for greater power and control. For example, there is no question that dynamic queries add enormous power to the language, but they also produce code which is less easy to read and more complex to write than the old static methods. While I know of no studies, it seems likely that this has resulted in a more modest productivity advantage for modern ABL over other languages, especially since competing 3GL languages have also acquired some higher level features.

In addition, there has been at least a potential migration of part of the solution out of ABL. One of the more common expressions of this is for the UI. With the advent of browser-based interfaces and OpenClient Java and .NET clients and most recently with OE Mobile it is not uncommon in a modern ABL application for some or even all of the UI to not be written in ABL. According to OERA principles, one should not find this disturbing since the UI proper should be a thin layer which can easily be swapped from one technology to another without disturbing the core system. Similarly, in good OO design, one recognizes a division of an application into highly discrete subsystems or domains and allows for the possibility that particular subsystems may use different technology than the rest of the system. One common example of this separation is that even strongly model oriented developers will not use models for the UI since visual designers are so much more productive for creating a UI.

In more recent years we have seen the introduction of other “foreign” technology subsystems in the form of BPM and BRM systems. In each case, a certain part of the business logic is removed from the ABL code and entrusted to the new domain, not for the sake of reducing the ABL code, but because rules and processes are more easily managed in an environment where they can be modified by visual tools without the need for programming changes.

Thus, we have gone from a historical context where the unique feature of ABL was being able to write 100% of the application within the same language to a context in which best practice indicates that we should partition the solution into multiple subsystems or domains and some of those subsystems will not be ABL. This is not a diminution of the importance of ABL, but rather an indication that modern systems are more complex than ones 20 and 30 years ago and this complexity is best addressed by using multiple tools in combination.

Therefore, in the context of Pacific, where one has the OpenEdge database, ABL, Rollbase, Corticon, OE BPM, and Data Direct Cloud all available as a part of a solution, ABL still has a major rôle to play in any enterprise class business application as the tool by which the core, complex business logic is performed. Rules will be in Corticon; Processes in OE BPM, the web presence possibly in Rollbase, other UI in various visual designers, connectivity to external data via Data Direct Cloud, but everything else is in ABL.

AttachmentSize
ABLinaPacificWorld.pdf68.95 KB