Skip to Content

Given reader interest, I would like to share some experiences around the internal architecture of ABAP applications: lessons learnt from applications which were robust in the face of change, and others that were more brittle to change. My idea is to raise a number of issues that should, from my point of view, be answered before a major new ABAP application is started. This might be of special interest for partner companies that start their first ABAP development, or that want to
share and exchange lessons learnt, for example using the comment feature.

Everybody who is responsible for the creation of complex, long-living software applications needs to make a lot of crucial decisions. Some of these decisions are strategic, some are of a more tactical nature, but most of them have some form of influence on the future extensibility and maintainability of the application.

Fortunately, as an architect, we do not have to reinvent the wheel. There are tons of material available, both on the net and in books and magazines. This is true not only for development environments such as Java, but also for ABAP.

Strategic aspects of an application, such as the UI technology used, the way workflows are implemented, master data management, SOA integration etc., are covered in SAP-internal architecture guidelines and the principles of Timeless Software. SAP offers partners recommendations and insights into these subjects in a publication called “SAP Guidelines for Best-Built Applications“, which can be found on SDN.

Coming from another angle, the book “Official ABAP Programming Guidelines”  describes principles of well-written ABAP programs, such as naming conventions, the use of ABAP Objects, robust programming techniques etc.

These sources answer many crucial questions. Following them, an architect can assure that the right technologies are chosen, the right strategies for application management applied, that the coding itself will be robust etc. So, the architect’s  job is done, right?

Well, maybe not quite. Between the level of the strategic guidance given in the internal and external guidelines, and the level of well-programmed classes, subroutines, function modules and reports, there is another layer of architectural decisions that can make or break an application from the point of view of maintainability, stability and future readiness.

My intention is to address some of these architectural topics in a series of SDN blogs. In each blog, I will describe an architectural challenge and provide examples of potential solutions. I do not claim to know all the answers to all  uestions from different application scenarios; it is not my intention to provide the definite guide to ABAP architecture decisions. However, whatever answer an architect or a team finds to an important issue, if the issue is thought and talked about, and a conscious decision has been made on how to address it, there will be a lot of benefit compared to an application that does not even ask the question before the implementation starts. I am talking from experience here…

So, if you are interested in a list of topics on the “internal workings” of an ABAP application, feel free to comment. If you have ideas for subjects that could be covered, also do so.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Thomas Zloch
    Sounds promising, I look forward to compare your “insider knowledge” with my own development and support experiences at customer installations.
  2. Sascha Wenninger
    Hi Joerg,

    I’d like to put up my hand for you to continue your train of thought and share your experience with application architecture.

    One topic which only recently caught my attention (through reading about RESTful design) is loose coupling of applications at the semantic layer.

    Pretty much everyone is now building applications which consume backend services so that they are loosely coupled at the technical layers using SOAP/REST services and standard, cross-platform communication protocols. This is obviously A Good Thing.

    However what’s not so clear to me is how widely adopted the concept of loose coupling is at the semantic layer of an application, especially when it comes to integrating with other applications. To me the proliferation of Enterprise Services and Global Data Types is actually quite dangerous here as all of a sudden everyone and their applications share a common understanding of what a customer number must look like, and how it’s defined differently from an amount. So in a sense, we have tightly coupled some of the semantics…

    You can take this one step further. If the backend implements a 3-step process to accomplish something, how can we build consumer applications which are not slavishly bound to the number of steps and what they mean, and which will break if anything changes?

    A very, very basic example of I mean here might be an online shopping cart which could go through the following states, with transitions handled by services: Ready to Check Out –> Awaiting Shipping Cost Confirmation –> Awaiting Payment –> Paid.

    Now, how can we integrate this shopping cart (implemented in a web store for example), with our SAP backend that may or may not expose services which are a 1:1 match with each of the state transitions of the shopping cart? For example, the ERP system might not implement the ‘confirmation’ steps at all, or it may have additional steps. What if the backend is enhanced later to have additional steps, or moves from SAP-standard enterprise services to custom-built services using the same data types?

    Anyways, there are a lot of combinations and permutations here, but the abstract problem remains. Has the point of close coupling between applications simply moved higher ‘up the stack’ from the technical protocols to the semantics embedded in the services and their payloads? How can we avoid/minimise this?

    I’d love to hear your thoughts on this.


    1. Joerg Wegener
      Post author
      Hello Sascha,

      yes, that will be one of the topics I would like to discuss. I had to solve such an issue in one of my projects and will introduce the solution we took. This solution also covered the semantical aspects of inter-application-communication.

      Thanks for the detailed comment

    2. Former Member
      Hi Sascha,

      Maybe also try and do some research on the SAP Netweaver Gateway Project & what it has to offer. From what I have read so far & what I understand about it, it provides a RESTFul API for the entire SAP Business Suite. Personally, I feel this turns everything as we know it (especially in the context of SAP Enterprise Services & SAP GDT’s) on it’s head is going to be a really big game changer! I will be loose coupling until I’m blue in the face using any technology my heart desires 🙂

  3. Kumud Singh
    Beautiful blog to be read first thing in the morning. Thanks.
    Yeah, I too would be interested in adding to the areas of discussion.
    I already have couple of them to be discussed.
    It would be great if you list out the agenda of your discussions on these upcoming blogs. Then we too can add (in case they match) and then come up with the initial list. In case you like this idea.
    1. Joerg Wegener
      Post author
      Hi Kumud,

      I might do this, but the list itself is still work-in-progress.

      I will either post it here or as a “teaser” chapter in the next blog installment.

      Thanks for the idea


Leave a Reply