1. Your <a href="#technical_debt">technical debt</a> is out of control, and it takes you weeks to move transports to production.
2. You use <a href="#sandbox_systems">sandbox systems</a>, but they take a lot of time and money to provision, only to have the data quickly become stale.
3. Your <a href="#project_based_development">project-based development</a> has numerous challenges, and you never ship on time.
4. Your <a href="#transition_to_hana">transition to S/4HANA</a> will take years and require significant effort from your already overburdened team.
5. You need to <a href="#validate_processes">validate processes</a> but are restricted by the system landscape.
6. Testing <a href="#cross_system_compatibility">cross-system compatibility</a> is unattainable.
 
 
Chances are you have at least one of these pain points in the SAP space. Luckily, we can mitigate or eliminate these issues with modern technology.
 
Please post in the comments if you would like a deeper dive into any of these issues.

<h2 id="technical_debt">Technical Debt</h2>
 Problem 
Technical debt is primarily due to the centralized architecture of SAP. Centralized development is when all development and configuration occur in a shared system. This shared space introduces numerous challenges. 
<ul>
 <li>The quality of the data quickly degrades. </li>
 <li>To test your results, you need to move your code or configuration back and forth from DEV to QAS.</li>
 <li>It's challenging to update existing code since you don't understand the implications. Instead, you add to it, making it more complex and keeping obsolete code buried in your system.</li>
 <li>Changes are in disparate areas (data dictionary, report, class, methods), making it difficult to conduct peer reviews.</li>
 <li>Static analysis is tedious to set up, and manual checks are slow and error-prone. Think of anything hindering your workflow, and you accept it as "this is the SAP way."</li>
</ul>

 Solution 
Modern development relies heavily on testing, which requires ephemeral systems. Ephemeral systems are used for a specific purpose and can live for as short as a few minutes. Consider an SAP system that spins up in three minutes, runs unit or integration tests, reports the results, then is deleted. This system likely ran thousands of tests and modified the database, so it should be short-lived. Implementing this type of modern architecture requires the use of containers. 
 
With containerized SAP, you can implement a modern workflow. Your workflow should facilitate peer reviews, run static analysis, validate that unit tests exist and are passing, and merge the code to the main branch of your code repository. Applying this workflow to a feature or bug fix is a pipeline. CI/CD pipelines are popular because they help create higher quality code and deploy faster. CI/CD has been around for over a decade, but it requires ephemeral systems to implement, so it was not previously possible for SAP. Well, it is now. 

<h2 id="sandbox_systems">Sandbox Systems</h2>
 Problem 
Sandbox systems are a stepping stone to maintaining a clean system landscape. Typically, sandbox systems are refreshed once per year to facilitate access to high-quality data in an isolated environment. However, this is still not frequent enough, and it's a time-consuming and expensive process. Since users know that they can try anything in a sandbox, the system requires more frequent refreshing. It also involves a considerable manual effort to port the changes from sandbox to development.
 
 Solution 
You need a consistent way to "refresh" the system and keep the data up-to-date. However, you should also have a way to allow users to keep their changes. The last thing you want is a system refresh that wipes a week's worth of development. Do not worry; modern development has a solution for this too! You should be using containers for your sandbox systems. With containers, you can perform a "refresh" in minutes to restore the sandbox to its original state and revert any data changes. Development and config can be saved using abapGit and restored after the "refresh." You can also maintain recent data in your container system by leveraging tools such as SAP TDMS or other available third-party tools. These tools allow you to time slice data from production to keep your containers up-to-date. Using these tools, you can even anonymize/scramble sensitive data to ensure security compliance.

<h2 id="project_based_development">Project-based Development</h2>
 Problem 
If you've been on an SAP project, you've experienced at least some of these issues every single time. 
<ul>
 <li>You run into object locks with other developers or team members.</li>
 <li>You have trouble getting consistent data to test your features.</li>
 <li>You keep a spreadsheet with a list of transports for production.</li>
 <li>You have to handle failed transports when moving to production.</li>
 <li>You experienced project delays.</li>
 <li>You have to implement a code freeze during User Acceptance Testing (UAT).</li>
 <li>You have trouble fixing production bugs found in locked code for the current project.</li>
</ul>

 Solution 
If you've read these headaches in order, you'll notice I'm starting to sound like a broken record. All these issues stem from the fact that we're trying to run billion-dollar companies using a shared system! Using SAP containers that run in the cloud, you should be able to provide systems for each project team where they can do all of their development and testing. Once the project is ready for UAT, you can move it to your central landscape, but at this point, containers allowed you to perform such exhaustive testing that UAT is nearly error-free. You can even provision production replica containers for your UAT team to work as efficiently as possible. Since the container systems run in the cloud, you provision them on-demand and delete them when the project is over. 

<h2 id="transition_to_hana">Transition to S/4HANA</h2>
 Problem 
Upgrades are challenging. Everything from setting up the system to ensuring it performs as expected becomes a daunting task. Significant changes in the system mean that you will make errors. You are also starting fresh, so you do not want to repeat yesterday's mistakes. The good thing is that you know your expected results, and you can improve on the status quo.
 
 Solution 
Leveraging the concepts covered above, you can use this transition as an opportunity to stop banging your head against the wall. This is the perfect time to implement better workflows and improve your system landscape. This approach requires using containers to allow teams access to sandbox systems, implementing CI/CD pipelines, and creating a culture where you encourage automated testing.

<h2 id="validate_processes">Validate Processes</h2>
 Problem 
Your QAS system and PRD system are likely very different. You have probably experienced production issues that you cannot replicate in QAS. Or maybe you want to validate processes in a production replica before you perform them in production! Process validation was previously just wishful thinking but containerized SAP makes that possible. 
 
 Solution 
Containerized SAP with the latest production data using a tool like SAP TDMS or third-party solutions makes this a realistic option. Validating processes in an isolated system can help save a lot of effort and headaches and ensure business continuity. 

<h2 id="cross_system_compatibility">Cross-system compatibility</h2>
 Problem 
If you're an SAP partner and building solutions, you need the ability to validate that your solutions work on a variety of systems. Validating across systems is a costly and resource-intense process. You might have created your solution on ERP 6.0 Ehp7 on an ASE DB but need to test ERP6.0 Ehp8 on HANA and S/4HANA 2021. 
 
 Solution 
You should only run systems when needed. By running containerized versions of SAP, you can achieve this. You can improve the quality of your solutions while not spending your entire budget running systems full-time and starting with configured systems that include data.

 
If your first thought of the headaches listed here is "that sounds nice, but it's too expensive to adopt," you're wrong! The flexibility and system requirements of containerized SAP cloud systems also mean that they can be significantly more affordable than typical setups. So you get better functionality while spending less!

Learn how modern technology can help you solve these issues.

Chances are you have at least one of these pain points in the SAP space. Luckily, we can mitigate or eliminate these issues with modern technology.

Top 5 Development Headaches and How to Make Your Life Easier

Learn how modern technology can help you solve these issues.

Interested in learning more about DevOps for SAP?

Related Articles

Our Journey with SAP ERP DevOps

A Practical Guide to DevOps for SAP ERP

Infrastructure as Code, DevOps, and the Future of Enterprise