With S/4HANA, you have a data-hungry production system. And the sizing of hardware is not just disk, it's also memory. These come packaged either as a pre-built appliance, or you can leverage hyperscalers who provide T-shirt sizings for consumption. But in the hyperscaler model, you typically can’t go from 1 to 1.1 of something. When your system starts to fill the recommended maximum capacity, you have to go up a size – which is often double the previous allocation.
We’re constantly being told that this is a time of unparalleled technological change. That we will need to rethink many parts of our working lives as a result of AI and its staggering power. The scale of what we’re being asked to try to comprehend is incredibly daunting… so here’s a little break from all that where we can clearly see a simple technology change and why we must act differently.
For the last 30 years, most organisations running SAP have carried out system copies. It became clear that production data was the only way to unit test, regression test, integration test, system test, test the tests etc. And so the steady growth of production systems meant delayed but equal-step growths of non-production systems. The three-tier model (database server, application server and presentation layer) with a traditional database made it very easy to clip on additional volume as needed, and then in later years a SAN (Storage Area Network) could allow small chunks of space to be added almost instantaneously.
So, the process of allocating enough disk and then copying back Production to one or more non-production systems has become so ingrained in the annual calendar of an SAP Basis team that it is rarely challenged. Until you start to plan your S/4HANA landscape…
A data-hungry S/4HANA production system
Now you will have a more data-hungry production system. And the sizing of hardware is not just disk, it's also memory. These come packaged either as a pre-built appliance, or you can leverage hyperscalers who provide T-shirt sizings for consumption. But in the hyperscaler model, you typically can’t go from 1 to 1.1 of something. When your system starts to fill the recommended maximum capacity, you have to go up a size – which is often double the previous allocation. So now your 1TB highly-utilised production appliance becomes a 2TB low-utilised appliance, and before your next QA refresh you will have to scale up the hardware there too, or it won’t cope with the production data volume (disk and memory).
Don’t just bring me a problem, bring a proposed solution!
For the last 20 years I’ve argued that you don’t need production data from 10 years ago in your QA system. It won’t be displayed, reported on, changed, processed etc. It will lie dormant until it gets replaced next year, by itself, again. Now my argument is absolutely undeniable from a cost perspective. Transactional data is typically 50%-90% of the volume of an SAP system, so if we can limit the history in our test system, we can leverage a smaller appliance or smaller T-shirt sizing for hyperscaler hardware.
How to keep your SAP S/4HANA QA system the same size
But what’s even better is that your non-production systems will not grow at anything like the same rate. Unless your business generates a lot of master data, you’re really bad at housekeeping (and we can help with that), or your business generated more transactions this last year than the year before, the size of the QA system could remain the same (give or take). This is by leveraging the Client Sync solution (part of the EPI-USE Labs’ Data Sync Manager suite) to build your non-production system with all customising, master data, and only a set period of transactions, such as the last six months. Which is all you need for testing.
And this solution also provides wiggle room. If your slice of data does start to grow because of more master data or more frequent transactions, you can adjust your slice date to make it slightly smaller, or limit the selection to certain representative company codes only in order to delay a hardware investment another year or two.
Now that is just one side of the coin. There is also the unlocked ability to actually do more in your test systems, and have additional small clients for specific projects or pilots. And this in the S/4HANA world will become more and more necessary as the system becomes the digital backbone more than the place where every business process runs. Cloud applications will need dedicated backend clients to test interfaces with, without disturbing or being influenced by other projects. So what saves you money in the near term can help you support the flourishing of the business in the long term.
How does Data Sync Manager (DSM) reduce S/4HANA storage costs?
Want to learn more about Landscape and Test Data Management requirements in an S/4HANA world? Download Paul Hammersley's ebook.
Leave a Comment: