Landscape and Test Data Management requirements in an S/4HANA world

In a recent webinar and white paper, I looked at the changing role played by the non-production systems before, during and after an S/4HANA brownfield migration, or indeed a selective data transition. This focused first on the sandbox phase where something highly representative of Production is needed, then on the build out of a new development for the S/4HANA system, based on Production not the legacy development environment. I then looked at the paradigm shift in SAP on-premise (now referred to as Any Premise) upgrades once you have joined the S/4HANA conveyer belt.

Now I’d like to expand on the interaction of this new S/4HANA landscape with the new cloud solutions.

Embracing cloud

Let's start by looking at why there are likely to be integrations to other SAP solutions which are not on-premise. There are three main reasons why organisations are embracing what I refer to as ‘pure cloud’ solutions (as opposed to on-premise solutions being hosted in a public or private cloud).

Business demands:

Over my career, the relationship between the business and IT teams has changed massively. When I first started out (and yes it was this millennium, but only by months), the IT Director called the shots. She or he chose the software, the Systems Integrator, etc, and only called on the business for design workshops and User Acceptance Testing. The business didn’t have their own server room; they didn’t have the knowledge to set up hardware and install software.

Now, the business can go out and procure a solution in the cloud and completely blind-side the IT department, and I’ve heard many cases of that happening. So the ability provided by ‘pure cloud’ to allow businesses to drive has also given them a much stronger hand. So the CFO, COO and other senior people in an organisation are looking at what the latest technology is to try to give them the edge, and if that is Salesforce or Workday or whatever it may be, they want to be using it. The process of moving to those solutions may not be quite as easy as they are led to believe, and the compromise that gets thrown up is ‘Let's move to S/4HANA but take SAP’s alternative to Salesforce and Workday so the integration is easier (or even consider Rise with SAP and have one throat to choke), and move significant business processes from our legacy SAP ERP system to the cloud, and then integrate back to the digital core’.

Cost models:

Anyone responsible for a budget likes to have predictable repeating costs which allow them to plan. The variable costs of housing an ABAP stack SAP system on a hyper-scaler cloud platform, or even hosting your own servers and paying for hardware, system admins, network admins etc, are not as desirable. By slowly moving everything to a subscription model and paying for the service, not the consumption, it becomes much easier to budget and plan. Any major variation in the cost will come with a variation in the service which can easily be passed on to the business.

Functionality:

Some current functionality in any given SAP ERP system may no longer be supported in S/4HANA, or may be supported until 2025 via compatibility packs. This may lead to a consideration of an alternative process in one of the cloud solutions, which could then bring more processes into potential scope for moving to the cloud. Allied to the first point here – the capability to leverage the latest technology such as machine learning and AI is easier to access from the cloud. Similarly, the impression given is that analytics across the enterprise will be easier from the pure cloud solutions.

Re-thinking the role of the ERP system

The weight of those drivers will mean that over time, more and more processes will find new homes in the cloud. Which means the SAP system becomes the backbone and needs to be incredibly stable as the source of financial truth for the enterprise. It will also need to be available whenever a satellite solution calls, and the integration must be robust. Any change to the backbone for one linked system will need to be analysed for potential impacts for any data flows coming in and out from all the others. Fortunately, SAP ABAP stack systems have a tried and tested change management system which ensures reliability of the production system, and visibility of the journey of a change through that system. How companies use that functionality does vary; some favour release cycles where a pre-production acts as a sealed testing area for a set time before the whole release can flow to Production, others have parallel development tracks for projects compared to BAU. Smaller companies typically run BAU via a ‘change committee’ or ‘steering board’ and handle projects separately through the same track. What was the best approach for SAP ERP for a particular organisation may not be the best approach in S/4HANA, particularly where there are new integrations to cloud solutions. The reason for this is the release cycles of pure cloud solutions.

In 2019, these nine cloud products had a combined 17 unique weekends in which they released impactful productive code to customers:

• SAP Ariba
• SAP C/4HANA
• SAP Concur
• SAP Digital Supply Chain
• SAP Fieldglass
• SAP S/4HANA Cloud
• SAP Analytics Cloud
• SAP Cloud Platform
• SAP SuccessFactors

Source: https://news.sap.com/2019/12/sap-release-dates-cloud-harmony/

