Skip to Content

ABAP Trilemma

During any ABAP development project there will always be architectural constraints that a developer needs to relate to. It is my experience that performance, security and design are constraints that cannot be changed without affecting the others. A trilemma.

The triangle can be used as an agreement between developers on how to prioritize development efforts. The model is very simple and is easily comprehended and memorized by development team members. Hence, the triangle can be used as a guideline by ABAP development teams.

This blog is aimed at architects, development leads, project managers and ABAP developers in general. The ABAP development triangle is an offspring of multiple customer ABAP projects. The idea of the ABAP development triangle originates from the Project Management Triangle.

Overview – ABAP Development Triangle

The ABAP development triangle has three corners; Performance, Security, and Design. The constraints are straight forward. Performance refers to ABAP performance optimized code. Security is not about the wider security aspects of a SAP system. It is mainly related to secure ABAP programming. Design refers mainly to the proper use of ABAP Objects. The red dot represents what developers in a project have agreed on to prioritize when coding ABAP.

In theory the trilemma seems to be a no brainer. Security first, performance second, design third! However, in practice, it is not that clear. Honestly, do you always write specific code to secure your programs? Ok, you did write some secure code, but was it the first thing you considered before starting writing the code? Did you run a performance test to benchmark your nice object-oriented code to old fashioned ABAP code? If you answered NO to any of these questions, then the triangle might help you focus on getting your priorities straight.

Lets have a look at two differing scenarios.

Scenario 1 – Large Volume Data Processing

For large volume data processing, performance is key. The above mentioned triangle depicts this through placing the red dot closest to Perfomance, closer to Security and furthest away from Design. It is not that Design does not matter in large volume data processing, but obviously the design is less important than swift code. For example, instead of using collections of objects, the developer might use internal tables with structures. As large volume data processing often is related to databases the Security part might be reduced to ensuring that all tables are assigned to authorization groups and that data can not be manipulated in the productive environment. Another Security measurement could be to prevent unauthorized persons from running the code in a productive environment and closing other loopholes, such as for example test reports.

Scenario 2 – Web UI development

This scenario is about Web based ABAP development. Security is very important for Web applications as they often contain backdoors to the underlying information system. Following the Secure User Interfaces documentation should therefore precede the two other aspects. In the Web Dynpro ABAP (WDA) framework, performance and design go hand-in-hand. Focus can therefore be placed on finding a nice design and using the checklist for high-performance WDA at the same time.

You must be Logged on to comment or reply to a post.
  • There are so many things that go into writing / Designing ABAP code.  So many decisions to be made.  These three areas are a big concern.

    1.  Performance - ALL code on our system should be tuned to the nth level.  Why?  Because even the smallest program can cause issues if it is ran often enough.  So I personally would not put performance on my triangle.  I suppose if you had a large data load performance would be a discussion point with timing.  But never as an ABAP code tuning reason.
    2.  I think it depends on what is important to the project as to your discussion points.  The triangle may be something to keep in mind.  But design covers a large area, and it should again be something that is ALWAYS your top concern.  Why?  If your design is not good everything else will fail. (Performance and security rely on a good design.)
    3.  Security - I believe is part of the design process.  It is always nice to have an expert in security instead of the ABAP developer thinking about security.  Yes, I agree it is part of our jobs to raise issues around security, and to know how our code could breach the system.  BUT the security officer would know more than I about some / most security issues.  Yes, it is an important thing to think about.
    4.  So my triangle would look more like a ladder.  Design at the top, Performance, Security - Switched to Security, Design, performance if there is not a security expert.
    5.  The sub components of design would be many things.  Future support, current skill set, end users familiar with SAP, and the list goes on...  Sometimes it becomes an 80/20 rule.  Because support should always be a concern.

    Just my thoughts / debate,


    • Hi Michelle,

      great comment and thoughts. In a perfect development world I believe you are absolutely right - everthing comes down to nice design. Unfortunately, it is not my real-life experience. Sometimes great design (and that is a difficult thing to define) does not always go hand-in-hand with performance and security. I have been in countless meetings where nice object-oriented design was set aside to optimize performance.

      I would like to make the analogy to the project management triangle where the corners are cost, time, quality. In an ideal world quality implies less time and lower costs. However, in real-life these are too a trilemma.


      • Light bulb going off! 

        I have seen the same thing happen, and I didn't even think about it.  OOP is the black sheep over here.  It is often set aside for performance reasons.  And so your triangle now makes sense to me.  I say if we have a security person on the project - and so that would influence security.  Performance, it depends on the end result.  Design influenced by both of these factors.

        OOP is set aside whenever it can be; for whatever reason it can be. Sadly.  And it is probably the best design at times.

        Really a good design should be the top priority - but I do see where the other two points of the pyramid would drive the design!

        Thank you for the example!


        • Once again - thank you for your valuable comments Michelle. As with the project management triangle, there are aspects that are not covered in the ABAP triangle. It is a way to simplify and visualize an agreement among ABAP developers on what to prioritize.

          When I write blogs, it is merely my thoughts, perspective, and experience put into words. It should never be considered as a scientific article that reveal a proven "truth". My ABAP thoughts often come when I'm out running. As a slow marathon runner, I have plenty of time considering ABAP concepts 🙂

          • nice article, but speaking from a developer's perspective, its design we bother about, if one is right at that the other two ends of your triangle are intrinsically taken are of !
          • Hi Anurag,

            thank you for your comment. Please read my first reply to Michelles first comment. As mentioned, like you also state in your comment, the ideal would be that good design solves the other corners of the triangle. Unfortunately, that is not what I have experienced so far. For example, from a design perspective I would like to use collections and objects instead of internal tables and structures in the business logic layer. Do you think that would optimize performance? I believe that many developers would tell me that they use internal tables and structures because it is faster.

            In my next blog, I will describe examples of my thoughts on code level.


          • Coming from a non-SAP world it's amazing how performance is important in an ERP system. The nice designs I make with OOP concepts all go down the drain when the codes needs to be used in work intensive programs.

            The concept of OOP, which enables us to reuse code in an amazing way, makes it less focused on the exact task at hand. If this task is really work intensive, it needs to be optimized, and there goes all the nice work.

            I had never thought about that, but OOP is really not adequate to ERP intensive tasks.

          • Hi Joao,

            thanks, this is exactly my point. As a convinced OOP developer, it has taken me several years to realize that it is currently not possible to combine great OOP design with high performance for large data volume processing. At least I have not seen the perfect solution yet. If anybody out there has it - please share!

            (By the way, security in itself is a compromise, as the most secure solution is an unplugged version, which is neither good performance nor nice design).


          • This is an interesting point, but I believe the truth is multi-layered.

            Firstly, most of the applications dealing with high data volumes tend to be fairly straight-forward in their design (read data, process, output). This should provide a good reason for dealing with it in an OO-centric way.

            Secondly, most of the performance-related issues with large data volumes relate to the DB access itself. This is (to some extent) independent of the application architecture itself, save for intelligent table access via proper indexes and so on - things which can easily be done also within an OO context (and, of course, HANA will hopefully revolutionize this aspect anyway).

            Thirdly, there are different flavours of "performance". What about reuse? Ease of maintenance? Total cost of ownership for procedural vs OO? I'd much rather maintain and enhance an (well-written and properly structured) OO application than a 5000-line procedural monster. Anytime.

            Lastly, and maybe most importantly, I believe the "OO is not performance-friendly" mantra is - to a large extent - being put forth by those developers/managers/devco's who are not too comfortable with the OO world themselves, in order to avoid having to deal with it. It's convenient to chuck the whole OO discussion down the drains - and, mind you, I believe that most of the ABAP'ers dealing with performance-related issues are still very firmly rooted in the procedural world. No offense intended.

            I challenge anyone to show me proof that performance and OO does not mix well!

          • Hi Trond,

            thanks for your comment ... and especially for writing a blog [original link is broken] [original link is broken] [original link is broken] This is the reason why I enjoy SCN.

            I have replied to your blog and followed up on this blog with an example where I usually compromise between design and performance. [original link is broken] [original link is broken] [original link is broken] This said, I don't disagree with you, but there are times where it is not possible to go all the way with OO programming in ABAP.



          • Got it - I agree. OOP for ABAP is indeed an evolution not a revolution. Time and again developers are told that they are suppose to write ABAP Objects, but never compromise with performance and security. That is a challenge. Especially because there is a huge inheritance of standard code that has not been converted yet. Within never frameworks such as Web Dynpro ABAP, CRM WebClient UI, it is much easier to apply a nice OOP design with swift execution. Without promising too much, in my follow-up blog I will propose a compromise between the conventional internal table/structure programming and using objects only. The idea is to have two layers; one for multiple processing and one for single or fewer objects.

            Happy holidays to you too!


          • Thanks for your propmt and valuable reply, the place i went wrong was interpreting 'design' as 'Design refers mainly to the proper use of ABAP Objects' as mentioned in your blog, i guess you are stressing more on OOPS cause it makes things reusable (one benefit, thr are many to count). I agree with your concept, however i think the third end of your triangle should be reusablity rather than design. anticipating a reply to prove me wrong again!   
          • Hi Anurag,

            just for the record, I do not reply to prove you wrong, but to have a nice discussion. This blog is too abstract to be binary 🙂

            Actually, I am mainly stressing ABAP Objects because it says so in the official SAP ABAP Guidelines, see guideline DEV-ABAP-2 (

            I do not believe my example of internal tables/structures vs. collections/objects is primarily focusing on a reusability perspective. It is about design.


          • Valuable?  Thank you!

            Blogs...  Isn't that what they are supposed to be, your thoughts, perspective, and experiences?  I know mine are.  However, yours are weighted more on "we should do this" side.  Your fame precedes you.

            We'll get there!


    • Hi Chandra,

      agreed, performance is very important for web development. Remember that the ABAP development triangle is not about excluding one aspect for another. The relative security vulnerability of web applications is the reason I have mentioned that it should be first thing to consider when doing web development.


  • I'd still contend that a properly designed program will automatically have good security and performance. In the ABAP OO world though, good design is not the same as following the standard OO paradigm. Using Collections is good OO design - but it is bad ABAP-OO design; internal tables are better. Using persistence classes is good OO design - but bad ABAP OO design if you're dealing with bulk data; Open SQL is better.

    At the base layer of data structures the best ABAP OO practice is to use the ABAP data structures directly - don't use abstractions. However, once you're beyond that layer, there's no reason whatsoever not use standard generic OO practice. I've been doing it for eight years with considerable re-use of components.

    Even if you have to break best ABAP OO practice, because you need to have that performance enhancement, you can do it carefully and make sure that your design is good elsewhere. I can't think of any scenario where security would have to be compromised in order to have good design - or where good design would compromise security. I can think of scenarios (and I've seen them) where bad design leads directly to bad security (and performance).

    Most of the cost of a program is in the design of it. A badly designed program will be more expensive than a well designed program, as it will take longer and be harder to maintain and enhance.

    • Hi Matthew,

      your comment scares me. Are you reading my mind? I am currently writing a blog post about the difference between standard OO and ABAP OO. Many ABAP Objects blogs here on SCN focus on OO or not to OO. I think the critical question to answer is where and what, within your code, to OO as ABAP is a hybrid language. I believe one of the key drivers of complexity in enterprise development comes from that it is often dealing with extensive amounts of data. For example, Horst Keller in his ABAP Objects book provides an example with car as an object. There is a method for increasing the speed. The problem is that in a typical enterprise scenario we need to increase the speed of 100000s of cars at the same time. Usually we get the list of cars from a BAPI call which returns an internal table. It would be very dumb to transform the internal table into a collection of car objects and then iterate over it in order to increase the speed. Instead we would probably create a car class (more a representation of car related code than a real object) which has a method to mass process internal tables of cars. Is that standard OO? Probably not, I guess it is more ABAP OO.   

      As I mentioned in a previous comment, good design can include both rigid security and high performance. However, many times I have experienced code refactoring (to less good design) in order to enhance performance. 

      Thanks for your comment.


      • No mind reading - just synchronicity and serendipity! I just happened today to stumble over your blog.

        I do most of my development in BI environments (two customers - one HR, one Finance), so I'm dealing with processing of complex data (HR) and/or millions of records of data (Finance). It absolutely must be efficient. For each source/destination, I usually have a single class to do the processing. Also, there must be no code change if the structure of the data changes in ways that don't affect the logic. So these classes have methods with STANDARD TABLE parameters, and I handle the data dynamically. 

        Where there are common tasks, I have other utility classes to handle them. For example, hierarchy access, or reading InfoObject master data.

        On one occasion, going from A->B, I was told the logic required, and then "we need to do the transformation like C->D". So, as the last step in the "A->B" processing, I instantitated the "C->D" class, and transformed the data through that.

        To me this is a powerful example of re-use, achieved by good design. After eight years of doing ABAP OO, I find it hard to do procedural - it's SO inflexible!