How to keep the core clean, when the tool many customers used for that is no longer there in S/4?

[Siarljp]

As an SAP customer, we are on a journey to S/4 and I plan to run a blog series surrounding some of the challenges we face, and how we intend to solve them. Today we focus on "Keeping the core clean". Future blogs will take a look at how to manage agile development, and topics around SOLID and ABAPUnit amongst others.

 

Like many SAP customers we are on a journey towards S/4.

Occasionally as a customer of SAP's you need to make changes to a SAP standard object, sometimes this is due to manual implementation of an SAP note, sometimes it is part of SPAU / SPDD / modifications. If you want to have smooth upgrades it really pays to limit these kind of changes as much as you possibly can. Developers can also be tempted to change SAP standard code to deliver on requirements they receive. It pays to have processes in place to control these changes. When you are in an organisation with hundreds of active developers, this becomes ever more challenging.

One item we have recently noticed in our journey to S/4 is that Object Access keys are now going the way of the dodo (we knew and accepted that dev keys were going, but object keys, that initially seems to be a contradiction to a key message from SAP themselves). The entire modification assistant is simply turned off by the developer at the click of an icon.

Since the Björn Goerke keynote speech at SAP Teched in 2018 and then repeated yearly at subsequent Techeds, SAP have been heavily encouraging their customers to "Keep the core clean" and rightly so! Modifications get in the way of upgrades, and can lead to many subsequent maintenance issues.

From my personal experiences I know that many customers have been attempting to do this for a considerably longer period of time, my own experience (which dates back to the early days of SAP R/3 and before that)  one of the primary ways customers of SAP use to control that developers don't modify the heck out of the SAP standard code base, was by the issuing and control of object keys, this I saw consistently across many different SAP engagements.

Unfortunately with S/4 this mechanism is extinct. SAP themselves only ever saw the object key as a way to manage licensing (this confirmed with our SAP RIG (SAP S/4 upgrade specialist) team contact), and did not apparently realise that customers had this secondary usage (in SAP's eyes); to the customer's eyes it was more likely the primary usage of the keys. This message is again confirmed in oss note 2309060.

To be fair SAP have a point, once a key was issued you could not revoke it, but during upgrades keys often were reset (blanked), and so the mechanism was quite effective, and in my experience used widely by many of their customers to successfully prevent modification to SAP standard and so keep the core clean by effectively blocking a developer until they had a key. On a recent customer code lifecycle management survey SAP were very complementary as to how we as a customer have succeeded in limiting modifications, again showing the success of this limitation approach, the approach provides a lock, that developers must unlock before proceeding to change an object for the first time. It was a good trigger point for a process check to ensure that the change being attempted was the correct change to make.

Now with S/4 the official message from SAP seems to be as follows, to keep the core clean you control modification through user roles. S_DEVELOP and S_TRANSPORT, all modifications can be tracked and are visible in SE95.

This raises new challenges, S_DEVELOP allows you to create a selection based on an object key, and so in the user role you can define DEVCLASS, OBJTYPE, OBJNAME, P_GROUP, ACTVT.

For S_TRANSPORT - you can place your limits around the type of transport request being released, so a Repair or a workbench or customizing change (so in other words not very granular). You could prevent all modifications or allow all modifications for a user that is assigned to this.

This all means to achieve an object level check prevention that we had in the past, that user roles for developers now risk become incredibly long and complex. A developer requesting to change an object is now essentially asking for additional access, for each and every object that they need to change. They need to engage with the roles and authorisations team, who then give a temporary access to just the objects requested, by creating an additional role just for the specific request. This leads to a lot of work, for the authorisations team, for reporting on the authorisations, and so delays for the users. I an agile organisation with frequent deployments its really not a desired outcome to create artificial delays.

If that all sounds impractical, I think that is because it almost certainly is. So then the question comes, what are the alternative ways to approach this?

A possible approach could be to introduce a ban to all changes to standard objects? This will soon clash with the reality that SAP notes often require object keys in order to implement them for various reasons. What if the SAP note is a critical security change? what if it is a legal compliance issue? What if it is a pilot note that SAP offer you as the only way to deliver critical functionality? In addition a ban would also need to de-implement all modifications you have made historically before starting on the ban. In conclusion, I would strongly argue this is completely impractical to most SAP customers.

So how to keep the core clean and control at an object level when SAP mostly offers only the authorisation approach?

Perhaps the best approach is to catch the object change as it is being saved, and so to prevent save of changes to standard objects until that object change is approved. This all points to a custom code solution to achieve the lofty goals set by SAP in teched 2018 and onwards. (It would be really nice if there was a standard solution here (hint hint)).

We identity the classic BADI CTS_REQUEST_CHECK->CHECK_BEFORE_ADD_OBJECTS as a place to block and potentially register object level changes prior to saving them in a transport request, and so a custom solution to achieve what used to be standard. Then we could introduce a ztable, where all object requests are stored, a notification mechanism on this table, and a process to approve based around this. Its not ideal but it should work, we wonder if anyone else has a preferred approach to control modifications to standard and so keep the core clean?

The real irony here seems to be that to keep the core clean, we need to make an enhancement to implement a custom solution (head spins).

We would be very interested to hear any thoughts around this topic, and I hope you can continue to follow this blog series in future where I will continue to highlight some of the challenges we see during our move to S/4.