There are two big challenges here for system stability:

• The company can’t adjust the date of the update; in the old world the company chose when to apply upgrades or support packs and had some leeway in the exact timings.
• Two systems which talk to each other both receiving updates on different weekends can mean a period of time where their integration is broken, either directly with each other or via their integration to the digital core.

SAP did recognise this, and moved to four maintenance weekends for those solutions in 2020, but customers might themselves want to consider when they patch their S/4HANA system to align with cloud updates. But it may go further than that. Organisations which didn’t previously use a ‘Release’ approach for change management in SAP might now wish to adopt one and use the ‘preview’ periods in cloud solutions to run ‘end-to-end’ testing before everything goes live in conjunction with cloud solutions.

Change management and test data availability

Aligning release cycles and schedules is all well and good, but what about the mechanism for controlling change through the landscape? And what options are there for provisioning data which is representative of how it will be in Production when the change gets there? In S/4HANA, we have the same capabilities that have always been there, both standard SAP and third-party for both. SAP Transport Management System and Client/System copies respectively each have third-party alternatives that sit inside, or integrate with ABAP.

But what of the pure cloud solutions? Do they have the same capabilities? I’m now going to look at two examples: C/4HANA and SuccessFactors.

C/4HANA

What is C/4HANA?

Firstly, we need to define exactly what C/4HANA is.

This excellent blog from Gavin Mooney explains the names and origins of the five solutions which C/4HANA comprises: SAP Customer Data Cloud (based on Gigya), SAP Marketing Cloud (previously Hybris Marketing Cloud), SAP Commerce Cloud (Hybris commerce cloud), SAP Sales Cloud (combination of SAP Hybris Cloud for Sales, SAP Subscription Billing and CallidusCloud), SAP Service Cloud (Hybris Cloud for Service, SAP Customer Engagement Center and others).

The last two are what was previously packaged by SAP as C4C. Also worth noting: only the last two (SAP Sales Cloud and SAP Service Cloud) aren’t alternatively available on premise.

C/4HANA: Change Management

With the multitude of solutions, it’s not surprising that we need to break this down in to different sets:

SAP Sales and Service Cloud

There are two capabilities available via the Service Control Workcenter. The first ‘Copy solution profile’ allows you to copy all the Business Configurations from a source to a target tenant. This would typically be done at the start of a C/4HANA project to provide a testing environment. There are plenty of activities required during a C/4HANA implementation that are not included in the Business Configuration work center and previously had to be manually repeated in each tenant. These are now covered by the second capability: Transport Management. From the naming conventions used, it's quite clear where this idea came from! Transport routes are created and then Transport requests can be created for Adaptation Changes, Business Roles, Language Adaptations, Local Form Templates, and Mashups.

SAP Customer Data Cloud

The Gigya Console provides the option for Copy Configuration, but this is typically used between two production ‘sites’ (sites being the term used rather than ‘tenant’). Customer Data Cloud is much more of a black box. You develop outside the solution on other platforms that leverage APIs to integrate with it. So there simply isn’t the same concept of test systems and change management. There is more information available here.

SAP Marketing Cloud

The SAP Help Portal for SAP Marketing Cloud provides a Solution Lifecycle Overview which explains how a two system landscape is typically used. A Quality system receives all the data and is configured before being copied to Production for the go-live. The Segmentation and target group configuration as well as the Extensibility Objects (custom fields, custom logic etc) still have to be manually imported into Production using the Manage your solution app. Ongoing changes for Segmentation and target group configuration and Extensibility Objects continue to be managed the same way after go-live. All other configuration changes are done in Quality and then transported by leveraging the Manage your solution app to create a service request ticket. When this request is processed the entire configuration moves from Quality to Production, not individual changes.

SAP Commerce Cloud

The public cloud edition of SAP Commerce runs in Azure leveraging kubernetes and the SAP Cloud Platform.

Extensions are used to manage additional functionality. Some are delivered by SAP but custom extensions can also be made. An extension generator system called extgen creates new extensions for you to work from based on extension templates. The configuration is carried out via code and continuous delivery/continuous integration recommended using code from a Git repository is recommended. The build and deployment of packages can be automated using APIs and third-party tools. For more information on the SAP Commerce Cloud architecture see this article.

C/4HANA: Test data provisioning

