SAP Continues Disrupting Itself
As you might know I’m an enterprise architect working for an ISV that is a special expertise partner of SAP in insurance. For our business reliability and dependability is as important as innovation. We believe that HANA is a cornerstone for our IT strategy but there are other important topics, too: We need to improve automation of business processes, we connect IT systems of stakeholders in the area of health care, we need better support of telemedicine and of course mobile solutions. To master these challenges we need SAP NetWeaver Platform and to benefit from its technical evolution.
In one of my last blogs I discussed some problems with the last developments of SAP NetWeaver platform: SAP delivered lots of deletions as you can read here. In fact it was even worse because some deletions have been ported back to earlier releases. So even if you decide not to install an Enhancement Package then some of these problems will be shipped to you in SPs which you will install to get bug and security issues fixed.
In the last time we had a lot of trouble with disruptive changes. Fortunately SAP fixed many of these problems but nevertheless all issues aren’t solved. It was my hope that SAP would deliver all corrections so that we could avoid any further delays in the future but this didn’t happen. In fact there is a solution but a unit at SAP doesn’t want to ship it in a regular release. So let me summarize:
- Those changes are completely unnecessary.
- SAP could solve these issues immediately.
- I’m talking with SAP managers since months about it and many the most urgent problems have been solved but one severe issue remains still unsolved.
“Are they kidding? Go Disrupt Yourselves!”
This was first reaction of my colleague Thorsten Franz when I told him of the decision of this development unit of SAP. We should implement to functionality of the deleted function modules in our namespace. Then we have to adjust the code in hundreds of locations.
Maybe some developers at SAP don’t know how an ISV is working: We don’t just copy some function modules into Z-namespace, do adjustments and transport it to Q-systems and then into production. As ISV we create software components the same way SAP does. We have software releases which are shipped to our customers who install, integrate and test them. We develop two releases in a year which is necessary because of legal compliance reasons. If we can’t implement software updates within a short period of time we will have a delay in development – moreover we have limited development resources and we could invest it in a better way, say developing solutions for our customers, spending more effort in quality assurance or innovation.
“I wished more Companies would have ambitious technology strategy and culture of innovation as you have”. This is what many people at SAP are telling me – and yes, in the past software updates have been predicatable but now they aren’t any longer. This is really a weird story: We are working closely together with SAP to obtain best results. We are working in various customer Engagement Initiatives and in the SAP Mentor Initiative. SAP always emphasizes that innovation without disruption is their highest priority and I’m sure that developers of SAP Business Suite share this paradigm as well as people from server technology development and most of people in NetWeaver development – unfortunately there are some development units who spoil our joint efforts: Yes, we want to implement HANA and benefit from enhancement packages and many people at SAP work hard that we are successful. And there are others that spoil all this joint efforts.
Does Everyone at SAP Understand the Nature of Disruption?
Well, I don’t think so and that’s why I have to explain it so that everyone will understand it:
- The root cause for any disruption (major or minor) is a technical disruption.
- When you delete an IDoc segment just to “clean up” then the whole integration scenario of an enterprise architecture can collapse because exchange of master data is crucial for core processes of our business.
- Compared to this the change of a UI is a minor disruption but still severe: customers have to be trained the use the new functions. This can be managed but needs to be planned. Changing the UI technology is more disruptive but customers accept it as long the impacts of disruption is predictive and manageable and provides business value.
- If a developer at SAP deletes a function module then a huge solution of a partner resp. customer isn’t working anymore and needs to be corrected. Correction isn’t always easy because sometimes we don’t know how to correct it. But even if we know it takes time and this can become critical: most IT infrastructures are heterogeneous and there are centralized governed change processes. They have releases and for changes there are only a few time slots because many organizational units are involved in the change process. If you can’t perform these changes in a defined time slot the whole change requests gets in danger.
This is why enterprise architects and IT managers fear disruptions especially when they affect core processes. Sometimes disruption is necessary but it has to be manageable and provide business value.
The fear of Disruption spoils the Success of SAP’s Innovation Strategy
This is a simple truth everyone at SAP knows and any business analyst will confirm. Every executive and most developers at SAP already understand this simple truth. But unfortunately there are some developers who don’t seem to care about it. It seems to me that they are only thinking in terms of functions modules and are happy if they can leverage the proportion of object oriented code by say 0.1 ‰ and delete “legacy code”. And yes, since I was a developer for a long time I appreciate the intention to produce clean code. But they are incompatible changes will produce disruptions.
SAP has to establish Standardized and Consistent Development Standards to make Software Updates Predicatable
I am worried. Those disruptions caused already delays and since no everything is resolved it will cause further trouble. But it is worse: The consequences of software updates have been predictable and could been mastered using best practices but now my predictions and best practices fail and this is what me worries most.
If development units of SAP NetWeaver continue this way then we won’t be able to follow SAP’s innovation strategy because we would have to spend our time in completely unnecessary work.
IMHO SAP’s development units have to decide what is more important to them: performing “Spring Cleaning” in SAP NetWeaver that provides customers absolutely no business value and causes only pain or providing business value say be optimizing NetWeaver for HANA for example. At the moment SAP’s strategy is not consistent:
- SAP can’t encourage customers to spend efforts to follow their innovation strategy on the one hand and create obstacles on the other hand.
- SAP can’t spend lots of effort to work as enabler for innovation on the one hand while other development units prevent customers from implementing innovations.
- SAP can’t do both: “spring cleaning” and thorough HANA optimizations of the infrastructure.
- SAP can’t announce the non-disruptiveness is most important and allow that SAP’s development units have different objectives.
Me message is simple: Those unnecessary changes have to stop immediately. Otherwise they will harm the SAP Ecosystems and so SAP as a consequence.
Hi,
This is a simple but ignored truth! There are dozens of FMs that just 'disappears' when you do a system upgrade. Of course, there will be a different FM with just a few wordings different in its name. I've always thought, why can't they just enhance the same FM or just leave them as it is instead of deleting it? 😕 As you said, it will be a nightmare for an ISV as you have to reach out to each of your customer who is potentially going to do an upgrade. Now you can't promise your customer any longer that your product is going to be upward compatible with all SAP upgrades. 🙂
Cheers,
Mahesh
Hi Mahesh,
yes, you got the point: for ISVs those deletions are a nightmare. But this can become a problem in every development project although I am well aware that many experienced software developers and architects at SAP know about the consequences of deletions and avoid it. I wish that all developments at SAP would follow that example but unfortunately there seem to be different development standards. And what worries me most is that my best practices are not working any more:
Cheers,
Tobias
shouldn't SAP announce the upcoming deletions to allow its customer base to proactively check which parts of their custom development can be affected? this should be deployed as a standard and unobtrusive transaction showing the date of the planned deletion, leaving it up to the customer for any follow-up. just a thought.
Hi Greg,
yes, but I think I have a better idea. Some executive from SAP should visit those programmers and tell them the following: “Non-disruptiveness isn’t just a buzzword for SAP. Stop what you are doing immediately otherwise I send you to every customer who has a problem with your code and you fix it for them.”
Cheers,
Tobias
"It seems to me that they are only thinking in terms of functions modules and are happy if they can leverage the proportion of object oriented code by say 0.1 ‰ and delete “legacy code”. " -- good thing though but with out strategy, isn't this like a child's play?
I appreciate the idea of object orientation, but tampering with stable code / functions which would have been used for customer's extensions means that developers at SAP are tampering customer's development too... which obviously can not be predicted resulting in less stable systems. Should SAP be releasing the changes along with existing code giving a choice to customer. After all, it is his call to choose on existing code vs more performing new code.
These are good points. I also appreciate object oriented code but I think it can coexists with “legacy” code. There are many examples in SAP standard where SAP introduced an new API to a very old functionality (see correspondence tool for example). IMHO technical evolution is possible without producing incompatible changes.
Sometimes the software reached the end of its life – then you should offer a new alternative like SAP did in BRFplus: it is better and faster than BRF. There are the cases that SAP wants to redesign an existing framework like SAI package for SOA runtime: There have been drastic changes within that framework but I had no trouble because I only used elements exposed in the package interface. I think we have the possibility to define package interface right now and SAP should keep them stable and encourage SAP partners to use the package interfaces. Of course for legacy code this is somewhat problematic but here SAP should try to apply only compatible changes.
Best Regards
Tobias
Very nice post Tobiais. It's high time SAP understands the meaning for "co-ordinated development". Looks like there are too many streams which work concentrating on individual trees and forget they are supposed to be part of a forest.
Hi Tobias
Seriously?
That's a no-go, just think that you copy hundreds of line of code that were created out of your domain and than you take ownership of it. It's not just making it Z, you have to check the code to see what other functions are used. And then you are responsible for bug fixing of SAP code ...
Developers may be the new king makers, but just because some devs think they don't need a function anymore, deleting is still a no-go and should be treated respectfully by supervisors, managers, et. al.
Besides, what happened to using @deprecated (sorry for the Java spelling) and treating BAPIs, (R)FM as an API? Before you delete something, mark it as: may change in future releases and if you really delete it, delete in the next major release (that is: NetWeaver 8 or later).
Disruptive or not, this is simple and basic coding of an application that is shipped to customers.
PS: Looking at the spelling, this is a topic you really care about
Hi Tobias,
no, I’m not kidding – they really want me to change the code. When they first suggested to use the new OO API I answered that they should change the code: I open SAP_SUPPORT on two or three development systems, create some workbench transports and then they can start to work. I think this would be a good way to learn that other people in the ecosystem are using their code.
I know the rule for BAPIs and BOR objects but not for functions modules. I’m in that business for more than 10 year but I have no clue. Weird, isn’t it?
Cheers,
Tobias
Looks like SAP lost control for source code last years. SAP is not just ABAP code like thinks some developers 
Modernizing ABAP developmentRegards
Sergii
Hi Sergij,
well, there are different reasons for the problem but I don't think it is the problem of the ABAP language - modernization was too disruptive, there had been trouble with code lines NW 7.30 vs. 7.31 and so on.
But there are also good news and SAP listened. Do you know my latest blog?

