SAP release management and agility

In the dynamic IT world, we often hear from our customers that agility has made release management obsolete. The trend towards immediately putting completed features into production seems to reinforce this belief. But is that really the case? Or is this a return to old habits? Old hands will remember how changes used to simply be transferred to production (uncoordinated) on demand. So weren’t the beginnings hyper-agile and why shouldn’t they be today?

Continuous Delivery in the context of SAP

Parallel to agility, the concept of continuous delivery, also known as feature delivery, has become established. This model aims to put new features or updates into production at regular intervals, for example every two weeks. But how does Continuous Delivery fit into SAP release management?

In the SAP world, which is often characterized by complex and integrated systems, one might assume that continuous delivery is a challenge. But with the right tools and processes, it can certainly be implemented:

1. automated tests: A key aspect of Continuous Delivery is the ability to deliver quickly and reliably. This requires a strong emphasis on automated testing to ensure that new features or changes do not affect existing functionality. We have already described why automated testing should be indispensable in this article Test automation for SAP customers: Why it should be essential ‘ blue.works

2. feedback loops: Short feedback loops between development, test and operations teams are crucial. This ensures that problems can be quickly identified and rectified before they reach production (see DevOps).

3. flexible deployment: While some features may be suitable for rapid delivery, others may require longer testing and validation phases, especially in an SAP context. An orchestrated deployment that supports both continuous delivery and traditional release cycles is therefore essential, and this is precisely where release management plays a key role – namely in the orchestration of changes from different projects and extensions with different change speeds. This is particularly important when it comes to combining fast continuous delivery on new microservice architectures, e.g. SAP BTP, with an enterprise core (e.g. an integrated ERP system) with slower change speeds.

Why SAP S/4HANA is not a microservices system and has numerous dependencies

SAP S/4HANA and its predecessor SAP ERP are, as the abbreviation suggests, an integrated enterprise resource planning system that was developed to support and optimize business processes in companies. It is not a microservice system, but a comprehensive and complex system that covers many different business functions. Here are some reasons why there is no microservice system:

• SAP ERP/SAP S/4HANA was developed to support a wide range of business processes, from finance and controlling to procurement, production, sales and service. These processes are often interlinked and require close integration in order to function efficiently.

• As S/4HANA is an integrated system, data must be available consistently and in real time across different modules. This requires a close link and dependency between the various modules.

• SAP has also developed a standardized user interface for S/4HANA with Fiori. This requires tight integration between the different modules to ensure a consistent user experience.

• Many companies adapt S/4HANA to their specific business requirements. These adjustments can lead to additional dependencies between the modules.

• Many companies integrate S/4HANA with other systems, whether within the SAP ecosystem (such as SAP Ariba, SAP SuccessFactors, etc.) or with third-party systems. These integrations create additional dependencies.

It can therefore be said that the complexity and integrated nature of S/4HANA lead to many dependencies between the various modules and functions. This is both a strength and a challenge of the system, as it enables companies to comprehensively optimize their business processes, but also requires careful planning and implementation.

Bundling changes makes change and test management more efficient

For the reasons mentioned above, changes should be orchestrated and bundled. This significantly reduces the overhead for tests and deployments. An organized and structured bundling of changes is essential for the efficient operation of such integrated systems. This means that test scenarios can be created once and used for several changes at the same time. This makes the scope of testing much larger than with individual changes, and the probability of errors and undesirable side effects remaining undetected in regression tests is greatly reduced.

It can therefore be said that, in principle, every change stresses production and that this stress is reduced by bundling the changes.

Release calendar with different cycles for flexible deployment – but planned!

A predictable release cycle ensures that all teams in the company work in sync. This is particularly important in large organizations, where projects often have interdependent elements. A fixed calendar enables teams to allocate their resources effectively and ensure that their work is not affected by external factors. If the release cycles have a fixed rhythm, it is easier for business users to adapt to them.

SAP best practice is to distinguish between three different Change Paces.

1. Innovation Pace – for the big projects
   The “Innovation Pace” is intended for large projects. Changes from these projects have a significant process impact. This means that such projects are carefully planned and can be put into production in several steps (waves) or in one large step.
   
2. Enhance Pace – for more flexible deployments (and continuous delivery)
   The “Enhance Pace”, on the other hand, is there to bring small enhancements and improvements to the system. The process impact should be minimal and each one should be analyzed and approved within a change board committee.
   This is where every company benefits from good requirements management: the specialist department can record all its wishes and requirements. These are evaluated and analyzed. The exciting thing is that, depending on the results of the analysis, a requirement can either result in an Enhance Change or even an entire project. Or you realize that many requirements could be clustered thematically and implemented within an expansion project.
   If you now manage to coordinate many of these tasks transparently and automate steps for testing and deployment (see Piplines), you have probably already arrived at Continuous Delivery.
   
3. (Bug)fixing Pace: Yes, the production downtime can be fixed directly
   There are times when immediate action is required, especially in the event of critical production errors. The “Fix Pace” offers precisely this flexibility. If there is an error in production, it should be rectified as quickly as possible – without having to wait a long time for the next deployment window.
   

Does my microservices architecture now make release management obsolete?

Encapsulated microservices would indeed offer greater flexibility and allow organizations to deploy faster and more frequently. This is one of the main advantages of the microservice design. Nevertheless, the existence of microservices does not necessarily mean that traditional release management becomes completely superfluous. Here are some thoughts on this:

• Complexity: Despite the advantages of independence, microservices can be complex, especially in an ecosystem and in interaction with SAP S/4HANA with many interacting services. Effective release management can therefore still help to control this complexity and ensure that there are no unintended side effects when new functions or changes are introduced.

• Dependencies: Even if microservices are well encapsulated, there can still be dependencies between them. Changes in one service could have an impact on others, especially if they use shared APIs or databases. For example: If a microservice for authentication fails, all other microservices can be affected – even a small change (such as replacing the certificate chain or the Trusted CA) that works in an encapsulated manner can have major negative side effects for all other web services.

• Quality assurance: Irrespective of the architecture, thorough quality assurance is essential. With frequent deployments, quality assurance can be a challenge, especially if there are insufficient automated tests.

• Stakeholder communication: For large organizations, it may be useful to maintain a release management system to ensure that all relevant stakeholders are aware of upcoming changes and to gather feedback.

Ultimately, microservices actually make it possible to deploy features more frequently and independently of each other (continuous delivery). However, it remains important to orchestrate and monitor deployments and ensure that they meet stakeholder expectations and the company’s quality standards and, above all, to coordinate changes with any slower change-pace systems.

Overall advance planning makes deployment even faster

Anyone who has worked in a large company knows the challenges that come with coordinating different departments. Release management offers a very good coordination point here. For example, if the finance department is planning year-end processing, the IT team can ensure that this is taken into account in the release calendar to avoid potential conflicts.

Furthermore, cyber threats are constantly increasing and security patches are essential. With fixed release management, time slots for security updates are defined in advance. This means that the time-consuming process of coordinating these slots with stakeholders is no longer necessary. This not only promotes efficiency, but also ensures that critical security updates are not delayed due to scheduling conflicts.

The need to be fast and agile is beyond question. However, in complex IT environments, especially those supported by integrated SAP systems, balanced release management is (currently still) essential. It can be said that while agility and continuous delivery offer their own advantages, traditional release management still has its place, especially in complex systems such as SAP. It’s about combining the best of both worlds to deliver both quickly and securely.

Just ask us how you can utilize and technically map the advantages of agility and structured release management.