Skip to Content
Author's profile photo Tobias Trapp

Anti Patterns in ABAP Development Projects

In day-to-day business many ABAP programmers have to write reports for evaluation of their special field and the implementation of user exits. As a consequence these developers have vast ABAP skills and they are knowledgeable about the parts of SAP ERP they oversee. However, this doesn’t automatically mean that the developer in question has studied in depth software structuring or even software architecture, both of which are indispensable for the development of new applications.  If such a situation presents itself, the chief designer has to take certain measures. It’s sensible to name a chief designer who guides the ABAP programmers, advises on essential design decisions and who also doubles as a coach. If a chief developer fails to identify the challenges of new ABAP development and believes that he has to transfer his experiences with classical report programming to a larger development project, he takes a lot of chances. The development will not be conducted in an adequate technological and organizational environment. In my opinion there’s a series of typical signs that these prerequisites aren’t met.


„One Man – One Report“


The phrase surely makes sense within the development of single ABAP reports of a special field. This approach has its advantages:

  • We define a part of an application with a common module unit that’s equally useable for user dialogue and background programs.
  • The work organization is clear: A series of developers are programming reports: work distribution, work coordination and modularization of the overall application thus is secured.  

This sounds good. Now where is the fundamental error?  For one, a report is a rather inapplicable module unit for a big application. For example you have to use tricks to make it send return parameters back to the caller. In fact, a big application will always consist of a number of function groups (better: objects) and other development objects.  Even more serious are the consequences in work organization: Let’s assume that motivated developers start working parallel on their application part. Who can tell if the same function isn’t developed multiple times, possibly in different ways? And should the overall project come to a happy completion, who guarantees that for each single application part there is a second person next to the developer who can fix bugs and maintain that part. There exist teams of programmers who in years haven’t tried to develop an application together, although the advantages are obvious: All programmers involved know the code, can discuss their design decisions and explain their code to each other, or realize that it’s become too complex.  There’s also an implicit know-how transfer in this method: A developer who knows a field very well, can transfer that knowledge to his peers. Furthermore there’s another advantage: If there’s parallel development of an application, it will faster be test ready. When then problems are found during acceptance tests, developers can learn from them and use counter measures in the next application they are developing.  In my opinion, many old school software development managers or former report programmers haven’t yet realized the advantages of collaborative work forms, but see them as a KO-criterium due to the additional overhead needed to coordinate parallel activities. I think that the lack of collaborative work forms are, along with the high grade of specialization in the SAP programming field, the main reason for many ABAP programmers’ lack of innovative ability, like for example the inexplicable refusal of many developers to program in ABAP Objects.  

I used to take this as a quirk and a question of taste, but now I see the refusal of “new” technologies as a risk. An example will show why: Naturally we can develop database access layers anew any time – but the resulting software will become too expensive, meanwhile ABAP offers a well functioning framework for persistent objects. We should learn from this that up to date and cost-effective solutions need a new work organization and a new technological environment.  

“One Development Class Is Enough.“


While the software development manager I mentioned above can still cite reasons for modularization in his instruction for report programming, he usually fails totally when it comes to software structuring.  While it’s usually sufficient to set the ABAP development elements to one class during the creation of User Exits and single dialogs, this method isn’t recommended when it comes to the development of bigger applications:  

  • The ABAP package concept allows to differentiate between private and public parts of a package by defining package interfaces.
  • Violations of package interfaces can be checked with the Code Inspector
  • We can define the dependencies between software components and test them automatically 

In my experience the difference between Development Class and Package often isn’t fully understood, just like the difference between a packages and an amount with the same name (due to name conventions) isn’t  seen.

„The Report Gets Specified, Designed, Coded And Then Tested.”


Here’s another difference between report programming and ABAP application programming: In report programming we have a special field and development of well understood data and a process model, to which we want to add reporting functionalities.  ABAP application development for example needs additional requirements analysis. Equally we can’t expect, that important methods of software development (like the waterfall aproach) which may be quite successful in report development, will also attain the goal in the development of bigger application systems.  The same is true for software tests: Often it isn’t known that module testing now also is possible with ABAP Unit. The idea that the creation of test code during or even prior to coding is possible and sensible, sadly still seems esoteric to many ABAP developers and development managers. Software tests are often seen as unpleasant busy work which only needs to be done at the end of development. And a good developer who at the end of development still has the patience for tests is regarded a top performer. Many developers and development managers haven’t looked into test driven development so far.

