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.