Skip to main content

ABL in a Pacific World

Printer-friendly version
With a SaaS ERP package, for example, one can analyze the capabilities and features of the ERP software separately from the subscription licensing or cloud delivery, even though the licensing and delivery will clearly be important in the final product selection. Thus, to evaluate Rollbase as a product in relationship to ABL, we need to consider Rollbase as a tool separate from the delivery or licensing. This is not to suggest that the delivery or licensing are in any way unimportant, but, rather, that delivery and licensing are properties which are somewhat independent of the tool itself. Thus, while Rollbase is presented as itself a Platform as a Service, specifically a tool on an infrastructure which allows very rapid development and deployment of browser-based applications, we can consider the Rollbase tool separate from the infrastructure which is used to deliver it. Indeed, that infrastructure might well be used to deliver other tools.

Based on presentations and a workshop at the 2013 Exchange conference, my bottom line impression of the Rollbase tool is that it is a nice way to quickly develop and deliver web-based applications, if those applications are basically CRUD3 applications. Yes, one can include logic via JavaScript, but that is putting business logic in the client, which is not consistent with modern design practice, i.e., OERA. With the continued development of integration with Corticon and OE BPM, it will be possible to add more complex processes and rule evaluation to those CRUD operations, but this is still a long distance from the kind of complex business logic which characterizes “enterprise class business applications”, Progress’ stated market.

To be sure, even an ERP application has components with limited business logic, so that one could be able to supply much of the application with Rollbase, but for any core functionality, one is going to require a connection to server-side complex logic outside the scope of Rollbase and for which ABL is ideal.

In discussions I have had over the years with people who were unfamiliar with OpenEdge, some have dismissed all 4GLs and related tools as “mere” RAD (rapid application development) tools. By this they refer to any one of a variety of tools to allow the very rapid development of CRUD applications, i.e., where the “application” is little more than a conduit between the user and the database. The sophistication of thousands of ABL applications makes it clear that this is not a fair characterization of ABL, but it is certainly more correct as a description of Rollbase.

Yes, the infrastructure makes it special. Yes, there are provisions for providing additional logic, but if that logic becomes substantial and complex, then not only is one putting the logic on the wrong end of the client-server connection, but one is developing that logic in JavaScript, which is not rapid and productive. Yes, one can connect the Rollbase application to Corticon and OE BPM to provide some types of business logic, but in no way do BRM4 and BPM5 provide complete coverage of the kind of logic required by a typical ABL application. And, yes, one can connect a Rollbase application to ABL logic in the AppServer, but then one is also not solving the whole problem in Rollbase.

Thus, one can imagine Rollbase and ABL interacting in different ways in the future. In some cases a customer or ISV will have an existing ABL application suite and have a need for a new, browser-based application with limited business logic. Thus, they might use Rollbase to create that application and interface it primarily at the database level with the rest of their applications, possibly providing any needed business logic without the use of ABL. In other cases, such an application might start out appearing to be fairly simple, but as it grew one discovered a need for more sophisticated logic. This could lead to interfacing the Rollbase application with an ABL application via the AppServer. Or, one might have an existing ABL application which needed a web aspect that it did not currently have and use Rollbase through the AppServer to provide that new interface on an existing application. In some cases, a customer might start with an independent Rollbase application and move to adding an ABL back end to address growing complexity of business logic, but this seems less likely.

ABLinaPacificWorld.pdf68.95 KB