The proliferation of multiple underlying platforms also means the test data provisioning capabilities differ greatly. SAP Sales Cloud and SAP Service Cloud both have a ‘Tenant refresh’ procedure to request the entire system and data be copied either from Production to Test or one Test tenant to another. The process is managed by logging an incident from within the solution. SAP Note 2751824 provides more detail.

SAP Customer Data Cloud doesn’t have the same concept of test instances or tenants with the only configuration being done outside of the solution to call APIs that it provides.

The SAP Marketing Cloud has a two-tier architecture and all configuration made in the test system goes to production with each deployment. The data in the test environment is pulled from corresponding test systems e.g. S/4HANA dev/test clients. Multiple Segmentation Profiles can be used to take data from more than one S/4HANA dev/test system into SAP Marketing Cloud. This means the test tenant does not need to be refreshed from production but there is a dependence on having good test data in the linked system’s test environment.

SuccessFactors

In late 2011, SAP acquired SuccessFactors which, at the time, was then the second largest cloud-based software solution next to Salesforce.com, with more than 6,000 customers and over 32 million users in 60 industries in over 185 countries.

In 2012, SAP announced to its approximately 13,000 on-premise SAP HCM customers a planned movement to the cloud, and a planned future cessation of its on-premise HCM applications, including Payroll. When initially announced, customers were encouraged to journey to the cloud, adopting the SAP SuccessFactors cloud versions of the HCM solutions.

Since the acquisition, SAP has adjusted the options available for customers as to their journey roadmap and how fast they need to move to the cloud, as detailed in our Ultimate Guide: SAP HCM & Payroll Options for Existing Customers. The SuccessFactors cloud technology follows a different methodology from the traditional on-premise SAP change management transport style Dev, QA, Production workbench update model, and rather encourages standard configuration versus a highly customised system. For those customers who wish to extend the solution they are encouraged to leverage the meta-data framework.

SuccessFactors: Change Management

The Meta-data Framework (MDF) is how SuccessFactors provides extensibility. It allows functional users such as Business Analysts to configure objects and business rules with very little technical knowledge. These extensions are automatically supported by the OData API for reading and sending data. When standard objects are edited they are moved to replacement MDF versions. Picklist entries determine available values for fields and these can also be maintained by non-technical users. Some of these settings could be migrated from development instances to production ones via the Instance Sync utility but not all, and the process was cumbersome. Read this blog from my colleague Danielle Larocca to hear how this is now being improved with the new Configuration Centre which is much more similar to the Transport Management System in the ABAP stack. Many customers will already have significant misalignment between development, test, preview and production instances and adoption of the configuration centre with effective change management processes will need to go hand in hand with a clean up and alignment project.

SuccessFactors: Test data provisioning

The Instance Refresh utility is available for refreshing test instances from Production or from another test instance. For small and medium-sized instances, an automatic scheduling capability has been introduced, however for larger instances it is still maintained by ticket. Where SuccessFactors replicates to an Employee Central Payroll (ECP) system or backend SAP system for Finance and potentially Payroll, that backend system will normally be refreshed inline with the SuccessFactors instance refresh. Due to the extreme sensitivity of the data involved, that does throw up the need for masking or scrambling of the data. When investigating this, it's important to realise the replication process does not change data in all the ABAP stack tables (e.g. PCL2, REGUH), so a masking solution like Data Secure™ may be needed which can consistently mask SuccessFactors and the backend system before they are released to users.

For more information on provisioning test data for SuccessFactors, please see the white paper: Understand the Configuration Center's role in SuccessFactors Instance Management co-authored by my colleague Danielle Larocca.

How can you support heightened test data requirements in the S/4HANA world?

So clearly the role of the Enterprise Resource Planning system is changing with the move to S/4HANA, with it now being the digital core of the Intelligent Enterprise. And with that change in role there will be very different demands on the S/4 landscape in terms of providing the right data and configuration for integration testing with these different peripheral cloud solutions. Agility for your Test Data Management solutions and processes will become ever more important, while all the time the clock-speed of change will be getting quicker and quicker as all the new capabilities of the SAP Business Technology Platform (BTP) drive innovation in your SAP estate.
Find out how our Data Sync Manager™ (DSM) suite can help in this on-demand webinar recording.