- SAP Managed Tags:
Introduction
The closer we are to the era of SAP S/4HANA Cloud 3-systems landscape, the more relevant become discussions and understanding of deployment orchestration in such environment.
This blog post describes, how such commonly familiar SCRUM terms as waves & sprints are connected with the SAP Cloud ALM possibilities.
Release: understanding the project timing in SAP Cloud ALM
The biggest from timeframe perspective entity, provided in SAP Cloud ALM is Release. You can create Release in "Project" app:
Once you set up your Project and created Release, you can assign Release to Project:
Generally recommended correlation between these two entities is having one Release for one Project.
Release version: split your project
As you can see on the first screenshot, it is also possible to have Release versions in the Release.
Having Release versions in SAP Cloud ALM, we can match them with such terms from the SCRUM, as Waves.
For example, if we are talking about SAP S/4HANA Cloud initial implementation project, each Wave (and Release version therefore) can contain activation of new country and related activities.
Sprint in SAP Cloud ALM
We can say, that SAP Cloud ALM Sprints mean the same, what SCRUM Sprints and common approach is having Sprints of 2 weeks duration. But in the last time many companies try to switch to even shorter Sprints.
So one Wave (and one Release version) will have several Sprints. Sprints are aimed for resolving certain technical tasks, which can be described in details. As an example of such task, we can use building of integration flow for one business entity or setting up output scenario for one type of document.
And these examples lead us to the SAP Cloud ALM entities, which are meant to help defining already mentioned technical tasks: User Stories and Features. The detailed descriptions of these two entities are available in the linked blog posts. And for the concept we are discussing here, it is important to mention, that there could be as many User Stories in Features in one Sprint, as necessary to define properly technical scenarios to be implemented in the Sprint.
Moving to PRD
The described above concept plays important role not only for processes´ and teams´ organisation, but also for having technically consistent solution in productive tenant of your target system. Setting up the business processes in SAP S/4HANA Cloud, for example, can include such different activities, as fine tuning, in-app extensibility and embedded steampunk extensibility. These activities can be distributed between different Teams and SAP Cloud ALM Tasks. But the whole business process would work properly, only once all components are available in the system. It is critically important therefore, to use dependent Transport requests to move all the parts simultaneously from DEV SAP S/4HANA Cloud system to TEST (if we are talking about 3 systems landscape).
As a result, we can have several Transport requests for one Feature (and User story).
But it is also important to say, that final import to PROD system should complete the earlier described Wave (or Release version).
Various SAP Cloud ALM analytical solutions provide strong support to trace such processes.
Conclusion
The final picture of the described terms and dependencies would look then like this:
No doubt it can be assumed, that further questions and considerations would appear during usage of SAP Cloud ALM in more and more complex projects. We will continue evaluation of deployment orchestration from various perspective in future blog posts, how it is already done in this one, for example.
