In the last weeks I blogged twice about disruptions in SAP standard software – now I turn the tables and will tell what I did to prevent disruptions that have been caused by ourselves. I want to discuss what we, as ABAP developers, can do to prevent disruption. Why is that important? At the one hand we benefit from evolution of SAP NetWeaver and SAP Business Suite, on the other hand we have to take care that our solutions can smoothly survive any SP and Ehp upgrade. Every ABAP developer knows some guideline – for example to avoid modifications but is it the best we can do? I don’t think so. As one of the leading software architects of a huge ABAP solution I feel responsible to establish this quality standard because we want to benefit from new SAP releases in many ways – think of our HANA and Mobile strategy for example. And so I will blog about my activities in this area.
But before going into detail let me explain how the story went on.
SAP Listens
As you might know software updates have been really painful for me in the last time. Since some months I’ve been into discussion with SAP and in many constructive talks we found solutions. I am glad that SAP listened carefully and understood the problem. These are really good news!
Although we found solutions for existing problems I am thinking about the future: we want to benefit from new SAP solutions and technology and will keep a high Ehp level. How can we manage the risk of SAP software updates?
Evolution of SAP Software is Necessary
The reason is that we have to evolve our IT solutions for many reasons:
- we have to support out business using better and completely new IT solutions,
- we want to reduce const,
- we fulfill merging and acquisitions and last but not least
- we have to obey compliance aspects.
SAP Business Suite and SAP NetWeaver platform constantly evolves and we benefit in various aspects: from performance optimization, new technology (think of HANA, Mobile, new UIs), new development tools, improved processes and much more. If you want to benefit from this evolution then you have start to think about the risks and how manage the risk of disruption.
In my opinion there are many things SAP can do to prevent disruptions as consequence of a constant evolution:
- SAP spends time in Customer Validations and Ramp Ups to ensure that the solution is mature.
- An important aspect is time. The more time we have we can test all necessary measures: installation, administration, performance and so on. The reason is that IT architecture often is not agile: if problems cause delays than they will lead to trouble because usually changes in systems are difficult and can be done only in small timeslots. If these are over sometimes a whole upgrade project can be delayed by months. If a new solution is available early so that we can do tests we can reduce the risks of disruptions.
- SAP should spend budget for rectification of defects after drastic changes. This can be done with Customer Connection and Customer Engagement Initiatives.
The message is simple: there are many ways to manage consequences of changes – and only if this can’t be done a disruption will occur. But this means also that we as developers of customer and partner solution are also responsible to prevent disruptions: we have to learn how to make our software adaptive to change and to prevent disruption and this is what I will talk about in the rest of this blog.
Implicit Enhancements Considered Harmful
The reason is very simple: Implicit Enhancements have nearly all bad properties of modifications. They change the SAP code instead of using defined interfaces like BAdIs. They are code injection in SAP standard code and can cause trouble:
- What happens if the program logic within SAP standard changes and so the implicit enhancement isn’t called?
- What happens if you use another application / business function and an enhanced functionality that is called now from another application? Are there unwanted side-effects?
These are the same problems you have with modifications when checking conflicts – you only have to use transaction SPAU_ENH instead of SPAU. I looked at a lot of implicit enhancements within last time and learned the following:
- Some of them are completely useless and could be removed. This is an interesting phenomenon: they have been introduced some time ago and nobody controlled them.
- Some of the enhancements are problematic: the developer who introduced wasn’t available and it was difficult to figure out the reason for it. This is sad situation compared to “proper” custom or partner development where there concrete artifacts (online and offline documentation) for every program.
- Many developers are well aware of the risks of implicit enhancements and used them only if there was no other chance. At the same time they tried to convince SAP to introduce a BAdI. They know about the risks and do explicit tests after every software update (SP and Ehp).
So as leading architect I am glad that we introduced the same governance process for implicit enhancements like for modifications. And I am also glad that we have been able to remove all implicit enhancements on one of our development systems within a week.
Perform Package Checks!
I am also glad that we introduced package checks in ABAP development of solution. We use them to guarantee installability of software components, to structure our solution and reduce the risk of side-effects after changes in a complex development landscape.
Another reason is that we want code against the same package interfaces like SAP Business Suite does to ensure that we only use public interface and avoid using private implementation details of packages of SAP software.
I made a good experience with package SAI and its subpackages: the web service runtime of AS ABAP was evolved in many SPs but the elements exposed in package interfaces remained stable. I can tell you many other examples where usage of ABAP package interfaces prevent you from damage of non-compatible changes.
What are your Best Practices?
To summarize: we want to benefit from the evolution of SAP NetWeaver and SAP Business Suite because this is essential for our IT strategy. Therefore we invest to harden our solution. I think SAP should encourage others to do the same perhaps in Guidelines for Best built Apps:
Of course we use additional best practices like automated testing but it would be interesting what you as software developer can do make your custom solution as stable and robust as possible. In my opinion this is the most important quality criteria for any customer or partner solution and far more important than naming conventions for local variables for example. Of course many people love those discussions (“Is prefix lt_ for internal table ok or l_tab_? What about l_tas_ for sorted tables? What about l_tas_s_ for sorted tables with secondary index?”). In my opinion those discussions are a waste of time. For me it is far more important to emphasize that our solutions that are ready for the future is much more important.
How do you achieve this goal? What are your best practices?
