Is SAP NW EhP 3 really Non-Disruptive?

ttrapp · ‎2013 Jan 28

Everyone talks about non-disruptive evolution of software systems - but what about the ABAP application server? Is non-disruptiveness really the most important development guideline? In this blog entry I look at the facts.

The ABAP Application Server contains the technological basis of SAP Business Suite. It has a set of technical tools in software component SAP_BASIS, among them

UI technologies like ABAP Dynpro Controls, BSP and ABAP WebDynpro
SOA frameworks and a local integration engine
frameworks for business rule like BRFplus
SAP Business Workflow
frameworks for output management technology and document archiving and integration

The software component SAP_ABA is more useful for rapid development of business applications because it is a treasure chest of reuse tools. If you get curious a recommend you one of my previous blogs.

In fact I was already looking for AS ABAP 7.03 which is also part shipped with SAP NetWeaver 7.31. The components SAP_BASIS and SAP_ABA 7.31 contain many useful tools and it is part of SAP ERP 6.06 and CRM 7.2 which is necessary for SAP Business Suite on HANA.

For me the implementation of SAP NW 7.31 turned out as painful and without help from SAP it could have become a nightmare. The reason for this problem was that SAP deleted many development objects which caused syntax errors in custom code. The good news: SAP was fair especially if you think of Note 109533 - Use of SAP function modules.

Evolution of AS ABAP and Stability of Software Components

Was it just bad luck? Let’s look at the facts. Do you know how many development objects of SAP NetWeaver have been deleted in the last time. If you don’t know you should have a look on the number of development objects (TADIR entries) of software components SAP_BASIS and SAP_ABA in the following picture:

The SAP_BASIS component got bigger while the SAP_ABA component even had shrunk. So I counted TADIR objects again and learned that from 7.0 to 7.31 more than 11.000 development objects of SAP_ABA have been deleted! 2.328 deletions came from the deletion a whole framework: see note 838772. This is a drastic incompatibility but I don’t consider it as harmful: ABAP developers should only use SAP frameworks that they know. No reliable SAP developer should perform recklessly and randomly reuse. If you hired one of those developers then you had bad luck, the future of you custom development is in danger.

Implementation of SAP NetWeaver Ehp 3 Considered Painful

As I already mentioned before I made bad experience with SAP_BASIS and SAP_ABA 7.31 but you might have made a different experience. So let’s talk about facts and count deletions of development objects in terms of transparent table TADIR. Winston Churchill once remarked that the only statistics you can trust are those you falsified yourself. You might judge if this holds for me – I think I was quite fair:

I don’t count the elements of above mentioned deleted framework because I consider it as deployment error.
Furthermore I don’t consider deletions which are downports to a deeper software component.
And last but not least I’m counting only development objects that are shipped with NW 7.0 and I don’t count deletions of objects shipped with NW EhP 1 resp. EhP 2.

Nevertheless, the number of deletions is dramatic – from NW 7.0 NW 7.31 3.25% of SAP_BASIS was deleted and 7.98% of SAP_ABA. You can see this in the following picture:

This is really much, especially if you compare it with other software components of SAP Business Suite and Industry Solutions which is displayed in the following diagram.

What can we learn from this picture: SAP Business Suite is quite stable and has only between 0.2% and 1.4% deletions – and please compare it with the deletions in SAP NetWeaver: We have 5.8% and 8% deletions in SAP_BASIS and SAP_ABA – and please remember that I was fair and didn’t count a huge framework which was deployed by accident.

You may ask why I am that fair because and didn’t count a huge set of deletions. SAP NetWaver had a hard time within the last years:

SAP NetWeaver had to find its place between onPremise and onDemand
SAP shot down a development line 7.10, 7.11, (7.20,) and 7.30 and 7.31 and did downports to 7.01, 7.02 and now 7.31 is a consolidation release.

Under these circumstances I am quite impressed that SAP managed to keep quite SAP NetWeaver stable. In the mean time the software components of SAP Business Suite and Industry Solutions got bigger and bigger as you can see in the following picture:

I wasn’t surprised because of this because SAP shipped many Enterprise Services as SOA layer which usually cause an inflation of data types.

The Consequences of Incompatible Changes

Every deletion is an incompatible change (the opposite is not true – there may be much more incompatibilities in SAP NetWeaver) and every incompatible change may cause trouble for customers and partners. The consequences are severe:

