If S/4 isn’t yet on the roadmap, it’s on the horizon
Through a combination of carrots and sticks, SAP ERP customers are being slowly herded towards S/4 being the Digital Core, even if at the same time many processes move out into the pure cloud space of Ariba, Concur, SuccessFactors etc. This is going to be a significant project affecting the vast majority of SAP customers in the next few years. And the increased cost of the hardware per GB means effective landscape management can save significant costs, both on the project, and the follow-on running of the system.
Many of our Data Sync Manager™ (DSM) suite clients chose to buy DSM as part of a major project. Often this would be when, early on, the project highlighted the risk of old test systems with inaccurate data. With many organisations planning to start their S/4 journey, I wanted to share how being a DSM client can help, before, during and after your S/4 migration; possibly the biggest SAP project you have on the horizon.
Before: Leave your excess baggage behind
A lot of organisations have a sprawling SAP non-production landscape. Some systems are old copies of production and some multi-client systems are relics of old projects long since completed. Over the last 20 years, enterprise-grade storage has become cheaper and more manageable. As a result, SAP landscapes have been allowed to use ever more space. Knowing that S/4 is looming, with in-memory database technology being much more expensive than disk, now is the time to lose the excess baggage. And, at the same time, ensure you have good test data for every part of the S/4 project, however you choose to approach it. With DSM you can spin up new system shells, populate them with lean clients containing masked data and use these to replace existing test systems. Alternatively, you can use the powerful client deletion capability of Client Sync (part of the DSM suite) to remove redundant clients and delete ones you want to reset with good data. Find out how to Uncover invisible SAP test data to recover costs.
Before: The pre-project activities
The more complex nature of the S/4 migration compared with previous upgrades means organisations are looking more widely at exactly what it is they’re taking forward. Some preparation steps, like the Customer Vendor Integration, can be done ahead of time – but this can also prompt musings around that long-discussed (never committed to) data cleansing project. Even if it is decided that Greenfield is out, there may well be some quick wins from clearing out historical duplicates or improving consistency of how data is stored. DSM can help bring real data-sets into development and testing systems, and even allow the cleansing procedure to be processed repeatedly by resetting the data from files.
Before: First big project since GDPR? ‘Privacy by design’
The combination of technical and functional activities involved in this project may mean a broader group of providers (SIs, functional consultancies, testing specialists) having access to your development and test systems. If this is your first major project since 2018, and you have the data of any European Citizen, then it could be your first taste of ‘Privacy by design’. Article 25 (Data protection by design and by default) of the European General Data Protection Regulation (GDPR) asserts that considerations like data minimisation must be considered in any new project, and that personal data should only be processed by persons where it was necessary to have that personal data for the processing. Any activities on test or development systems using real personal data will likely fall foul of this. And although GDPR has been the headline-grabbing legislation, there is similar new or updated legislation in other countries, and many predating laws, including the Australian Data Privacy Act.
During: Pilot project
SAP recommends a Sandbox first before your project starts in full. Read more about what happens in that sandbox here. The more accurate the sandbox is the better but the bigger the system will be and the larger the HANA appliance. Use DSM to build a lean, dedicated sandbox for the project and consider the cloud, given that the duration of the sandbox project is not clear and the business has to be supported in the meantime.
During: Rebuild non-production from new production
For anyone taking the Brownfield approach, I would recommend considering how wide the gap is between the configuration, customisation and code in the development system and production. Over the years, that gap has got wider and wider with old Z code abandoned, configuration taken to QA and then the project cancelled, and even third-party add-ons loaded in development but never uninstalled. Our migration teams use DSM to rebuild a new non-production landscape from the production system, as part of their cloud migration strategy. This could also be part of your S/4 migration approach.
Rebuilding development and QA from production means a cleaner start on the other side, with a smaller gap between development and production, so less chance of defects sneaking through. Some organisations have even done this with full copies as part of their migration then discovered the costs on the other side when it’s already too late. Presumably, the reduction in the volume of custom code to be refactored is a strong driver for this. Using DSM to build out smaller new test and development systems can bring the same advantage in closing the gap between development and production, and reducing the amount of Z-code to rework, but at a fraction of the cost, since smaller appliances can be used.
During: Hybrid cloud landscapes – the perfect use case
With the ability to mask data on exit, you can also consider keeping a production environment on-premise and moving all your non-production systems to the cloud. Those are the systems that can benefit most from the elasticity of the cloud resources. Power up the systems during key project phases; switch them off when they’re not required. With Object Sync and Client Sync (components of the DSM suite) keeping test data up-to-date, there is no real person or sensitive data leaving your network.
After: TDMS not supported on S/4
Once your S/4 dreams have been realised, this will not be the end of the journey. The functional teams will want to embrace S/4 as the digital core to the intelligent enterprise. There are likely to be many follow-on projects leveraging the possibilities of AI, machine learning, etc. as your business looks to find, or keep, the competitive edge. All of those projects will need accurate test data and an agile non-production landscape. The much-maligned TDMS solution, which led many of our clients to find DSM in the first place, does not support S/4, and from the changes we’ve made to our architecture over the last four years to handle new technologies used by S/4, it’s hard to see how it ever could. DSM is used on S/4, is supported on S/4 and is certified on S/4.
After: Don’t let the non-production appliances grow like production
Even with some processes moving out to pure cloud solutions, the Digital Core will begin to grow again on the other side. As the production appliance needs to scale up or scale out, the development and test system hardware can remain in situ much longer. Client Sync allows a time-slice of the most recent transactions for test and development systems, so unless the volume of transactions in the last X months is becoming much bigger than the previous X months, or the volumes of master data are skyrocketing, then your non-production systems can grow at a much more leisurely pace, and therefore stay within their hardware sizing longer.
Start on your robust test data management journey
EPI-USE Labs is offering a free readiness report to validate your SAP system size, footprint, supported objects and more, to help you rationalise and secure your SAP landscape.
What does the free Readiness Report provide?
- Visual and interactive insight into your SAP systems
- Data volumes, largest tables – highlighting potential space savings
- Custom tables, Active BADIs, business functions in use
- Used Objects supported for Data on Demand copying
- and much more…
Author: Paul Hammersley
Bio: Paul has for many years been a remarkable technical force at EPI-USE Labs. As SVP of the ALM Products, his portfolio includes System Landscape Optimization, and his hands-on experience of implementing Data Sync Manager and helping clients to manage data across the breadth of their SAP landscapes is unique. He has specialised knowledge about data security and how GDPR (the General Data Protection Regulation) impacts companies running SAP.
This article is sponsored by EPI-USE Labs
