Handling Custom Code
In the first 2 parts of this series, I covered the following aspects of a transition to S/4HANA:
In this final part, I will talk about handling of custom code and the development and deployment of future S/4 landscape change.
SAP Custom Code
Historically, one of the reasons why SAP is such a dominant product today is linked to how flexible and relatively easy it was to extend or adjust the product to meet every customers’ needs. This was possible via the inbuilt ABAP programming language and has led to the creation of tens or hundreds of thousands of custom objects and millions of lines of custom code in many of the world’s largest SAP customers.
This double-edged sword is now one of the key challenges facing customers as they approach their S/4 transformation, as much of the custom code which was necessary during initial deployment and ongoing continuous improvement represents one of the biggest barriers to simple S/4 transformation.
Custom code could even be a key factor in determining which transition approach is right for each customer landscape. High amounts of relevant custom code, for which the customer does not want to transform their business process or move back to standard, would be a reason to go Brownfield or Hybrid (see part 1 of this series for more details). Conversely, a huge amount of unreliable custom code with poor documentation and loss of knowledge could be a reason to start again and go Greenfield, with a goal of leveraging standard SAP best practices wherever possible.
SAP recognizes the importance of custom code and the fact that it is a barrier to S/4 adoption, so they have many tools which can be used to better understand what custom code exists, whether it has been deployed and whether it is being used (if so, how often and by whom), in addition to whether it is of the right quality and whether it will work with S/4HANA:
What to do with your custom code
Once you have made a decision on the approach to take for a particular landscape, you need to decide how to handle the custom code. In many cases if you are going Greenfield, the simplest and most cost effective approach will be “if it ain’t broke, don’t fix it” – leave it to die in the ECC system or only refactor / clean-up those selected custom solutions which need to be maintained. They can be “lifted and shifted” to the new S/4 development system.
If, however, you are planning a Brownfield or Hybrid approach (based on shell creation), then it is important to better understand the custom code and to cleanse it. By cleanse, I mean remove code that isn’t needed. Most companies only use <40% of the code they have created and even then, there could be code branches which are no longer relevant.
In the case of shell creation, this clean-up can be done in the new shell system, but in Brownfield it needs to happen in the current landscape (at minimum the removal of no longer required objects), and the sooner the better. This work could take months and will hold up your S/4 transformation so I’s best to begin as soon as possible.
Making it work on S/4
In order to have a healthy S/4 system running with custom code that was originally designed and developed on ECC, it is important to understand that there are 3 different types of work to consider regardless of the approach and the amount of custom code that has been retained.
Functional – The first category is to ensure that the custom code still works with the core system and has not been affected by changes to the solution which SAP documents in the Simplification List. Functional changes cannot be automated and must be analyzed to adjust based on what was originally intended and how the new system functions in that process.
Technical – HANA itself is one of the more obvious technical changes that are required. If native SQL has been used or if ordering is assumed in the response from the DB, then changes may be necessary.
Performance – Lastly, to take advantage of running on an In-Memory database, code can be re-written or adjusted to allow some of the functions to be performed at the DB level (code pushdown) so that the new platform can be fully leveraged.
There is a lot more detail in the following SAP blog.
Depending upon the amount of custom code, the impact of the simplification DB and the approach being taken, the amount of work in custom code adaptation could be extensive. Services exist which can accelerate/automate this to a large extent – for example smartShift. Significant custom code remediation coupled with a lengthy dual maintenance process and high volumes of change demand an automated solution for change control and governance, like ActiveControl from Basis Technologies. ActiveControl can integrate with smartDeploy from smartShift to ease the merging of ECC and remediated S/4 code throughout the transformation to S/4.
Future S/4 Landscape Complexity and Volume
Personally, I see the following drivers within future S/4 landscapes which will mean higher volume of change being managed across more people, with a higher degree of orchestration needed than is the case today:
The pace at which SAP is releasing updates for their S/4 solution is higher than at any point in history. Annual releases (1511, 1610, 1709, 1809, 1909, ..) and bi-annual Feature Pack Stacks (FPS) make the ability to efficiently upgrade and stay current more than important ever before. It could even be necessary to consider an upgrade during your S/4 migration.
Staying current will also allow for a reduction in the amount of custom code that gets developed, as hopefully SAP is building out new S/4 features in areas which can be leveraged to avoid custom solution development.
In addition, the demand for agility in a future S/4 system will continue to grow despite higher change volume and higher business risk of failed changes.
In this context, automated regression testing could be a key enabler to stay current as efficiently as possible. Basis Technologies has a solution for this – Testimony. If fast, continuous, safe SAP change and release appeals to you, request a free demonstration to learn more about how our software can help you to achieve it.
Summary
I hope you have found this blog series useful. Feel free to reach out to me with questions/comments. If you would like a discussion on your specific plans and challenges around moving to S/4, or would like a demo of how our solutions could benefit your transition and ongoing operations, please get in touch.
Other related Basis blogs:
- Considerations when moving to S/4HANA – Part 1
- Considerations when moving to S/4HANA – Part 2
- eBook: Accelerate Your S/4HANA Journey with Automation
- Why SAP Automation Is Crucial When Adopting SAP S/4HANA
- What to consider for your journey to SAP S/4HANA
- 4 steps to a clear S/4 HANA migration strategy
- Use a Dual-Track Approach to Make SAP Upgrades Easier and Lower Risk