reduced stability - incompatible changes can come with SPs and not only EhPs
maintenance costs - you have to correct the error, test and ship the corrections
implementations of SPs will get more costly with many side-effects like security risks

This is really weird: SAP does a great job making SAP Business Suite on HANA a non-disruptive change and developers and SAP Developers from SAP NetWeaver and Reuse Layer seem to try to perform a “spring-cleaning” which thwarts SAP’s efforts.

I don’t think this is consistent: SAP Business Suite as well as solutions from SAP Ecosystem build a software pyramid – if the technological basis – SAP NetWeaver is not stable that the stability of the whole solution gets questionable.

So if the priority of SAP Business Suite development is to avoid any disruption and the same should hold for SAP NetWeaver development.

What should you do right now?

My first advice: Don't panic. If you have a bigger custom development project I suggest you to set up a sandbox before doing a software refresh and test your applications using the Code Inspector. Don't try to avoid a NetWeaver EhP implementation - this won't help you because many nasty deletions have been shipped in SPs and I recommend a high SP level because of many reasons - think of security for example.

Let’s Talk about Disruptions

SAP Business Suite on HANA is released – please I readthorstenster's great blog about it: The SAP Ecosystem can only follow this strategy if SAP NetWeaver development stops making incompatible changes - otherwise the whole HANA strategy of SAP Business Suite will become questionable because of disruptiveness.

On the other hand the code of SAP NetWeaver is very old and I expect evolution will come to point where incompatible changes are necessary because it has to face challenges like SAP HANA, Mobile and Cloud.

SAP has much experience with stability and governance processes: think of BAPIs, Enterprise Services and so on. The ABAP language has a package concept, package interfaces and SAP Code Inspector can check usage of obsolete elements. So the technical infrastructure for a governance process is there – SAP only has to establish it.

TammyPowlas · ‎2013 Jan 28

Hello Tobias,

This is well done as usual

In the mean time the software components of SAP Business Suite and Industry Solutions got bigger and bigger as you can see in the following picture:

Would you please check this, as it seems a figure/picture might be missing.

Regards,

Tammy

ttrapp · ‎2013 Jan 28

Hi Tammy,

thanks a lot - you have eyes like a hawk. It seems I didn't save my last version of this blog but now inserted the picture.

Best Regards,

Tobias

former_member182046 · ‎2013 Jan 28

Fantastic job, Tobias! What a great idea to just measure software stability by looking at the fluctuations in TADIR. I wish I would have thought of that. 🙂

TammyPowlas · ‎2013 Jan 28

I'm glad you added that as we saw big changes with FI-CA in Ehp5 - your graph explains it all :smile:

Tammy

Pazahanick_Jarr · ‎2013 Jan 28

Excellent article Tobias and a great topic give the recent claims from SAP that customers should expect "innovation without disruption" for the Business Suite on HANA.

