Technical Articles
How to keep the core clean, when the tool many customers used for that is no longer there in S/4?
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.
Yea, well, clean does not imply empty. It is possible to have a lot of things, while still keeping it clean.
In my opinion its more important to #keepTheCoreMoving than #keepTheCoreClean, as a business you need to change stuff to deliver stuff.
Modifications are not good, but probably better and easier than building a new application from scratch.
Sure but in our case we have over 70 independently operating agile teams each of whom is capable of potentially modifying standard, with a subsequent risk of impacting any number of other teams working in the same central system. So some controls are needed to prevent agility turning into chaos. I agree with you modifications are not good, but often not optional, but its good to evaluate and take care over each one with a similar quality process.
agile <> anarchy 🙂
And every team still have tests running to make sure their product is working
True but automated tests do not protect against design oversights, and tightly coupled mods are often the quick and dirty solution when a less tightly coupled design is possible, just not being considered. The object keys in the past have helped as a guardrail to identify when these tightly coupled alternatives are chosen, and now they are gone.
Lars once made the very valid point that "keeping the core clean" is not the same as "keeping the core empty"
My house can still be clean despite the custom furniture I have installed.
In the same way provided - and this is the key thing - as Lars said - if you have automated unit tests running over everything - then what is the problem?
Even in ECC 6.0 you can - and should - do unit tests on user exits.
If you have 70 teams all possibly interfering with the same system then that is the best argument I have ever heard for automated tests ever. Go ahead, tell me I am wrong.
Paul Hardy in my career as ABAP developer I have yet to find a customer installation (out of more than 50 different companies) that has automated testing in place, except perhaps those supplied by SAP or external projects such as abap2xlsx. Only one customer had locks in place to prevent creation of CRs without a corresponding internal ticket but that was it: it would be nice to have but I can understand the appeal of object access keys or equivalent solutions via BADIs, they help with damage control 😉
My experience is similar here, automated testing is sadly more the exception and I think the reason is managing dependencies is more complex than it first seems. That said I absolutely see ABAP Unit as the way to go, but working out how to get the best out of it is the real challenge, and then communicating that. The test double framework introduced in S/4 certainly really helps, but so does combining it with an older tool (SCAT) to enable the building of test data libraries (more on this in a future blog hopefully).
My impression - as documented elsewhere - is, that at a typical SAP customer (not third party software company!), unit tests are not cost-efficient, except for maybe some small parts of the codebase.
By the way, are we talking about unit tests over SAP coding? For modifications, unit tests over Z coding are not very relevant.
Hi Edo, my blog was talking about modifications, and how to manage those now S/4 is coming without any object key hurdles, so developers can just click and modify. The suggestion/supposition from Paul I think is that all modifications should have ABAP Unit tests provided, which I think in a parallel universe where all developers understand ABAP Unit, and where everyone does everything by the book, would be very nice.
We are trying to encourage ABAP Unit adoption, but in our case, it is in its infancy in terms of code coverage currently, and so its not really a pragmatic suggestion to say just unit test every mod, it is a good end goal I think, but requires quite some refactoring from our current solution, and I suspect we are not so unlike other SAP customers (given what we have learned talking with SAP in the custom code lifecycle management service).
Hm, I don't understand it. To manage those modifications that come in without any object-key hurdles, unit tests won't help. (Except, if they test whole standard processes, but then they aren't unit tests any more).
Enforcing all modifications to be just one-statement method calls, and then requiring unit tests for those methods, that is a nice idea. (Although again, I am not sure whether it is cost-effective at a typical SAP customer.)
Unit tests are never intended to test the outside environment, but the unit of custom code, so then you need to isolate the custom code, done by encapsulating it in a class with an assigned interface, I try to encourage our developers to encapsulate their enhancements, but you are right in that this is challenging and not possible in all circumstances. Then with encapsulation you can at least test changes to the unit based on assumptions of pre and post conditions for given test cases. If you need more advanced functionality you can also define your own badi definition (assuming this is not in a standard badi location). Then its often impossible to create test cases for everything condition that can arise for a tightly coupled modification deep in SAP standard code. So there are usually ways to code mods in a smart way, but I still argue its better to take a step back and consider if there is a way to design a loosely coupled solution. For instance perhaps look for an event that can be triggered on the update, and then from that event perform the update you need.
While I am on the subject the "keep the core clean" thing as far as I can see is exactly the same as in 1997 when I started with SAP and was told it can do everything you want, and with the IMG and a little tiny bit of Z code you will be right.
Every single customer fell for that back then, and - 20 years later - every single customer ended up with a bucket load of custom Z code and user exits and core modifications like the stars the sky.
Now in 2022 we are getting the exact same message again, word for word.
Thanks for the comments and considerations Paul, much appreciate receiving your valuable insights (now the owner of 2 of your tomes). We are certainly targetting ABAP Unit as a key skill and I am actually in the process of preparing training material around this. I know the opensap material is also very good here, although a bit dated, but there are some additional challenges and messaging we need our developers to understand and follow. There are plenty of challenges to fully automating your unit testing, its not like flicking a switch (as I'm sure you are aware), and the first challenge for us is education. I also agree on the modification messaging from SAP, it has always been there, but if we give our developers a free reign and just rely on unit tests, I fear they will adopt modifications when a prefferable less tightly coupled alternative is possible, but just not considered, because modification is quicker, requires less design thought, and returns results faster. We often see the need for a design intervention, to show that a more loosely coupled SOLID solution is preferable, but these solutions take more effort and knowledge. The object key in the past for us has been a guardrail to warn on these tightly coupled implementations, and triggered a process of consideration, sometimes we have accepted the mod is the way to go, and sometimes we can point to a more sustainable solution.
So just to reiterate, the reason we need some kind of controls around the modifications, is not to totally keep the core clean, but it is to act as a review point, to consider lower coupling alternatives. In our experience tightly coupled solutions are usually simpler to implement (and so preferred by devs under time pressure) but incur a higher long term cost.