Why ABAP is still the best platform for enterprise applications
The ABAP platform provides a centralised model of development that solves several of the challenges of mainstream business software development practices.
Some years ago (just over 10, to be exact) I wrote a post on this blog entitled “Why I like ABAP“. A lot has changed in the meantime, but I believe ABAP still remains an unbeatable and powerful platform for creating business applications; perhaps the best there is. Here’s why:
The Local Development Model
Over the years I have had the opportunity to observe, from working on several projects where other systems have been commissioned from the ground, some to integrate with SAP, alternative models of enterprise development. This has given me insight into other development practices that very different from those followed on SAP implementations.
The most noteworthy thing I have observed about how modern-day business applications are developed, is that the process for building and deploying software is incredibly complex.
In a very typical scenario, every developer runs a local installation of the application server. The application source is replicated from a central versioning repository. This means they have to satisfy all the dependencies; all the needed libraries need to be installed locally on their machines.
Now the developers code. They develop, make changes, compile and test them locally, then commit their source changes which are synced back into the repository. From here it is deployed to a QA system and finally to Production. To support the process, the environment includes so-called “continuous integration” tools which automate the process of compiling and, to some extent, deploying the software.
An Integrated Development Environment
I have recently been delving into Smalltalk; something I have been putting off for years but enjoying it immensely now that I am finally into it. Classical Smalltalk is not just a language; it’s a running environment with a GUI and a full-blown development environment baked in. The Smalltalk paradigm is very different to typical software development. As you code, you are in fact modifying a running environment.
Conceptually, this has some similarity to an ABAP application server. There, the development environment is just another suite of applications running on the server that you are able to access the same way as any of the other applications it hosts. It gives a totally different (though not new) meaning to the concept of “Integrated Development Environment”. What we typically understand an Integrated Development Environment to be is an editor, compiler/interpreter, debugger and possibly other tools, all rolled into a single application, hence being “integrated”.
But in the case of an ABAP application server, the development environment, together with all the supporting applications like a debugger, testing tools, software logistics, etc. is part of the application server. That makes it truly integrated, in the same way the Smalltalk development environment is part of its running system.
As in the Smalltalk environment, as you write programs in ABAP, you are changing the runtime environment by adding to it.
ABAP’s Central Development Model
I cannot overstate the immense gain in productivity that results from having the development being part of the running system which is, moreover, centrally hosted and multi-user. It truly makes me wonder why this is not the way that all enterprise software is developed.
Presumably, the centrally hosted paradigm has been inherited from mainframe systems; I have never worked on a mainframe system, but ABAP has a history dating back to the late seventies and has effectively inherited many concepts from the mainframe era.
Contrast this with how enterprise software is generally developed today, in the local development model, where the development environment is strictly separated from the environment that hosts the developed applications.
In order to support this model, you have to make use of continuous integration tools and deal with conflicts in sources. The centralised development model, as exemplified by ABAP, eliminates all of this; as you change the environment, the system is able to immediately compile against other objects in the environment, ensuring nothing breaks. It can do this because all dependent objects are present in the same system. Furthermore, because source units are locked by the user working on them, you never have source code conflicts. (ABAP has built-in versioning, just by the way).
While I imagine that the central development model is not applicable for every case, for example if you are developing desktop applications or an OS kernel, it certainly seems to be the way to go for server-hosted enterprise apps.
Conclusion
Newcomers to ABAP are often dumbfounded by the seeming antiquated language. It is easy to overlook, therefore, that ABAP is not merely a language or even a system, but an entire platform. One of the big strengths of the ABAP platform, as far as its capability to develop enterprise software is concerned, is the central development model.
Add to that all the enterprise features such as transaction control, sophisticated introspective capabilities (you can see, in detail, what is happening inside the system at any point in time), extremely fine-grained user access control, along with a host of other basis tools, it adds up to a formidable enterprise development platform with extremely high productivity.
There is to my knowledge, currently no other platform that provides such comprehensive functionality and such a high level of integration where you develop directly on the target application server with all the tools and dependencies already present. I often wonder what it would take to try and emulate the ABAP architecture in another language environment and how long it will take for someone else to adopt its model.
Leave a Reply