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. Conclusion
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.
