A Stable Basis
The ABAP NetWeaver Application server is robust, mature and highly scalable. It contains a number of frameworks we can use build state-of-the-art business applications: the Internet Connection Framework, SAP Business Workflow, the Web Dynpro Framework, a Business Partner application, tools for logging like the Business Application Log to mention a few.
These applications are shipped in two software components SAP_BASIS and SAP_ABA which can be regarded as the tool basis of the SAP Business Suite and thus ERP, CRM, SRM and so on.
Reuse & Controlled Evolution
Some frameworks have been ported back from higher software components into SAP_ABA, for example the BRF framework as well as the parallelization tool BANK_PP_JOBCTRL. Such a backport makes it possible that an application can be used in the whole business suite. This has following consequences:
- By reducing the number of solutions for often occurring problems in business programming we reduce the complexity of the overall solution.
- This means lower support costs because we have to maintain a smaller number of software modules.
- By focusing on a smaller number of applications we can perform better evolution of existing tools for business programming and add modern features to them like Web Dynpro frontend, better tool support for developers more easily.
Let me give an example: Parallelization is the most important technique to deal with mass data. There are at least 3 different frameworks within the SAP Business Suite for that purpose. In my opinion at most two different tools make sense: perhaps one lightweight and another heavy weight tool. These tools could be improved in further releases by implementing a lot of new features:
- Reduction of the implementation effort by avoiding customizing and doing code generation.
- Improved monitoring for parallel processes perhaps using a web enabled UI.
- Support of modern and non-obsolete ABAP programming models.
Another example comes from user interfaces based on ABAP Dynpro programming: If they get more and more complex it makes sense to use frameworks on top that allow us to use state-of-the-art techniques like ABAP classes and object-oriented design patterns. In fact there are at least two frameworks which serve that purpose: one in ERP and the BUS screen framework in SAP_ABA. This is hard to understand: In my opinion both frameworks still have the potential for improvement. At a certain time it would have made sense to review them, add missing features and use only one framework instead of two or three.
A Good Example: BRFplus – a modern Tool for Business Rules
Business software has to deal with business rules. Frameworks for business rules allow to separate business rules from business objects and business processes so that both can be changed independently. BRFplus is such a framework but has much more features: It is extremely fast, rules can be defined using customizing as well as application data and can be reused on the whole NetWeaver platform.
SAP recognized the strategic value of BRFplus:
- It is shipped within SAP NetWeaver software components and is not part of an industry solution that had to be ported back to SAP_ABA.
- It has good tool support and is integrated into the rest of the NetWeaver platform.
In my opinion BRFplus was done right from the beginning:
- BRFplus was designed as a tool for the whole NetWeaver Platform.
- It is based on model driven resp. generative techniques and so it is fast and avoids the complexity of tools based on customizing only.
- The product manager tried to get feedback from users right from the start.
- BRFplus contains wizards to migrate a lot of rules from the outdated BRF framework into the new world.
- The members of the development project blogged about their project and so it became known within the community.
A Missing Framework: Flexible Correspondence
One major strength of SAP software is its extensibility using customizing, frameworks and features of the ABAP language itself. With these features we can build appends to transparent tables, enhancements of user interfaces and much more.
Compared to these features the solution for output management like the correspondence workbench in SAP_ABA, which is heavily used within SAP ERP, is not very flexible. Of course we can change the layout of a certain correspondence but it takes some development effort to integrate additional data to a correspondence. And there is a drawback: it is not transparent what additional data are integrated to the correspondence because it is hidden in user exits which is an obsolete technology.
But SAP can do better: SAP CRM provides a framework that allows to create flexible output for campaigns that is easily extensible. In my opinion a comparable framework should be available in SAP_ABA, too.
In my opinion it makes no sense that SAP offers new solutions like Adobe Interactive Forms but the “middleware” that connects business processes and an output technology is rusty and uncomfortable. This is hard to understand because the creation of correspondence is a generic process: In the design time of a correspondence tool you define the interface of a correspondence. Usually this interface contains data from one or more business objects. But there should be the possibility to add extension points to the interface so that customers give out additional data with less effort.
At the moment there are different tools within the platform like for example HR and HR-TEM, which has its own and proprietary output framework. So if SAP wants to support new output formats like Adobe Interactive forms, a lot of frameworks have to be adapted which causes a lot of work that can only be done by specialists for that certain module.
Business Programming Tools as Strategic Asset of the NetWeaver Platform
It seems to me that in the past SAP developed a huge number of redundant solutions. There may have been reasons for it and in fact redundancy is not always bad. Let me explain that in detail. Common software modules must be of extraordinarily high quality and their release strategy has to be harmonized with the rest oft the platform which can cause problems.
Why is redundancy not always bad? Why is it sometimes wrong to try to achieve a single solution? The reason is simple: It is not easy to compare different solutions. In my opinion it is a common mistake of IT managers that they believe in the “one size fits all” dogma which hardly makes sense – or do you think we would be happy in world with unisex shoes and unisize shirts?
In my opinion SAP goes to the other extreme: At the moment I can hardly see a strategy for the evolution of business tools for ABAP development. And there is an additional drawback: New frameworks are shipped in NetWeaver Enhancement Packages that are linked to Enhancement Packages of SAP Business Suite so that you can’t install them independently. This is a little bit annoying because software developers should be able to use state-of-the-art tools like BRFplus to build applications on top of SAP Business Suite regardless of the version of the EHP of Business Suite.
What Should SAP Do?
Here are my suggestions:
- SAP should try to reduce the numbers of different coexisting frameworks. This should be a way to reduce support costs in a sustainable way. It also guarantees that frameworks can evolve much better and be adapted more easily to new technologies like Web UI and Adobe Interactive Forms.
- Let frameworks “compete” against each other! The reason is simple: When SAP ships a framework it has to be maintained and that means stability (think of stable interfaces). But during the development of a release or an enhancement package different solutions for the same problem will be created and in fact this is hard to foresee especially if you use agile development methods. But you can deal with that problem. At first you must be aware that there are different solutions for the same problem and then you should ask in the case they are comparable which one is better: which one can be used more easily be developers?
- SAP should focus on strategic frameworks. Web Dynpro and BRFplus are good examples: without them people will use low level approaches to solve the same problem again and again and so the whole complexity raises.
- When you want to know which framework is considered strategic don’t forget to ask Business Process experts. The reason is simple: They know the business cases and solutions which should be enabled better than developers do. Output management is a good example. The flexible CRM solution I mentioned above was developed for two reasons: Different output channels had to be supported and flexibility was absolutely necessary.
- If applications are adapted to new technologies (think of Web UI or Adobe Interactive Forms for example), try to see this as a chance to introduce standardized solutions or programming models.
- If it makes sense, add new features to the ABAP language! In my opinion Simple Transformations are a good example: If a certain technology like ABAP proxies for Enterprise Services need a speedup then there is the chance to integrate the solution into the language. But this should happen in a controlled way, otherwise parts of the business suite will create their own ABAP dialects like HR development did by using TRMAC-macros to define their own macro language years ago.
- Get in touch with the SAP ecosystem – this is a chance to get inspiration and to learn what customers need. In my opinion SAP did a great job last year by organizing round-tables and expert networking discussions during SAP TechEd. So my suggestion is that SAP should ask the community about the value of AS ABAP software components and how they can be improved.
- Promote new solutions! Here BRFplus is a good example: You can read blogs and learn at SAP TechEd about it.