Skip to Content
Author's profile photo Former Member

Perspectives on ABAP/Objects

Herewith, I want to answer to the quite dedicated weblog from Horst Keller where he replied to my recent weblog The Future is OO – Travel Back to the Past? with the somewhat rhetorical question Did ABAP Objects Fail as a Whole?. First, I want to strongly agree with the comment from Sebastian Rehbach on Horst Keller’s weblog. Sebastian titled his comment with “Sometimes ABAP Objects acts like the Cobol OO extensions” which indicates the tonus of his opinions expressed as an agenda of ten points. With Sebastian’s statements I agree in general, so I won’t repeat them here.
To make it clear from the beginning: It’s completely understandable to me that Horst Keller wrote a weblog like he did. And I agree with almost any of his statements. And I am a friend of object-oriented development. Nevertheless matters are more complicated.

Weblogs and Print Media

If writing a weblog, it sometimes is a good idea being sort of provocative. Evidently, this stimulates other people responding more extensively. Consider the opinions expressed in my The Future is OO – Travel Back to the Past? as being my opinions. They may seem provocative to some people. But these were/are my opinions written without being too diplomatic. A weblog should be the right medium for doing so. Regard that a weblog allows a dynamic exchange of statements and opinions. This is not the case for articles published in print media like in the Objektspektrum. Articles in print media should be quite compact and in many cases not that lengthy (as the editorial staff tells you). As an author you don’t have the chance of replying to criticism, in contrast to a weblog. Furthermore, a printed magazine claims to be more formal than a weblog. It would not be a good idea using too many picturesque metapherns and sloppy terms in print media. For weblogs this should be totally alright and makes the article perhaps more refreshing. The Objektspektrum article concentrated on displaying some facts about ABAP/Objects. As it is a non-SAP-magazine with readers not familiar with SAP infrastructure at all, there was the need of outlining the subject and not going into detail as possible in my weblog.

Take this as an answer to the fact that Horst Keller “was completely puzzled” that my weblog article seemed to contradict my Objektspektrum publication. Respect that there are different perspectives one can write about a subject. One perspective is the evaluation of a technology for itself. Another one is the evaluation of a technology being embedded into a huge system and landscape.

Points of View

What did I mean with “ABAP/Objects failed as a whole”? Allow me to cut it short: One aspect is the technological beauty and capability of a language. Another point, being quite independent of the first one, is the place a language takes in in a specific system resp. system architecture. And the latter is the kasus knaxus with ABAP/Objects. There is – for sure – no disagreement with what I wrote in my article in Objektspektrum 03/2004. In the article I explained the constraints which SAP had to take into account when implementing ABAP/Objects and embedding it into the traditional SAP infrastructure. You cannot embed a language as you want if there is a given architecture. SAP made no really big mistakes, I would say. Polishing up a legacy system containing an extremely huge internal and customer code base with a new paradigma often fails. As I expressed my opinion, almost none of our big SAP customers (big companies, millions of lines of legacy code of ABAP, mostly people being more specialists in their subject than developers) uses ABAP/Objects significantly. The reasons are numerous. One is given just above. Second, it is questionable whether an OO language is the right fit for a business logic oriented system already providing basic infrastructure, powerful-framework-like architecture and many tools available at the hands of the users and developers.

Another reason, IMHO, is the difficulty of REALLY learning what OO is all about. With this strong experience being evident to me, I wondered about the comment having made on the weblog of Horst Keller by Igor Barbaric. Please don’t misunderstand me: Igor’s comment is totally OK with me. I just wondered how he managed to do as he described (set up a project with ABAP/Objects and greatly exceed the success of prior ABAP projects, beginning from scratch with OO and ABAP/Objects). I don’t know about the basic conditions of Igor’s projects. It is good to know that there are companies allowing their employees to do freely what they want without being sure whether and when and with which costs the new paradigma chosen will lead to success. Additionally, I would be keen on knowing details about the project and the company: Is it a big project? How big was the legacy code base? It is a big company? IMHO, SAP systems were mostly designed for enterprises not for smaller companies. Nowadays this has changed somewhat.

Promised Answer

Just a detail, but I promised to clarify a statement about ABAP/Objects repeated by Horst Keller that marks “symbols already occupied by ABAP” as a limitation of ABAP/Objects. Well, as the point character already is in use by ABAP as end of line marker, you cannot use it for ABAP/Objects. So there is the need to press the keys to produce the string -> for dereferencing. This is just a small detail (as the clumsy calling of a message), but in my eyes essential. Reasons: You have to use it frequently and in addition with concepts like function calls it makes ABAP/Objects dowdy, IMHO.

Being Provocative (Again)

Allow me some sarcasm but take it not too seriously (we all want to be friendly here): When the time has come for SAP users gotten used to ABAP/Objects, I see it most probable that Java will have displaced ABAP/Objects. As a realistic vision one could add that SAP then could have managed to allow the random integration of ABAP code into Java source. That meant one of the top points on the agenda of SAP would have been realized.
Today you can find statements like “Use ABAP or Java as you want, it’s your choice”. As we all know this is completely nonsense. But in the future, the age of the robots (greetings to Will Smith), the age of Genetic Engineering, this should become possible. As Moore’s Law concludes (for chip technology) technical development advances exponentially. Read Ray Kurzweil’s book “The Age of Spiritual Machines” to know that this applies for almost any aspect in computation (I’m sure Mark Finnern knows his books, because I found links to similar resources on one of the sites coping with future he is involved with).