I take a stronger stance on the innovation without disruption as my track record with Enhancement Packages and even Feature Packs from an IT and Customer standpoint has been it has caused "some" disruption given some of the technical prerequistes which you confirm in your analysis. I personally wish SAP would retire the "innovation without disruption" marketing message and replace it with telling customers the reason why offering X (ie HANA/EhP's) will be worth a "little' potential disruption.

On a side note some of the new HR Renewal functionality delivered in Feature Packs has NW 7.31 as a prerequisite.

stephenjohannes · ‎2013 Jan 28

From a technical perspective I always argued that SAP can call it an enhancement packs not an upgrade, but we all know the truth it's a technical upgrade. In fact instead of saying that we are applying enhancement packs that we are performing a technical upgrade would be more honest, but it strays from the marketing message. I think upgrades have negative reputations in the SAP space, so a new word was implemented to ignore the fact of what is really happening from behind the scenes.

That being said if I look at things from an end-user perspective, if IT keeps the down-time window and involvement to the same amount of effort as a support pack and we don't try on anything new, then it's not an upgrade. In fact even with EHP1 for CRM where there are new features out of the box, for the most part an end-user can still do everything the same pre-EHP as post EHP if we dont' turn anything on. SAP has accomplished, but yes the disruption part is not your business disruption, but IT distruption :mad: !

I would agree that SAP needs to assume that every thing they delivered will be "misused" by a customer and they only should delete objects if they can provide tools for the customers to use something else during the EHP process or otherwise like you side you might as well call things "upgrades" again.

Take care,

Stephen

ttrapp · ‎2013 Jan 28

Hi Jarret,

you are absolutely right: SAP should change the marketing message. Personally I would accept some minor disruptions to use the full power of HANA - as long as SAP helps the ecosystem to overcome the problem.

The above mentioned changes don't deliver any business value - let me cite

thorstenster: "they are disruption without innovation." And it is even worse: SAP spread deletions in SPs and most customers don't expect it when planning a software refresh.

Best Regards,

Tobias

ttrapp · ‎2013 Jan 28

Well, I didn't provide a deeper look into FI-CA evolution in this blog - but I explained how I'm analysing changes form release to release: I'm comparing TADIR entries and I analyse the changes: Are there any new frameworks? Is there further development in existing frameworks? I think this will be very easy after the whole development landscape runs on HANA :wink:

Cheers,

Tobias

hofmann · ‎2013 Jan 29

"turned out as painful and without help from SAP it could have become a nightmare"

demotivating and motivating at the same time. Can you share more details on the help from SAP part? Normal OSS messages are backchannels?

ttrapp · ‎2013 Jan 29

I think I will provide details if everything is solved – it is still too early for a final summary.

But let’s talk about Business Suite on HANA: as you know we tested ERP and CRM on HANA as well as an Industry Solution, that is not yet released on HANA as well as a huge add on that never ran on HANA. In fact I was very skeptical and expected problems within all steps of the procedure: data export, HANA import, configuration of the application server, kernel changes, applying the latest HANA revision, the step to NW 7.4 and so on: this is a complex activity that but be mastered by applying best practices. I even expected that the new software would be error-prone but I was surprised: it is really stable and robust. This is really weird: for me HANA migration seems to be a routine activity that can be planned very well and mastered using best practices – but applying NetWeaver Ehps can be an adventure and sometimes scary.

And the biggest problem is that “disruptiveness” is a taboo – we don’t discuss it and therefore we don’t find good solutions. The problems has many aspects – and one of the reasons are overpriced consultants who want to provide a quick solution that breaks down after applying the next SP. What are the reasons? Those consultants have no clue about reuse and think random and reckless use of data elements and function modules is a good programming style: they don’t care about APIs or whether an application is released or not. They know that modifications are “bad” but they don’t fear to spread implicit enhancements all over SAP code although implicit anhancements are as bad as modifications. On the other side there are software bureaucrats who love to discuss naming of conventions for local variables and believe that this is the most area of necessary regulations: “Is lt_ a good prefix for internal tables? Is l_tas_ for sorted tables a better choice? But what about hashed tables with secondary index? l_tahs_ seems to be OK (or is it l_tah_s_ ?) but what about generated code?”. You may laugh but I heard that at DSAG people are working on those things. IMHO we have to focus on things that matter: non-disruptiveness, paradigms like “insight to action” and business value but not about ways to leverage software bureaucracy.

On the other side SAP has to change, too. SAP NetWeaver Development should adopt similar standards according robustness like SAP Business Suite. In fact we are already in discussion and perhaps in some months this can become a success story: "SAP, SAP Partners and SAP Mentors find a way to make software refreshes of SAP NetWeaver platform less scary and more predictable."

Cheers,
Tobias

ttrapp · ‎2013 Jan 29

You mentioned really important points. And yes, every software refresh is a technical disruption but it seems to me that SAP ERP development team did quite a good job and avoided drastic changes within the last years – even when developing ERP on HANA optimizations. From my experience SAP CRM 7.0 caused much more trouble, one important reasons have been missing features which came back later in SPs and Ehps. What is your impression? Can SAP improve the upgrade procedure – especially for CRM views and other objects?

Best Regards,
Tobias

stephenjohannes · ‎2013 Jan 29

The leap from CRM 5.0 and below to CRM 5.2/2007/7.0 was very disruptive. SAP however needed disruptive change or nobody would have been running the product right now. That being said when I piloted a move from 7.0 to 7.0 EHP1 it really was not that bad even though we had a lot of custom development on our system. The key was however that we did most of our UI changes the right way(as recommended by SAP) so the biggest issue was respository.xml comparison and adjustment which SAP made much easier between releases. EHP1 was pretty close to applying a support pack in terms of adjustments and the tools were much better for the CRM UI components compared to moving from CRM 52 to 2007 or CRM 2007 to CRM 70.

Now the issue is that you didn't follow the recommended SAP enhancement procedures your life will be made painful during an upgrade or applying enhancement packs. That being said a lot of customers/developers choose to think those rules don't apply to them and choose to do things the the wrong way, even though the right way is still available. Ultimately SAP needs to have a mechanism or way for customers who need to severely mod the system to be able to request SAP a better way to meet the requirement.

Take care,

Stephen

Former Member · ‎2013 Feb 03

I hear similar statements from our customers. How would you think a deep dependency analysis between the custom code and the standard objects help, not just at the code level but also at the DDIC level?

Do you think its the required support packs that cause the real issue or the true enhancement packs?

stephenjohannes · ‎2013 Feb 04

Actually it could just be a simple kernel patch that causes issues, even when you play by the rules. I have seen variations where standard ABAP commnds do not work as documented or e-mailing breaks due to kernel patch levels on the same release level. Now imagine a customer that applies a simple kernel patch to their system and finds that their custom code which uses no SAP delivered objects beyond the ABAP language does not work as expected.

Now let's compound that problem by applying code changes to SAP ABAP code and removal of objects and you can see the pain levels even in a system that was not modified. Part of the issue is that SAP never made good on it's promised to provide BAPI's and/or API's allow access to all of the data in ERP or even CRM. If one-order API ever was dramatically redone in CRM, most SAP customers will be in world of pain during an upgrade. It really has not changed that much between all the releases, so most of us bet that using it will still be safe.

So I guess the real solution for fixing this is one of two solutions

1) Provide a real API for all business functions in solutions and tell customers to use that

2) Provide some analysis tools that will customers to find stuff they are using that was removed and some type of tool that suggests alternatives.

Take care,

Stephen

Former Member · ‎2013 Feb 08

Hi Stephen,

sorry for taking a while to respond; looking at your problem areas, I feel that if you stay on the technical side a tool can detect a lot of the problems ahead of time, as long as they are caused by changes to the released ABAP code and DDIC objects. For kernel changes that break things there is not much you can do but believe SAP will not do this in the future - nothing will replace adequate testing.

For the technical side you can identify any referenced objects that has been modified or in the worst case deleted, with not all modifications being equal. If SAP changes the layout of a structure that you use, there is the possibility that it fails in your custom code. So finding out that a referenced object has changed does not do the trick but it's a starting point. The changed objects can also be in a on object that is not directly referenced but indirectly. We provide a service that can uncover many of these technical issues, we refer to it as out change impact analysis tool.

There might be significant functional impact based on a technical change as you mentioned but I don't know of a tool that can bridge the functional gap.
There are other tools like this out there. If you have used any of those tools can you share your experience?

Albrecht

stephenjohannes · ‎2013 Feb 11

Do you get the change impact analysis tool part of enterprise support or do you have to pay extra on top of that? I know you can't comment completely on pricing pieces, but if I were SAP I would throw in a complementary use of this tool for every customer who decides to migrate their business suite applications over to SAP HANA within the next year or two.

That would be an awesome way of SAP saying that we are going to prove it is not disruptive and if does cause technical disruption we are going to help you minimize the impact so it you will be successful. Yes I know it might be lost revenue for SAP, but the long term good will of many customers using the suite on HANA would greatly make up for any revenue lost.

I agree that the functional ramifications can't be predicted, but for most customer systems it's all the custom code that causes you all the headaches during an upgrade/enhancement pack cycle. I'm am at least glad to hear such a tool is available and I will have to keep that in mind the next time my company looks at applying an enhancement pack.

Take care,

Stephen

Former Member · ‎2013 Feb 25

Hi Tobais.

Its a interesting blog, and chimes with what we have been experiencing as customers with regards to enhancement packs.

Enhancement packs break things unexpectedly within core functionality, which is against SAP's marketing message of "innovation without disruption"

For instance ERP on HANA. We would have to upgrade to EHP6Hana edition. This would involve a full production system copy, and a methodology similar to upgrades.

There is a LOT more work for customers with regards to the application to Enhancement packs than SAP would like to admit.

This is why Panaya are doing very well at the moment.....

Even though technically the process is much, much better than ever.

James

Private_Member_12087 · ‎2013 Aug 13

Hi Tobias,

5 stars for the statistics and analysis. As physicist (retired) I like your approach.

Best regards,

Martin