Even new and complex systems can be stable
The primary goal of all SAP organizations in the world is stability. In keeping with the motto "never touch a running system," they continue to collect patches, adjustments and individual developments, combine them in a major release, subject it to extensive and repeated tests and put it into production once or twice a year at the most. This will not change in the new S/4 world. This is one of the reasons why many existing SAP customers inadmissibly reduce the discussion about the cloud to the question of the ideal implementation and operating location for the new software generation from Walldorf.
For SAP, the cloud is primarily a question of the optimal architecture for software and the software development of the future. This means function-specific and reusable services instead of software monoliths and the release of corrections, changes and enhancements in high numbers as soon as they are available. Gone are the days of large releases at equally large intervals.
This goes hand in hand with SAP's motto "Keep the core clean". Walldorf encourages SAP's existing customers to develop and provide individual customizations only as extensions. And to avoid a juxtaposition of fast and flexible changes in the core on the one hand and in the extensions on the other, SAP recommends that its customers follow the golden path of its Cloud Application Programming Model (CAP). In this model, developers can focus on their specific tasks and develop code in programming languages other than Abap. Everything is going in the direction of open standards for greater compatibility and reusability, also and especially in interaction with third-party applications.
More and more changes in ever shorter time, many small releases at high frequency, more programming languages, consistent separation of database, application and presentation levels - the SAP world is becoming more complex in the new generation. But more complexity means more effort and more sources of error, the horror for SAP organizations that cling all the more tenaciously to the status quo.
The line between proponents and opponents of change does not run between IT and the rest of the company, but within IT between development and operations. Ordered yesterday, delivered today - that's what not only business users expect, but also developers. They don't want to wait until the test environment is ready for their changes and enhancements created with agile methods, nor do they want to dwell on their impact on the operation and stability of the productive environment.
Their ideal is standardization and automation. But for that, they need their colleagues in IT operations. And they need to understand them better. This is precisely the goal of the DevOps concept, which creates the necessary basis for this through close collaboration in interdisciplinary teams.
DevOps is first and foremost a question of culture. And because this is lacking in many SAP organizations, there is no trust in this approach. Without this trust, however, there will be no grassroots movement that will eventually reach a critical mass and bring about the necessary change of its own accord, as it were. This is what the experience of the past three to five years has shown, contrary to expectations.
Management must put its foot down and force Dev-Ops. Because without agility, a "running system" quickly becomes a "failing system" in the cloud era. An end-to-end tool chain - from development and iterative troubleshooting to testing and code delivery - helps drive acceptance of this decision: So that the trust gained in collaboration is not shattered by the harsh reality of production systems, but both - development and operations - benefit from fast and frequent, yet low-risk software delivery.