“Real Men Do It All On Their Own“


Each Netweaver Application Server has a series of tested frameworks in its ABAP Stack  – for example:

  • SAP Business Workflow,
  • Organizational Management
  • Business Rule Framework,
  • Formula Builder,
  • Generic Object Services,
  • IDoc Interface,
  • Business Application Log,
  • SAP Business Partner,
  • Parallelization Framework. 

Each of these solutions has been proven and tested many times. Each newly developed solution has the disadvantage that it still has to prove its quality. Furthermore are these solutions are known to other users and developers and this isn’t the case with self made solutions. In fact they are, when it comes to handling and quality, little else but hardly tested and thus unestablished solutions.   If you develop without detailed knowledge of standard components, the result will be mediocre software at best, which has been created at a disproportional effort for development and quality assurance. In contrast, the knowledge of APIs of Netweaver ABAP stacks also mean knowledge of these APIs’ weaknesses and limits.


It doesn’t make any sense to think that experience in report programming or in SAP ERP implementation projects can be directly transferred to bigger ABAP development projects. We also can’t assume that the skills of experienced ABAP developers are automatically sufficient:

  • Is their knowledge up to date or for example stuck at the level of SAP Release 4.5C?
  • Do they know about recent module units (in classes and packages)?
  • Do they have a good overview of APIs and Business Services in ABAP Stack?

Also the software development manger should ask the question, whether his knowledge about development methods is up to date.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      Fantastic article and thoughts..  The ABAP Development team in SAP continue to make the environment very easy to work in, but we must not lose sight of the overall disciplines which we are working in.. 
      Author's profile photo Former Member
      Former Member
      Dear Mr. Tobias

      Greetings for the day.
      I have gone through this blog......n is extreemly good......i think all the developers been a part pf new development should must go throuh this blog.....

      Prashant Tiwari

      Author's profile photo Thomas Alexander Ritter
      Thomas Alexander Ritter
      Hi Tobias,
      nice blog. Regarding unit testing I just want to mention that there will be a session at TechEd2008 which even has "Test Driven Development" in the title: Hopefully it will be educational for some developers.
      cheers Thomas
      Author's profile photo Former Member
      Former Member

      Well -  The blog was interesting.   But does it take into account smaller firms?   If there are 3 developers with many different request it doesn't make sense for them all to work on the same thing.

      I firmly believe you can take an SAP report developer and have them change the way they think.    It doesn't mean they are stuck back in 4.5.   It just means they haven't found a better way to do things.   I've said it before and I'll say it again - "there are about a million different ways to do one thing in SAP.   Ask 10 different developers and you can get 10 different answers".   How do you know your way is the right one?   I'm not saying it's wrong.   I guess how would you justify it in a small shop.  One size doesn't always fit all.

      Each technology has it's pros and cons.   Agreed.   One person probably doesn't know them all in depth.   Agreed again - so why would only one person put the design together.  (I may have missed the point here. )  As always, it's not just the technical side, the functional side matters.  Understanding the business and what they really want comes into play as well.   Putting together massive projects would have to be a combination of technical, functional, and business units.   Once defined there should be several stop points in the development to check if it is going the right way.   When you get done you need a product that the business will love.   Why love?   You've just spent X amount of developers time.

      So interesting...    Worrisome...  Yes, I do know a bit more than just the report development.  But what if someone had never let me learn other things, and had just given me a piece of the development.  It wouldn't have been fun anymore.   Being a part of a team is more than just doing your small piece.   I would hope.   I think it is also helping to define and refine the project based upon your technical/business/functional skills.

      Alright done venting a bit.   Yes - I truly believe you should know the functional and technical side of SAP.   In depth maybe only in a couple areas.   I strongly think you should know the business where you work.  OR the business you are designing the project for.