Best Regards,
Tobias
Despite the few cons (like rendering useless IS SUPPLIED/IS REQUESTED parameter checks inside FMs), IMO there should be no more than one call to any one SAP's FM in custom code, and that call should be in a simple wrapper method mapping to SAP's FM interface the interface definition adhering to customer's naming conventions and translating the classic FM exceptions to customer's own OO exception classes. Wrapping the use of SAP's Form Routines having well defined interface is more complex but also doable.
Yes, even POPUP_TO_CONFIRM should IMO be wrapped - the 5-10 minute additional investment required is well worth not having to dread being forced to replace or adjust hundreds of calls. The wrapper classes can be static or singletons and for ease of finding the naming can correspond to names of SAP function groups, and the method names - to SAP FM names. I've even taken on wrapping and re-factoring to wrappers the BAPI uses in our system... 🙂
I'm with the "wayward" SAP team on this - far from it being unnecessary, continuous "spring-cleaning" of obsolete or unused code is IMO essential software maintenance... and customers/partners IT folks should take that into account.
That said, our team has not yet come to agreement on how to approach the use of SAP's classes...
cheers
Jānis
Hi Jānis,
I did the same thing some years ago but I failed. What are the reasons:
In my opinion the only chance is controlled reuse. Before I give some hints I will explain what not to do: Some developers don’t even think about local variables using TYPE … LENGTH and look for a data element in SAP Business Suite with the right properties, even if texts and documentation don’t fit. They don’t care about the applications where those domains and data element belong to – and so they use a domain of IS-U, a function module form CO-PA and a data element from BW – and then they complain because of changes in SAP standard.
So my advice is:
You can summarize the advice: Do reuse of an SAP standard function if it makes sense and when you think the API will be stable. Don’t do reuse because you think you can reduce your development time by some minutes.
Best Regards,
Tobias