Transformation to SAP S/4 Hana: Agility needs automation
No topic is currently occupying SAP departments more than the switch to SAP S/4 Hana: Should data, processes and customizing be transferred unchanged to the new world?
Or can a greenfield start be ventured with the introduction? And which of the many gradations between the two extreme approaches brownfield and greenfield best suits the respective customer situation?
There are no simple answers to these fundamental questions. After all, companies have invested a lot of time and money in customizing. In addition, for business reasons, they rely on functionalities that will only be available with the upcoming S/4 versions.
Many existing SAP customers will therefore probably make the transition to the new world step by step: first consolidate their various SAP ERP/ECC 6.0 systems, then switch to the Hana database, and finally implement the first S/4 applications.
As a result, they will run both software generations in parallel. With this "dual maintenance", SAP teams will have to develop, test and implement changes and innovations for both worlds and apply updates in both environments.
In addition, the templates for both the SAP ERP/ECC and S/4 systems must be protected and maintained to avoid difficulties caused by different changes to the same configuration in both worlds.
To ensure that this complexity does not come at the expense of agility, SAP managers are increasingly looking at converting their processes to DevOps. The associated advantages of being able to react more quickly to business requirements and provide innovations through the close integration of development and operations are too clear.
However, especially in large projects such as the introduction of SAP S/4, nothing can be allowed to go wrong, system downtimes and thus business losses must be avoided at all costs.
Control versus risk - faced with this choice, many SAP managers still cling to the tried-and-tested waterfall model. And this is despite the fact that they do not question the DevOps concept per se and SAP is also doing a lot to convince its customers of the DevOps benefits.
For example, agile methods have been supported in SAP SolMan since 2010 and have formed the core of SAP Activate, the implementation methodology for S/4, since 2015. Specifically in the implementation of requirements, SAP Activate envisions implementation along the lines of the agile approach Scrum in short, iterative cycles - so-called sprints - by small, effective, and interdisciplinary teams of developers, administrators, and quality managers.
To get a handle on the complexity problem on the road to S/4 and move from the waterfall model to more modern methods like SAP Activate or DevOps altogether, the solution for SAP teams lies in automation.
This benefits not only the development and delivery processes, but also the test processes. This applies equally to the testing of new functions as part of the migration and to regression tests of existing processes in SAP ECC.
Due to the size and complexity of both old and new SAP environments, such comprehensive testing procedures can only be realized by means of automation. Conversely, if transports and changes are carried out manually and at high speed, continuous integration and deployment are associated with risks.
Indeed, in SAP landscapes, only automation creates the necessary confidence in DevOps. And the higher the level of automation in Continuous Delivery, Continuous Integration and Continuous Testing, the faster the migration and transformation to S/4 will succeed.
So that SAP managers no longer have to choose between control and risk along the way, an integrated and highly automated tool chain is required for all phases of the migration, including dual maintenance.