As weblogs at SDN indicate there are several legitimate opinions about ABAP/Objects. Everyone has to find out for himself which place ABAP/Objects will have in his life. Let me remark that I find some statements of SAP somewhat distressed. In the online help (also for version 6.40) you can find an argument in favor of ABAP/Objects reading like “If you want to implement a counter needed several times, you now can easily do this with ABAP/Objects. With Function Modules it was a pain.”. Additionally, it is stated that ABAP/Objects embraces the extended categorization of business logic in contrast to function modules and groups.

SAP knows of the improvements necessary to make ABAP/Objects a language of preference. Let’s wait and see how development progresses. My assumption is that there are not enough developers available on behalf of SAP for improving the ABAP/Objects concept substantially as there is much work to do to advance NetWeaver.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      Your weblog seems to me more to question the ability of generalised OO to penetrate developers' mindset, than specifically ABAP Objects.  Even if ABAP were to disappear (yeah, right) this same group of developers who grew up with procedural ABAP would be faced with the same problem when moving to replacement languages such as Java.

      As for the future development of ABAP Objects, you only need to see the presentation on ABAP changes in 6.40 to see that SAP have not stood still in this area.  There are thousands of developers within SAP that are heavily developing with ABAP Objects and for this reason alone the technology must be advanced by SAP as necessary.

      Finally, sure it would be nice to write syntax like Account.Create(), but the '=>' or '->' alternative is really not that big a deal IMO.  Myself I would rather see support for syntax like "Account=>Create( )->AccountNumber".


      Author's profile photo Former Member
      Former Member
      Blog Post Author
      Hello Scott,

      to some extend I agree with you. ABAP/Objects for itself is not the problem, as I outlined in my weblogs. It is the fact that ABAP/Objects is the implementation of the OO paradigam within a legacy system driven by procedural forces. The question is whether this is senseful at all in common or whether there are just small areas of applicability.

      With Java, problems would be the same as with ABAP/Objects, if Java (or any other language) was the replacement for ABAP/Objects, no disagreement between us.
      Concretely, Java - as it is kind of foundation of the WebAS for Java - offers the ability to externally communicate with the legacy SAP system (by using WebAS for Java). So, this approach is completely different compared to the integrated concept mentioned before.



      Author's profile photo Former Member
      Former Member
      A few random thoughts:

      I came from the accounting world and learned how to write ABAP programs. I have read a lot of literature on good programming techniques, modularization etc. and tried to do good work for my clients. But I am by no means a programmer in the "computer science" sense.

      I purchased the book ABAP Objects and have read most of it. It is helpful for understanding OOP but I must confess that I still don't see the value of objects for business oriented programming. The examples in the book seem trivial and unrelated to my work.

      I feel that objects demands a technical discipline that is unnecessary and costly. One of the great virtues of ABAP is its accessibility to functional analysts who understood the business requirements. They do not need a long and detailed spec to develop a solution. They can prototype on the fly. In fact as their skills improve they can do some very decent modularization and structural programming. For very specific applications they are quick and very productive.

      However, their solutions are usually specific to the enterprise they developed them for. I can understand that back in the center of SAP development, this kind of programming is not well appreciated.

      I doubt that these programmers will ever adopt objects. Certainly they will use the methods delivered by SAP much as the used the function modules in the past, but I cannot see them investing the time and effort to create new objects (at least with any real rigor). Because the enterprises they work for are in business to make widgets not programs they will not support the hiring and development of object oriented programmers who certainly are a special breed. They will also not support the extended up-front development costs for objects.

      I think I understand why objects may be necessary for SAP. They are in the business to write programs and if this helps them do a better job of creating and supporting solutions that fit thousands of clients then it must be a good thing. But I think that there is a need to understand that SAP and its partners develop in a significantly different way than its customers do.

      There are risks in widening the gap between these two levels of programming effort. We can only hope that the power to develop and extend solutions is not permanently impaired as its technology becomes ever more specialized and diverse.

      May I also note that SAP's product offering frequently are understandable and configuratioon choices casn be made because an analyst understands the underlying ABAP code that is being executed. He can make intelligent decisions abouit implementation because of this knowledge. Object oriented techniques and abstractions frequently obscure this understanding as code is inspected and debugged. This can increase the cost and decrease the effectiveness of the configued solution. One can argue that this can be resolved with better documentation but after ten years this isn't much improved.

      Author's profile photo Former Member
      Former Member
      Blog Post Author
      There is a very interesting opinion about OO in general, posted on 2004-10-25:

      The paragraph I find stimulating reads as follows:

      "One of those experts, Dave Thomas once stated that 70% of programmers would never be able to work in more than one programming paradigm and that 90% would never master more than 2. If this is anywhere close to being true, it is no wonder that COBOL programmers and others that have moved from the procedural world have trouble with the abstraction that OO supports. It is also no wonder that those charged with educating the next generations of programmers have difficulty doing so."