This blog post addresses the release management mechanisms available with SAP S/4HANA Cloud, which allow your company to benefit from the latest innovations and improvements.
Release management with SAP solutions implies a continuous focus on adoption and embracing a culture of constant change. This post will explain the basic components of the quarterly release upgrade process for SAP S/4HANA Cloud. Then, we’ll discuss how you can make the most out of the continuous innovation delivery by following a structured approach based on available tools and the SAP Activate innovation adoption process.
Release management is a key practice that helps ensure ongoing organizational alignment, predictability, and quality software delivery. Thus, you’ll need systematic and clear collaboration and communication between SAP as the software vendor and your IT departments, your key users, and your end users working with SAP S/4HANA Cloud.
The purpose of SAP’s streamlined release management processes is to coordinate the development, operations, and deployment of software, while ensuring close alignment with business priorities. SAP enables you to establish an efficient and effective release management process by providing multiple tools, best practices, and guidance. From the perspective of an SAP customer, the main goals of an optimized release management process are to minimize the overall effort and cost of the process itself, while maximizing the business value, which can be achieved by sustainably adopting new release innovations and functionalities.
Release Upgrade Schedule
The release upgrade procedures of SAP S/4HANA Cloud are designed to be recurring, predictable, and reliable. Their sequence is specified and planned at least one year in advance. All companies follow the fixed upgrade schedule; no choice allows you to opt out or delay the release changes. SAP publishes the most recent release upgrade schedule online, which can be easily found with the search phrase “SAP S/4HANA & Marketing Cloud – Upgrade & Maintenance Schedule.” Two biaunnual release upgrades are planned each year, and each release is named with the current year and month. For example, “2208” represents the year 2022 and the month August.
For a two-system landscape, upgrades are performed in the following sequence:
- Quality systems are upgraded to the latest release, on the first weekend after the release-to- customer date.
- Production systems and all other types of systems (for example, starter systems) are upgraded on the third weekend after the release-to-customer date.
The purpose of the time gap between the quality and production system upgrades is to provide time for regression testing, thereby lowering the risk of upgrade-related issues. The table below provides an example upgrade schedule.
A detailed upgrade schedule for a two-system landscape can be found at http:// s-prs.co/v545703, and a detailed upgrade schedule for a three-system landscape can be found at http://s-prs.co/v545704.
Software patches and infrastructure maintenance activities are performed within weekly maintenance windows. Detailed information about the underlying servicelevel agreements (SLAs) can be found at the SAP Trust Center site, at https://www.sap.com/about/trust-center.html.
SEPTEMBER 2022 UPDATE: SAP has announced that new SAP S/4HANA releases will be every two years starting with the release of the 2023 version in October. Feature packs can be expected every six months during the two-year period between releases.
Plan and Perform Preparation Steps
Good preparation is a key success factor to making the most of SAP S/4HANA Cloud release upgrades while also minimizing effort and risk. Upgrades can occur in different phases of the system lifecycle. No matter in which implementation phase they take place—for example, the SAP Activate explore, realize, deploy, or run phases—upgrades must be reflected in your project timelines.
As an additional preparation step, early on, you should plan your activities around the release upgrades of SAP S/4HANA Cloud to ensure enough capacity. This planning includes, for example, informing key and end users about the new releases, taking part in early-release web sessions from SAP, and performing and reviewing postupgrade regression testing.
Tools and Best Practices
Your organization should define clear roles and responsibilities for the release management processes of SAP S/4HANA Cloud. Ideally, a central instance coordinates the preparation and execution of release upgrade-related activities and additionally at least one key user from the business per domain area who is specifically assigned as a catalyst for innovation adoption. Some helpful resources and communication channels, from high-level videos to detailed release notes, are offered by SAP, such as the following:
- Release videos: http://www.sap.com/s4-cloudrelease
- Release blogs: https://blogs.sap.com/2018/06/01/sap-s4hana-cloud-the-intelligent-erp-link-collection/
- What’s New Viewer and PDFs: https://help.sap.com/viewer/product/SAP_S4HANA_CLOUD/latest/en-US?task=whats_new_task
- Roadmaps: https://roadmaps.sap.com/
- Innovation discovery: https://go.support.sap.com/innovationdiscovery/
- Early release web series and show-and-tell sessions
- Release information and restriction notes in SAP Support Portal
The depth of information and content in these resources support each target group—from IT management to project managers, key users, and end users—in consuming and digesting the new innovations. In addition to general information about new releases, SAP also provides a tool for a more tailored approach to analyzing the impact and opportunities of a new release for your specific SAP S/4HANA Cloud installations. This solution is called the release assessment and scope dependency tool for SAP S/4HANA Cloud. With this tool, you can visualize your specific activated scope and understand the changes and new functionality available with an upgrade and be guided to potential innovations or new scope items that might be relevant to you. The tool suggests where you should focus your testing efforts based on the degree and impact of changes to the activated scope items, as shown in this figure.
Another key area of activity that secures a smooth release transition is post-upgrade testing. Testing can be supported by using the test automation tool for SAP S/4HANA Cloud along with automated post-upgrade testing, which is performed by SAP on behalf of customers. If you have a relatively high number of active interfaces and extensibility objects, you are advised to systematically retest their core functionalities in the time between the Q and P system release upgrades to ensure stability and business continuity and minimize risks accordingly. Also, objects related to identity and access management, such as business catalogs and business roles, need to be revised because, over time, some existing objects will be deprecated and new ones added by SAP.
Communication and Organizational Change Management Measures
To ensure that the potential added value from the quarterly release upgrades of SAP S/4HANA Cloud is realized, you’ll need to systematically perform organizational change management and provide clearly defined communication channels. Internal key users, champions, or coaches should be assigned to foster a continuous learning mindset and make all system users aware of learning resources, new innovations, and functionalities. Business users will be affected by changes like new user interfaces (UIs) and apps every six months; thus, these changes are predictable and can be planned. Instead of seeing release upgrades as an additional burden, changes in functionalities and new innovations can be accepted and proactively addressed enable a company culture that looks forward to and is curious about the new SAP S/4HANA Cloud releases.
Continuous Delivery for SAP S/4HANA Cloud
SAP is introducing a new development and delivery model for SAP S/4HANA Cloud. Building on top of the existing release management model, it is meant to accomplish the feat of accelerating change and reducing disruptions at the same time.
The first section will explain the underlying philosophy and how it applies to SAP S/4HANA Cloud. The second section discusses the impact of the new paradigm on the development process. The final section explains how this affects you and the way you consume new features.
Continuous Integration/Continuous Delivery: A Paradigm Shift
Continuous integration/continuous delivery (CI/CD) is a software engineering practice combining continuous integration, the frequent merging of changes into a shared code line, and continuous delivery, which aims to deliver changes to the productive environment in short iterations.
The purpose of continuous integration is to discover integration issues early and prevent merge conflicts when multiple development branches are merged back into the main branch shortly before an upcoming release. As ABAP development generally takes place on a shared server, continuous integration is already deeply ingrained in the SAP S/4HANA Cloud development model.
The goal of continuous delivery is to accelerate the innovation cycle by reducing the time from requirement to delivery and enabling earlier feedback and faster iterative improvements. It also makes each incremental delivery smaller and easier to consume. As SAP S/4HANA Cloud and its predecessors have always used a release-based model, this represents a fundamental change to the traditional development process. SAP already provides biweekly maintenance releases (hotfix collections), while urgent corrections (Emergency Patches) can even be delivered on demand, but these processes are geared toward fixing a limited number of issues, not the introduction of a large number of new, potentially complex features.
Continuous delivery for SAP S/4HANA Cloud is SAP’s way of bringing CI/CD principles to SAP S/4HANA Cloud. It is a hybrid approach that combines feature-based planning and development with a combination of feature-based and release-based delivery.
As stated earlier, changes that affect business users need to be predictable and plannable. Simply increasing the number of releases would introduce constant change and undermine this goal. In fact, SAP has done the opposite instead and switched from a quarterly to a biannual release schedule in 2022 to minimize the impact of lifecycle processes on you. This might appear to come at the cost of slowing down the flow of innovations, but thanks to the introduction of continuous delivery for SAP S/4HANA Cloud, quite the opposite is true.
Feature deliveries can now be integrated into any maintenance release, which can used to provide up to 10 additional delivery windows in 2022. This requires confidence that each feature can be delivered without causing disruptions or otherwise demanding attention. The following sections explain how this is achieved.
Continuous Engineering: Feature Development
Release-based development tends to go through a cycle of extension and enhancement followed by stabilization and validation that cannot be arbitrarily accelerated. As features are much smaller than releases, feature-based development can achieve shorter cycles by focusing on individual features.
Continuous delivery for SAP S/4HANA Cloud introduces a highly automated integration pipeline. Whenever a feature, or part of a feature, is complete and meets all quality criteria, it is moved from the shared development environment to a stable environment from which the feature deliveries are supplied. Before any change is allowed into the stable environment, the pipeline subjects it to a battery of automated tests that help ensure that all dependencies have been considered and no regressions are introduced. Further validations are applied before a delivery takes place.
This working model encourages a “deliver when done” approach with a focus on quality. A change is not published based on a deadline but instead when it is ready and free of defects. As a consequence, SAP cannot predict with certainty which features will be included in a specific delivery. But as deliveries are frequent and the arrival of new features requires no preparation on your side, delaying a feature by a delivery or two generally has little impact. In the rare case that a feature is time critical, which might be the case if it represents a legal change, this needs to be considered in the resource planning process to enable a delivery in time and quality.
Integrating even parts of features as early as possible and then delivering frequently entails that each delivery may contain changes that are not yet usable. If completed features need to be delivered smoothly and without disruption, this is even more true for incomplete ones. SAP therefore employs a mixture of suitable architecture patterns, business configuration, and feature toggles to help ensure that changes stay hidden and inactive until they are ready to be rolled out.
Feature toggles, which are supported in the ABAP programming language itself, are temporary switches that manage the rollout of changes. They are not only used in the source code to switch the behavior of ABAP between an old and a new version but can also be used to control the visibility of other assets, such as UX elements, services, documentation, or best-practice configuration, in a coordinated fashion.
Continuous Adoption: Feature Consumption
A new feature has now been developed, validated, and delivered to you silently, unobtrusively, and without causing downtime. Now you want to consume it.
SAP’s stated vision is to make the consumption of new features as simple and fast as possible. A feature should not require a project to introduce it. Ideally, it should not require any manual steps or decisions on your part at all but should work out of the box, using reasonable default settings. However, there is a high bar that a feature needs to clear to be considered for a fully automatic introduction. If there is any chance that the adoption of a feature might require retraining users, manual retesting, or any other form of manual intervention, the feature may be delivered only in an inactive state.
In many cases, features will represent additive changes. Using the new behaviors is then optional and subject to your configuration decisions. Often, such features permanently introduce a new choice in the business adaptation catalog. However, when a feature modifies or updates existing functionality, its adoption may not be optional and needs to be carefully managed as part of the feature lifecycle.
The figure below illustrates the lifecycle of a feature. It moves through development, validation, and rollout phases before becoming part of the standard behavior of every SAP S/4HANA system.
Different rollout strategies are supported to cover a wide range of use cases. The first rule of rollout is that any mandatory action on your part, if it cannot be avoided to begin with, is not allowed unless it is planned, announced, and scheduled for one of the biannual releases. The two strategies that are most relevant to you are as follows:
- Immediate rollout is used for features that can be activated safely in the background. You do not have to take any action.
- Customer-controlled rollout is used to enable you to adopt a feature at a time of your choosing. This gives you the option to immediately start using a feature that may require an action on your part and could therefore be activated by SAP only with the next biannual release.
All feature toggles are planned to be activated and then removed in the end, so all features should be rolled out eventually.
The transition to a feature-based model is a process that is expected to span multiple years. Ultimately, all development is planned to be organized as features, empowering you to consume them according to your needs. You may generally be content to focus on stability between the biannual releases, but you still have the flexibility to immediately introduce a feature you urgently require, giving you the best of both worlds.
Editor’s note: This post has been adapted from a section of the book SAP S/4HANA Cloud: An Introduction by Thomas Saueressig, Jan Gilg, Uwe Grigoleit, Arpan Shah, Almer Podbicanin, and Marcus Homann.
Comments