- SAP Managed Tags:
Technical Change Control enables you to control all software and configuration changes to your IT landscape. Both SAP Cloud ALM and SAP Solution Manager support it, but differently. Understanding the difference is another aspect relevant for your decision which ALM platform to choose for your SAP S/4HANA Cloud solution. In this blog post, I will briefly explain the different technical change control concepts of SAP Cloud ALM and SAP Solution Manager. This is another component of my blog series ALM for SAP S/4HANA Cloud.
Technical changes are managed by the systems themselves. If you make a change on a development system, it will be put into a transport and moved to the quality assurance and later to the production system by transport management. However, there might be dependencies between individual changes. Technical change control helps to manage these dependencies. You can orchestrate heterogeneous transport mechanisms to accelerate the delivery process. And you can increase transparency and reliability of changes and upgrades.
Deployment orchestration is required to handle the dependencies of transports. If an object included in one transport refers to an object included in another transport, the deployment of these objects needs to be aligned to avoid problems. This refers both to objects within a system as well as to related objects on different systems.
In SAP Cloud ALM, so-called Features are entities for change documentation and deployment orchestration. They are containers to collect information on changes and to trigger the deployment of assigned transports throughout your system landscape. Besides a simple description, you can relate features to work streams, user stories, or project tasks for documentation purposes.
Different transport management systems are relevant for SAP S/4HANA Cloud:
Some quality control is included in Features. Before triggering the deployment of changes in a feature, SAP Cloud ALM checks if any assigned transport is in a failed status. You must correct all transport errors before you can deploy the feature to the next stage. And deployment to the production system will only work after you have set the feature status to “Ready for Deployment”.
SAP Solution Manager uses Change Documents as equivalents to Features. A Change Document documents the activities of the users that are involved in the change process, for example developers, testers, and system administrators. A change document is created automatically by the system when a change manager or another employee responsible approves a request for change.
Change control in SAP Solution Manager supports both CTS and CTS+. SAP Solution Manager can even be your central domain control for CTS+, such that you can set up transports directly in SAP Solution Manager. And you can use SAP Solution Manager change control for Cloud TMS and Git-enabled CTS (gCTS) as well. However, the support of ATO is not on the SAP Solution Manager road map currently.
Traceability is crucial for technical change control. You, your colleagues, or even external auditors might want to know who has approved and who has executed the changes when.
SAP Cloud ALM has a standard workflow for features:
You can look at the history of a feature to see which user did which change at which time. This covers both content and status changes. With this, you have a kind of audit log.
SAP Solution Manager has multiple pre-configured workflows for diverse types of change. For example:
It is possible to adapt these workflows to your own requirements. For example, you can include additional approval steps or electronic signatures in the workflow if this is required by regulations applying to you.
Besides orchestrating and tracing the deployment of transports, you might want to have additional quality checks to avoid disruptions through transport errors. And if you have a more complex system landscape, additional support is valuable as well.
With SAP Solution Manager and the add-on Focused Build, you have more possibilities for deployment control.
As a relatively young product, SAP Cloud ALM does not provide such additional quality control yet. And there is no additional support so far for managing more complex landscapes, like dual system landscapes. You must manage such situations directly on your SAP S/4HANA Cloud system.
Release management is another feature provided by both SAP Solution Manager and SAP Cloud ALM, but differently. It takes care of managing the successful deployment of related changes. The release sets the timeline for deploying the contained changes.
With Release Management in SAP Cloud ALM, you can assign multiple projects to one release. All projects of a release have the same timeline. Each release has one or multiple release versions. These are required for agile projects, where the project result is delivered in multiple steps.
After assigning your project to a release, you will assign the individual requirements of the project to release versions. The GANTT chart view of the project allows you see the timeboxes of all involved release versions, requirements, user stories, and tasks together. The relation between release versions and contained transports is managed only indirectly at the moment via features assigned to the same requirement as the release version. But tighter integration has high priority on our development road map.
Release Management in SAP Solution Manager is much more mature than in SAP Cloud ALM currently. It provides tight integration between Release Management and general project scheduling. And it offers additional control for all activities required to manage a release successfully. Changes within releases are covered as well, e.g., when a development needs to be shifted from one release to another due to a delay in development. With SAP Cloud ALM, you would need to handle this directly in the transport management system of SAP S/4HANA Cloud, Private Edition.
In my other posts of the blog series ALM for SAP S/4HANA Cloud, I have recommended creating a decision table for your answer to the question: “Is SAP Cloud ALM or SAP Solution Manager the better ALM solution for our SAP S/4HANA Cloud?”. Let me summarize this blog with key questions to add to your decision table from the technical change control perspective:
And this is just the technical change control point of view. You should align it with other aspects discussed in other blogs, like e.g., the cost of the ALM solutions.
I hope you enjoyed reading this blog post. What’s next?
Technical changes are managed by the systems themselves. If you make a change on a development system, it will be put into a transport and moved to the quality assurance and later to the production system by transport management. However, there might be dependencies between individual changes. Technical change control helps to manage these dependencies. You can orchestrate heterogeneous transport mechanisms to accelerate the delivery process. And you can increase transparency and reliability of changes and upgrades.
Deployment Orchestration
Deployment orchestration is required to handle the dependencies of transports. If an object included in one transport refers to an object included in another transport, the deployment of these objects needs to be aligned to avoid problems. This refers both to objects within a system as well as to related objects on different systems.
In SAP Cloud ALM, so-called Features are entities for change documentation and deployment orchestration. They are containers to collect information on changes and to trigger the deployment of assigned transports throughout your system landscape. Besides a simple description, you can relate features to work streams, user stories, or project tasks for documentation purposes.
Different transport management systems are relevant for SAP S/4HANA Cloud:
- The Change and Transport System (CTS) for deploying ABAP transports. Features cover the deployment management for SAP S/4HANA Cloud, Private Edition and SAP NetWeaver Application Server for ABAP on-premise.
- The Enhanced Change and Transport System (CTS+) can be used for non-ABAP transports. Features support CTS+ as well for transports that are managed by the domain controller of the connected system (SAP S/4HANA Cloud, private edition).
- The Cloud Transport Management System (Cloud TMS) is supported as well. It is used for transporting changes of applications developed on SAP Business Technology Platform Neo and Cloud Foundry environment (as well as ).
- The support of the Adaptation Transport Organizer (ATO) from the public SAP S/4HANA Cloud is not available yet. ATO is used for transporting changes made by the Central Business Configuration. You must manage these changes directly on the SAP S/4HANA Cloud system. But the support of ATO by Features is planned already in the SAP Cloud ALM road map.
Some quality control is included in Features. Before triggering the deployment of changes in a feature, SAP Cloud ALM checks if any assigned transport is in a failed status. You must correct all transport errors before you can deploy the feature to the next stage. And deployment to the production system will only work after you have set the feature status to “Ready for Deployment”.
SAP Solution Manager uses Change Documents as equivalents to Features. A Change Document documents the activities of the users that are involved in the change process, for example developers, testers, and system administrators. A change document is created automatically by the system when a change manager or another employee responsible approves a request for change.
Change control in SAP Solution Manager supports both CTS and CTS+. SAP Solution Manager can even be your central domain control for CTS+, such that you can set up transports directly in SAP Solution Manager. And you can use SAP Solution Manager change control for Cloud TMS and Git-enabled CTS (gCTS) as well. However, the support of ATO is not on the SAP Solution Manager road map currently.
Change Process Control
Traceability is crucial for technical change control. You, your colleagues, or even external auditors might want to know who has approved and who has executed the changes when.
SAP Cloud ALM has a standard workflow for features:
- A feature can be created from a requirement or directly in the Feature app
- A technical specification is added to the feature
- The Feature is implemented, changes are recorded in a transport, and the change is deployed to the test stage
- After successful testing, the feature is ready for deployment
- Finally, the successful deployment to production is confirmed
- For postponed features, there is an additional status ‘Not Planned’
You can look at the history of a feature to see which user did which change at which time. This covers both content and status changes. With this, you have a kind of audit log.
SAP Solution Manager has multiple pre-configured workflows for diverse types of change. For example:
- Urgent change
- Standard change
- Minor releases
- Major releases
It is possible to adapt these workflows to your own requirements. For example, you can include additional approval steps or electronic signatures in the workflow if this is required by regulations applying to you.
Further Deployment Control
Besides orchestrating and tracing the deployment of transports, you might want to have additional quality checks to avoid disruptions through transport errors. And if you have a more complex system landscape, additional support is valuable as well.
With SAP Solution Manager and the add-on Focused Build, you have more possibilities for deployment control.
- The Transport Execution Analysis is a guided self-service to analyze your current transport process.
- Change Diagnostics determines and tracks technical changes in a managed system.
- Cross System Object Lock prevents that changes of the same object can be done in more than one transport in parallel.
- You can use Quality Gates as special milestones in projects. At that gate, you or your project team confirm that all essential checks have been done and all required approvals are available.
- If you work in parallel projects (e.g., maintenance and new development), you can use dual-system landscapes to separate changes of the different projects. But it is important to synchronize the parallel development systems regularly to avoid inconsistencies later. This synchronization effort can be significant. With the so-called Retrofit functionality of SAP Solution Manager, you can fully automate more than 90% of the required maintenance tasks.
As a relatively young product, SAP Cloud ALM does not provide such additional quality control yet. And there is no additional support so far for managing more complex landscapes, like dual system landscapes. You must manage such situations directly on your SAP S/4HANA Cloud system.
Release Management
Release management is another feature provided by both SAP Solution Manager and SAP Cloud ALM, but differently. It takes care of managing the successful deployment of related changes. The release sets the timeline for deploying the contained changes.
With Release Management in SAP Cloud ALM, you can assign multiple projects to one release. All projects of a release have the same timeline. Each release has one or multiple release versions. These are required for agile projects, where the project result is delivered in multiple steps.
After assigning your project to a release, you will assign the individual requirements of the project to release versions. The GANTT chart view of the project allows you see the timeboxes of all involved release versions, requirements, user stories, and tasks together. The relation between release versions and contained transports is managed only indirectly at the moment via features assigned to the same requirement as the release version. But tighter integration has high priority on our development road map.
Release Management in SAP Solution Manager is much more mature than in SAP Cloud ALM currently. It provides tight integration between Release Management and general project scheduling. And it offers additional control for all activities required to manage a release successfully. Changes within releases are covered as well, e.g., when a development needs to be shifted from one release to another due to a delay in development. With SAP Cloud ALM, you would need to handle this directly in the transport management system of SAP S/4HANA Cloud, Private Edition.
Conclusion
In my other posts of the blog series ALM for SAP S/4HANA Cloud, I have recommended creating a decision table for your answer to the question: “Is SAP Cloud ALM or SAP Solution Manager the better ALM solution for our SAP S/4HANA Cloud?”. Let me summarize this blog with key questions to add to your decision table from the technical change control perspective:
- Which Change and Transport System do you use? Is it supported by SAP Cloud ALM or SAP Solution Manager?
- Do you want to use a standard change control workflow, or do you prefer individual flows?
- How often do you plan to update your SAP S/4HANA Cloud solution?
- Do you have special regulatory requirements that need to be fulfilled? And if so, are they supported by SAP Cloud ALM or SAP Solution Manager?
- Do you want to use additional quality control or release management offered by SAP Solution Manager only?
And this is just the technical change control point of view. You should align it with other aspects discussed in other blogs, like e.g., the cost of the ALM solutions.
Next Steps
I hope you enjoyed reading this blog post. What’s next?
- Voice your opinion or ask questions about the content of this blog by adding a comment below.
- This blog post is part of my series: ALM for SAP S/4HANA Cloud. Please stay tuned to read more on this topic. <Start blog> <Previous blog> <Next blog>
- And follow the tags SAP Cloud ALM or SAP Solution Manager for related information. Thank you!
3 Comments
